queueDuration 0 in Webex CC search API results

[kseraphine]

I'm using the Postman collection and the webex-contact-center-api-samples repo (both of which have been very helpful) to familiarize myself with the search API.  I'm getting unexpected results for a task query in that the `queueDuration`  field value is always 0. 

Here's an example query:

task(
    filter: {
      and: [
        { channelType: { equals: telephony } }
        { status: { equals: "parked" } }
        { direction: { equals: "INBOUND" } }
        { isActive: { equals: true } }
      ]
    }
  ) {
    tasks {
      id
      origin
      destination
      isActive
      direction
      totalDuration
      queueDuration
      lastEntryPoint {
        id
        name
      }
    }
  }
}

Which returns:

{
    "data": {
        "task": {
            "tasks": [
                {
                    "id": "75519cf4-253f-437b-a473-f239816756f7",
                    "origin": "+XXXXXXXXXXX",
                    "destination": "+XXXXXXXXXXX",
                    "isActive": true,
                    "direction": "INBOUND",
                    "totalDuration": 0,
                    "queueDuration": 0,
                    "lastEntryPoint": {
                        "id": "AXpoGICUT669fVVELlIA",
                        "name": "Test Tele EP4"
                    }
                }
            ]
        }
    }
}

I'm querying for active calls because ultimately I want to build a query to aggregate the count and max duration of queued calls in realtime.  Even when I query for the same call after the call ends, the queueDuration is still 0 (but the totalDuration is a non-zero value).

Is this expected?  If so, is that another way to do an aggregated query for active tasks? 

Thanks!

dddd

[smeegada1]

If you have unique callerID with Timestamp, this can be implemented using Finesse Gadget.

[Arunabh Bhattacharjee]

Hi @kseraphine 

From an internal discussion, these durations are only being calculated if the call has exited the parked state.

Hence it shows up after the status isActive = false from the contact session. 

This is from all the events in the contact session record that help calculate aggregates post processing.

Could you please confirm the use case? Are you polling for queueTime of Active / realtime contacts in the queue?

This API will need to be enhanced to allow for Realtime queue durations - at this point it is a session record (task = contact session) and the metrics are being calculated after the fact.

We currently do not have a Contact Activity endpoint, (CAR) that would give you the events of new, ivr-connected, parked so that one can calculate the timestamps between them to find out the ivr Duration (selfServeDuration) or queueDuration.

Thanks & Regards,

Arunabh.

[Arunabh Bhattacharjee]

Another important aspect is that the queueDuration does return correctly for voice Queues.

From your screenshot, it seems like the queue was created with an older backend service.

Please try this out:

- Create a new queue. QueueID should be in the GUID format.

- Recreate the same test with isActive=false (post call end or post exiting the parked state.

It should return a value. Attaching some screenshots from internal testing. 

I would suggest opening a TAC case if you're not getting queueDurations for a specific Queue ID (e.g the queue ID in your screenshot was an older queue created on WebexCC before a cutover took place last year)

[kseraphine]

Thanks for the quick reply. 

I created a new queue and updated the flow. I'm still a bit confused on what to expect because you say "Recreate the same test with isActive=false (post call end or post exiting the parked state" however your first screenshot shows an active, parked call with a queueDuration value.

Below are the results for the same queries with an active call and after. I do not have queueDuration for my parked call as you did. Can you clarify if I should see queueDuration for the parked query?  If so, I can open a TAC case as you suggested.

Also, do you know why the direction ins "INBOUND" (upper case) for active tasks but "inbound" (lower case) for inactive tasks? That seems odd and doesn't match your examples.

Thanks

 

 

[Arunabh Bhattacharjee · Accepted solution]

The issue with the different cases can possible be an existing defect, if possible it would be good to raise a TAC case for the data integrity issue on your system. 

For the durations, the consensus today is that the metrics for contact Session is calculated post call.

For events in task:parked - perhaps you can use the webhook for task:new to task:parked to maintain the durations.

Other idea is to use Date.now() - createdTime to calculate durations since you get the CSR data.

Let me know if those are suitable workarounds.

Realtime websocket push based notifications are still on the roadmap and published in the coming soon for Webex Contact Center.

[kseraphine]

Yes, calculating the duration using the createdTime is a suitable workaround. Thanks for you help.

[kseraphine]

The use case is:

Customer wants a dashboard that shows in real-time the number of contacts and the longest hold time for each queue. They will use this information to reskill agents on the fly to adjust to conditions. 

I don't think the customer needs to differentiate IVR duration from queue duration so, if necessary, I can use the `createdTime` of each contact to determine the longest hold time. It would just be more convenient to use a aggregate/group by query.

Also, if it takes multiple pages to get all the active contacts, API throttling may become a problem because the customer will want the data to refresh frequently.

[Arunabh Bhattacharjee]

True, today the total Contacts per page is limited to 300 - with a maximum of 33 pages.

is it possible to get more than 300 active calls per queue?

I believe this threshold would be difficult to achieve based on SMB sizing and BHCA - if you filter by queue level.

Today the rate limit is set at 50 requests per minute as a default and it can be increased based on the Client ID level with a request to Cisco - permitting the use case is reviewed internally.

So you can still pull 33 pages worth of data in a single batch of search API calls without breaching the rate limit. 

[kseraphine]

This use case will be implemented in a desktop widget so my concern was requests from multiple instances.  For example, 20 instances refreshing every 30 seconds would fall under the 50 request limit only if the results are contained in a single page.

That said I don't think this system will approach 300 active contacts so it shouldn't be a problem in this case.  I thought the per page limit was 100 but now see that applies to agent session.

Thanks