This section covers common requirements for real-time dashboards for a contact center.
There are two types of common reporting interfaces:
Twilio has a set of partners who can provide out of the box dashboards end reports, or you can build these yourself using the data and tools Twilio makes available.
For each recommended graph or table, this document lists how you would derive this from the TaskRouter event stream, OR how you would get it from the TaskRouter statistics APIs. You would typically use one mechanism or the other, dependent on what technology you are using for building this.
Dashboards are typically used by a supervisor 'on the floor' of the contact center. Because these are used for active management, they really need to include the real-time value of each statistic, as well as the historical graph.
A contact center dashboard would typically cover the following high level areas:
All the graphs should be able to be toggled between different time ranges. Ideally that should include down to the specific hour.
Additional things to consider when building this:
We would recommend that you use Twilio Sync to power your realtime dashboards, and populate the data in the Sync maps based on updates from the TaskRouter event stream
You can find a full working code example of this here: https://github.com/ameerbadri/twilio-taskrouter-realtime-dashboard
The following table lists graphs which are often displayed on a summary dashboard.
Graph | Purpose | How to get from TaskRouter Event Stream | How to get from TaskRouter stats API |
---|---|---|---|
Average waiting time for tasks by date | To see the overall trend in waiting time | Derive from average TaskAge parameter from (reservation.accepted OR task.canceled) event | AvgTaskAcceptanceTime on the Workspace cumulative statistics |
Average waiting time for tasks by queue | To see which queues have longest waiting time (in order to consider assigning more agents) | Derive from average TaskAge parameter from (reservation.accepted OR task.canceled) event filtered by TaskQueueName | AvgTaskAcceptanceTime on the TaskQueu cumulative statistics |
Average waiting time for tasks by day of week | To see which days are busiest (for agent planning purposes) | Derive from average TaskAge parameter from (reservation.accepted OR task.canceled) event | AvgTaskAcceptanceTime on the Workspace cumulative statistics with individual queries for each day |
Average waiting time for tasks by hour | To see which hours are busiest (for planning breaks) | Derive from average TaskAge parameter from (reservation.accepted OR task.canceled) event where timestamp on that event is within given bucket | AvgTaskAcceptanceTime on the Workspace cumulative statistics with individual queries for each hour of each day |
Number of tasks queued (by hour) | Derive from task.created event | TasksEnteredn the Workspace cumulative statistics with individual queries for each hour of each day | |
Number of tasks queued (by day of week) | Derive from task.created event where timestamp is time created | TasksEnteredn the Workspace cumulative statistics with individual queries for each day of week | |
Number of agents logged in (by time) | Derive from worker.activity.update and filter by WorkerActivityName is Idle | It's possible to create custom Activity States. Where this is true, you must use the REST API to fetch activity states and which ones map to available. | |
Number of agents logged in (by day of week) | Derive from worker.activity.update and filter by WorkerActivityName is Idle | ||
Number of agents logged in (by hour) | Derive from worker.activity.update and filter by WorkerActivityName is Idle | ||
Number of agents logged in (by Queue) | Not possible | ||
Total Number of tasks waiting / In progress / abandoned | Waiting tasks is tasks received a task.created event with no subsequent reservation.accepted for same task SID Abandoned tasks is number of task.canceled events Tasks in progress is number of reservation.accepted events with no subsequent task.completed for the same task SID |
It should be possible to view a larger number of stats broken down per queue. Selecting one queue at a time is OK. Being able to select multiple queues and have stats aggregated is beneficial.
There should be a graph for each of the following statistics:
Graph | Purpose | How to get from TaskRouter Event Stream | How to get from TaskRouter stats API |
---|---|---|---|
Waiting time (duration) | Derive from (reservation.accepted OR task.canceled) events with average of TaskAge for all tasks for given TaskQueueName | ||
Customers waiting (tasks) | Count of taskqueue.entered events and subtract taskqueue.moved, and reservation.accepted events for the same taskSid. | ||
Logged in workers (agents) | Not possible | ||
Tasks Received | Count of taskqueue.entered events and subtract taskqueue.moved for the same taskSid. | ||
Tasks Handled | Count of reservation.accepted events for the given TaskQueueName | ||
Tasks Abandoned | Count of task.canceled events for the given TaskQueueName | ||
Average abandon time | Average of TaskAge for task.canceled events for the given TaskQueueName | ||
Average call duration | Average of TaskAge for task.completed events for the given TaskQueueName | ||
Agent states | Aggregated view of WorkerActivityName from the most recent worker.activity.update events for each unique WorkerSid |
Some graphs currently cannot be extracted from TaskRouter data and need data to be stored yourself in a different database. These will be addressed in the TaskRouter roadmap:
Some graphs currently cannot be extracted from TaskRouter data and need data to be stored yourself in a different database. These will be addressed in the TaskRouter roadmap: