Organization of multi-level voice menus

IVR configuration example may be found here
Personal Account Home Page. IVR. Voice Menu.

Full IVR parameters description is here:
Voice Menu (/ivr/)

Multi level example:

1. You have one level IVR from example Personal Account Home Page. IVR. Voice Menu.

2. Go to IVR configuration page
   https://demo.ucom4b.com/routing/

3. Choose “Add new schema“
   
   

   Open

   

   “NEW SCHEMA1” will be created, choose it
   
   

   Open

   

   
   Now you may configure it according to. For example name it “Second level“ and add action “Play Sound“
   
   

   
   Now we have routing page https://demo.ucom4b.com/routing/ like
   
   

    

4. Now it is possible to create transfer from one level menu to this menu (SECOND LEVEL). For example we want enter this sub menu by dialing “1“. Go to high level menu:
   
   

   
   Assign for number “1“ call transfering into this schema:
   
   

   
   
   

Queuing

Agents/Extensions Overview

Client(some organization) can have extensions with type='phone'. These extensions are:

1. Some device (phone/softphone etc) that can receive incoming call and do outgoing calls (SIP account in other words)

2. (optional) Employee who assigned to this extension

For example there are 3 extension: 101,102,103 have SIP account and assigned employee, 104 is just a SIP account:

Also client can have different queues (callcenters). For example here are 2 queues:

If employee wants to be a part of callcenter it should create an “agent“. Every employee (extension) may have few agents. All this agents introduce specific employee. For example here we have created 3 agents for Talal employee:

and one for Hamid and Dmitri

Assume

1. BMW Queue should contain Talal and Hamid

2. Audi Queue should contain Talal and Dmitri

3. Talal wants to have different agents for different queues (for getting separate agent reports in future)

Then queues configuration will be like this

In the morning Talal pick up the phone/softphone with 101 SIP account and dial

1. *96 and “Talal for BMW Queue” and “Talal for Audi Queue“ will start to receive calls from BMW and Audi queues

2. *96200 and only “Talal for BMW Queue” will receive calls from BMW queue

3. *96201 and only “Talal for Audi Queue” will receive calls from Audi queue

Hamid may dial *96 or *96200 and Dmitry may dial *96 or *96201

In the evening (or for break time) Talal dial *98 to logout all his agents or *96xxx to logout from specific queue

No any web interface manipulation is required in the evening and in the morning.

Agent reports will be done for agents, so for Talal there will be report for “Talal for BMW Queue” and “Talal for Audi Queue“ agent. Off course Talal may use one agent (“Talal” agent) for both queues and then get one agent report for both queues.

Separating agents from extensions

Assume it is required 2 employees every day in the office. So at the same day it will be Talal and Hamid or Talal and Dmitri or Dmitri and Hamid.

Currently it is necessary to have 3 work places with different SIP devices or 2 workplaces with multi-extension devices (3 different lines). Now we want to separate employee from SIP account. For example, the first work place will have 101 SIP device, the second 104 SIP device. In this case

Talal and Hamid day:

• Talal may use 101 without any extra actions; Hamid picks up the phone 104 and dial some secure code: now 104 acts as 102 or

• Talal picks up the phone 104 and dial some secure code: now 104 acts as 101; Hamid picks up the phone 101 and dial some secure code: now 101 acts as 102

Hamid and Dmitri day:

• Hamid picks up the phone 104 and dial some secure code: now 104 acts as 102; Dimitry picks up the phone 101 and dial some secure code: now 101 acts as 103 or

• Hamid picks up the phone 101 and dial some secure code: now 101 acts as 102; Dimitry picks up the phone 104 and dial some secure code: now 104 acts as 103

Extension 104 in this example is redundant: just for demonstration SIP account and employee difference. It is possible to have 3 extensions (employees) 101,102,103 and only 2 real SIP devices (for example 101 and 102)

How to test 'Dynamic Binding of the caller to employee'

queue configuration example is here
Extension Number - Queue

full queue parameters description are here
Queue (/queue/)

