Skip to contentSkip to navigationSkip to topbar
Rate this page:
On this page

Dashboards


This section covers common requirements for real-time dashboards for a contact center.

There are two types of common reporting interfaces:

  • Dashboards - primarily visual graphs - Described in this document
  • Historical reports - primarily text based tables - Described here

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

dashboards page anchor

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:

  • Summary
  • Queues
  • Agents

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:

  • It is useful if the report auto-refreshes at a sensible cadence if left open.
  • For certain values it is useful for them to be truly real-time. We recommend using Twilio Sync for this function - using the event stream data from TaskRouter to populate a Sync map with the values needed. Note: in the future this will be an integrated feature of TaskRouter.
  • It is usefil if the screen can be set to a mode with a display suitable for acting as a 'wallboard' display (e.g. remove as much chrome/config as possible and just show graphs, or even just the real-time numbers blown up big)
  • It is useful to be able to configure a specific SLA for each graph, and use that to display whether the graph breaches over the SLA, and also color code the real-time figures if breaching the SLA

Building a real-time dashboard with TaskRouter Events and Sync

building-a-real-time-dashboard-with-taskrouter-events-and-sync page anchor

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

Data flow

data-flow page anchor
  1. TaskRouter generates the event and calls the Event Callback URL associated with the workspace
  2. This invokes the server side python app to consume the event and call the additional Twilio TaskRouter Statistics APIs to get aggregated statistics
  3. Next, the Sync documents are updated with changes using the Sync REST APIs
  4. The frontend web app subscribes to the same Sync documents for changes vis the Sync JS SDK
  5. When changes are detected by the frontend, the UI is updated

You can find a full working code example of this here: https://github.com/ameerbadri/twilio-taskrouter-realtime-dashboard(link takes you to an external page)

realtime dashboard.

The following table lists graphs which are often displayed on a summary dashboard.

GraphPurposeHow to get from TaskRouter Event StreamHow to get from TaskRouter stats API
Average waiting time for tasks by dateTo see the overall trend in waiting timeDerive from average TaskAge parameter from (reservation.accepted OR task.canceled) eventAvgTaskAcceptanceTime on the Workspace cumulative statistics
Average waiting time for tasks by queueTo 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 TaskQueueNameAvgTaskAcceptanceTime on the TaskQueu cumulative statistics
Average waiting time for tasks by day of weekTo see which days are busiest (for agent planning purposes)Derive from average TaskAge parameter from (reservation.accepted OR task.canceled) eventAvgTaskAcceptanceTime on the Workspace cumulative statistics with individual queries for each day
Average waiting time for tasks by hourTo 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 bucketAvgTaskAcceptanceTime on the Workspace cumulative statistics with individual queries for each hour of each day
Number of tasks queued (by hour)Derive from task.created eventTasksEnteredn 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 createdTasksEnteredn 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 IdleIt'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 / abandonedWaiting 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:

GraphPurposeHow to get from TaskRouter Event StreamHow 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 substract taskqueue.moved, and reservation.accepted events for the same taskSid.
Logged in workers (agents)Not possible
Tasks ReceivedCount of taskqueue.entered events and substract taskqueue.moved for the same taskSid.
Tasks HandledCount of reservation.accepted events for the given TaskQueueName
Tasks AbandonedCount of task.canceled events for the given TaskQueueName
Average abandon timeAverage of TaskAge for task.canceled events for the given TaskQueueName
Average call durationAverage of TaskAge for task.completed events for the given TaskQueueName
Agent statesAggregated view of WorkerActivityName from the most recent worker.activity.update events for each unique WorkerSid

Some graphs currently canot be extracted from TaskRouter data and need data to be stored yourself in a different database. These will be addressed in the TaskRouter roadmap:

  • Disposition Codes (calls)
  • Wrap-up Time (duration)
  • Calls answered (calls/hr)
  • Calls timed out (calls/hr)
  • Time in queued calls (%)
  • Time in internal calls (%)
  • Time in external calls (%)
  • Time in outgoing calls (%)
  • Time otherwise unavailable (%)
  • Time logged in (%)
  • Wrap-up Time*
  • Agent States

Some graphs currently canot be extracted from TaskRouter data and need data to be stored yourself in a different database. These will be addressed in the TaskRouter roadmap:

  • Disposition Codes (calls/hr)*

Rate this page: