Our team is trying to design a custom report that should have a similar structure of the Queues Performance report but with other custom metrics like the number of calls within the Service Level every interval of 15, 30 or 60 minutes.
Would you please recommend us a possible strategy that we can implement in order not to only get all the interactions involved in those metrics but also the agreggate metrics, so that we can display a custom view with this data and the additional metrics per every interval?
Finally, would you please give us some well-known best practices you have implemented during the request building of this or similar reports, based on your experience, so that we do not trip up by missing something relevant? We are requesting this because in our approach the team is missing some interactions in some interval filters.
Despite having run the queries every 30 minutes our team usually does not have the same information we can bore out by seeing the Queues Performance Metrics Report. Usually the operation check the information at 15h and only compare the intervals of the morning, sometimes the number of interactions recorded per every 30 minutes is not the same of the report our team is building; so at the end of the day (23h) our team has been running again those queries so that we can get the information fixed or updated.
I apologize for the delay in answering this. With the hustle and bustle of the forum, we are catching up on a backlog of questions. I am going to review this and also talk with our analytics team to get you answer.
Thanks,
John Carnell
Manager, Developer Engagement
I'll be happy to assist you, but first can you confirm my understanding that you are wanting aggregate/numerical data as well as detail data -- conversation ID, date, and other data like you'd find in the Interactions view & report? It sounds like that is the case and that the interactions do not line up with the aggregates. If that is the case, my hunch for the data discrepancy is that conversation detail data is anchored to the conversation start time, while the aggregate metrics are emitted at the time that the activity is completed. For example, Service Level updates are made when the conversation is answered or abandoned, but Handle updates are made when the conversation is wrapped up, so those updates for a single conversation may fall into multiple different buckets of time. When you get into asynchronous interactions such as email, this is more prevalent.
Thank you so much for your reply.
No, our team is trying to developing the same Queues Performance Metrics Report that can be found in the Queue Performance option of the Reports menu in the Web App of PureCloud, but with additional fields like service level, attendant level, and abandon - that can be found by querying the aggregates API - for all queues in intervals of 15, 30 and 60 minutes (thats the main difference between both).
In spite of the fact we tested that this morning and we found consistent information, Our team would like to know the Genesys opinion about the way our team is building it and the best practices related to this kind of queries, because every hour (interval of 60min) or half of an hour (intervals of 15m 30m) our team is requesting this endpoint using the query structure that I posted above.
Our team needs that so that does not trip up by missing something relevant. We are requesting this because in our approach the team is missing some interactions counts in some interval filters (30 min) and we need to find the main cause of this problem, either if is an issue with the query or with the processing our team has been doing.