According to it you may do this binding by this queue configuration checkbox

How to test 'Call rating after call ending'

Currently you may do it using administrative interface only (including it into the client interface is in progress). Parameters for it:

All about quality rate is here
Conversation Rating (/quality rate/)

Call management directly from the phone

Dialing command are here
Hotkeys
You may configure Pickup/whispering/eavesdropping permissions via administrative interface here

Call management via API

API methods are here
Current Calls (/current_calls/)

See the Presence of Colleagues

Enable presence functionality for client in administrative interface and configure presence (dialog or register) according to you softphone/hardphone manual

Conferences

You may use “permanent“ conference extension or create temporal conference. According to
Conference (/conference/)
Dialing commands are here
Hotkeys

WebRTC

You may use any WebRTC client. If you use sip.view.ucom4b.com for you “classic“ phones, then for WebRtC client it looks like wss://sip.view.ucom4b.com
to be transfered to a new Space - Using the WebRTC

Web Call / API Initiation

Callback (/callback/)

Receive / send faxes via web interface / API

Using client interface:

Using API:

Fax (/fax/)

Receive alerts for missed calls in the mail

To configure alerts using client interface:

Generating PBX events for integration with third-party systems

Here is event description and testing example
Extension Number Events (/extension/.../event/)

Some event logic description
Event Logic on Extension Numbers

2 levels of web interface / API: for PBX administrator and employee

You may create user for client and for extension. According to user type you will be redirected to appropriate use page. For example, you can create employee level user in administrative interface

or using client interface:

There are API restriction according to user level permissions:

https://ucom4b.atlassian.net/wiki/spaces/RACD/pages/3571715

Receiving a variety of reports on calls through the web interface / API Please share where to find Call Center Reports/ procedure of API Testing

We have some reports in Client Interface:

The most detailed statistics on calls with a description of the fields can be obtained through the API:

https://ucom4b.atlassian.net/wiki/spaces/RACD/pages/28311707

Creation of specific call center reports and sending them using email are in progress (should be ready on June 2022)

Multi-domain setup

you may create a new domain according to

https://ucom4b.atlassian.net/wiki/spaces/AFSG/pages/203587610

Then choose this domain during client creation
https://ucom4b.atlassian.net/wiki/spaces/AFSG/pages/203161933

Registration of channels on other operators

After adding DID according to
https://ucom4b.atlassian.net/wiki/spaces/AFSG/pages/203456528

You may configure it for remote registration. Using Administrative Interface go to DIDs page and enter into the Registration configuration:

you will see current status and may create new registration paramenters:

Here is typical SIP provider registration parameters

Access to configuration change logs

You can do if via administrative interface. Here you can see logs of PUT/POST/DELETE methods and filter them out for some criterias

Configuration backups for cluster recovery

We install our software by ourselves. So recovery process currently possible only by us. In production all needed data will be inside '/backup' folder

Set email templates for clients

The mail templates are set in the Dealer level. Go to the dealer configuration page and select Templates section

You can choose type of the template and it is possible to use some variables (they are listed for each template under the Body area).

Restriction of access to the service by geography (GeoIP)

GeoIP restrication may be set for dealer (then all its clients will use it)

or for specific client

Client GeoIP value rewrite Dealer value. “*“ in Client value means: “no any GeoIP restriction for this client despite Dealer has some restrictions“

Voice recognition

To use voice recognition enable speech kit in client configuration:

Then in main IVR context, in option start create Voice helper IVR rule:

1. Set sound which will asks for voice dials. Voice can disrupt sound (it can be recognized while playing sound). Recognition works always with a small time delay, usually until recognition system detects silence.

2. maximum digits to listen to allow classic dial (phone terminal DTMF)

3. recommended timeout for voice dial

4. Set a result voice transcription like in example: to go to Options (as in example 1 or 2). All dial variants to same Options can be separated by '|'

Options 1 and 2 used in example must be created in the same context:

Temporary exception: options must be started with play sound rule first (it can be preloaded file with 1sec silence) - after this any other rule (like Transfer or any other) as in example: