ACD v1 usage

ACD v1 is the previous version of SmartQueue (ACD v2). It provides functionality to build call queues and process them by connecting to multiple operators. Though we recommend to use SmartQueue (ACD v2), Voximplant still fully support ACD v1 for existing customers.

1. Open Applications in the Voximplant control panel.
2. Go to your application and switch to the Queues tab.
3. Click Create queue in the upper right corner (or Create in the center of the screen). Name the queue, assign at least one user, and click Add to confirm the operation. Note that a queue name should be unique within your Voximplant developer account. In this example, the queue's name is "main".

Switch to the Scenarios tab and create a queue scenario with the following code:

First, we require the ACD module, then create a handler for an incoming call. Inside a handler we answer a call and when it connects, put this call to the queue via the enqueueACDRequest method. When an operator is reached, i.e., answers a call, we connect the caller with this operator. Finally, we place the handlers for cases when an operator rejects a call and either side of conversation hangs up.

To add some music while the customer waits in the queue, use the startPlayback method. To start background music, update the previous code as follows (lines 11 and 12):

Music automatically stops after operator answers and new audio source is connected to call via sendMediaBetween.

There are the following statuses in ACD:

Note that all the statuses should be set manually, except for Banned – it is set automatically. The Online status is set automatically only when an operator has logged in.

To summarize, all statuses except for Ready, Offline, and Banned work the same, so different names can be used to track statistics.

In Web SDK, status can be set via the getOperatorACDStatus method and changed via setOperatorACDStatus. However, you can retrieve an operator status from a JS scenario directly via the getStatus method.

Additionally, you can track changing statuses via the ACDStatusUpdated event. The event is triggered when the ACD operator status is changed due to the setOperatorACDStatus call (on any SDK logged in under that user) or due to a server-side event (the operator is banned because of a missed call).

If you want to use management API, use the acd_status field of the UserInfoType structure returned by the /GetUsers method call now contains an up-to-date value of the current user's ACD status as a string.

In our demo web phone, operator status can be changed via a buttons row:

Look at the scheme below to familiarize with the status concept:

In the control panel, go to your application, and switch to the Queues tab. Here can see the list of your ACD queues with an arrow icon on the left. Click on it to expand stats for the queue:

There is a Report button on the right, click it to reveal the extended stats:

You can also request stats via management API, check the Queues methods. Here is an example of how to get the current ACD queue state:

You can implement queues with callback function for your customers. With this feature, a customer who waits in a queue can press a specific button and end the call but remain in the queue. When the customer reaches their turn, the scenario connects the customer to the operator via calling both sides.

Let us modify the code example from the first section:

This scenario processes inbound calls, but sometimes developers would like to put a call in a queue from a callback form. Let us do it via StartScenarios management API request and additional code in the scenario:

It is also possible to make requests to the session using media_session_access_url and get queue position updates to display it to the customer.