Best API for IVR Resolved Calls

[MFord]

Hi,

I'm looking for the best way to capture the sum of calls received to all DNIS's, grouped by DNIS for a given time frame. I believe the POST /api/v2/analytics/conversations/details/query endpoint will contain that but is there another endpoint we can use to return that data?

Thanks

[Jerome.Saint-Marc]

Hello,

I would say requesting metrics with Conversation Aggregate query.
Probably with a groupBy on dnis, and a filter with predicates for mediaType == voice and direction == inbound.

You can also use Granularity to partition the results into intervals.

Regards,

[MFord]

Thanks for the response @Jerome.Saint-Marc . Is there a way to construct the query to exclude calls that ended up in a queue (resolved in the IVR)? We'll be using the same API to get queue-level metrics but would like to avoid double counting.

[Jerome.Saint-Marc]

There is possibly a way - playing with filter, metrics and groupBy (maybe getting more results than needed and filtering after) but I don't know for sure.
Conversation Aggregate is a bit tricky when playing with filter, dimensions and metrics. Like with tIvr, being an IVR participant metric, the filters will apply to that participant structure. Requesting tIvr for conversations where queueId does not exist would still be bring all conversations going via IVR and then going to ACD Queue or not (as queueId is not an attribute of the IVR participant structure in conversation details).
So asking IVR and ACD related metrics, and then doing a grouping, might allow to get results with both IVR and ACD and some with IVR only.

I am thinking that the Flow Aggregate might be a better approach in your case. I haven't used this aggregate endpoint often I must say.
The nFlow metric counts the number of times you enter a flow (so a call that goes through Flow1 and is then transferred to Flow2 - this counts as 2). So I don't think you would use this.
But you could request tFlowDisconnect. From what I see, you will have a tFlowExit if you exit your flow via an a transfer block, and tFlowDisconnect if the call is disconnected while in the IVR (either because customer hangs up or because you have used a Disconnect block in the ArchitectFlow).

So a Flow Aggregate, requesting tFlowDisconnect, with a groupBy on dnis, and a filter on mediaType == voice and originatingDirection == inbound.
The stat which is returned contains a count attribute - this will give you the number of times a customer disconnected while in the IVR (because customer hung up or because Architect flow invoked the Disconnect block).
Still, if you have a call going through the IVR, an ACD Queue, that gets distributed to an agent, and then is transferred to an IVR flow (where customer will be disconnected), the request above would count 1 for that call (on tFlowDisconnect).

Hope this helps.

Regards,