Reporting with Zendesk

This article will outline the methods for reporting on data from your call flows. It will show you how reporting can render complex data visible in Zendesk using tagging in global and local Automations.

It is recommended that you first read the article on Automations (linked just above), as the level of detail given here will be necessarily lower. 

This article will be split up into:

1. Planning and implementing a tagging system into your call flow
2. Examples of how this tagging is interpreted in Zendesk

1. Planning & implementing 

Depending on what data you would like to report, you can add tags to Zendesk tickets in two ways. Global Automations are triggered independently of which stage or module the call currently passes.

For example, if you create a Trigger which tests whether a caller dialed the emergency hotline number, a global Automation could be set up to add the tag "emergency_call" to the newly created ticket for that call. If you used a local Automation to try and make the same thing happen at a specific module, this would never be reliable as the call is never guaranteed to make it to that particular point.

In your list of global Automations, you would only need to ensure that your new Automation "Update - add emergency call tag" has the correct priority value, because a ticket has to have been opened first on which to perform the update! See below:

Now, however, we also want to report on a more specific instance in the call flow: we want to add a tag whenever a caller chooses to receive a certain instant SMS service. The Automation must be configured locally, because other automated SMS options exist within the flow. This one should add the tag "support_sms" to the current ticket:

The naming of this tag is significant; it cannot simply be "sms", as it would not allow you to differentiate between other SMS tags, ruining your reporting data. 

Now that these ticket update Automations are configured with your Zendesk integration, they will add tags to the relevant tickets for those calls, only when either condition is met. 

2. Reporting examples in Zendesk

The conditions, as we have seen above, are different for each case. For the first case, the condition was only that an inbound caller had dialed the emergency hotline number. The condition for the second tag to be added was that a particular SMS had been sent.

Let us say that a caller dials the emergency line, then realizes that their problem could be easily solved by the support SMS. They select the SMS option before reaching a agent. As soon as these actions take place, a ticket is created, updated and pushed to an agent. The left hand information panel of this ticket will look something like this:

The call data has been sent to Zendesk in real time, and differentiated to make them specific enough for clear analysis. But this is only really half of the job. The data has been reported, but is in no way presentable, as it exists only in individual tickets. 

There are various applications and products which will allow this data to be analyzed for BI, including dashboards to present metrics. For Zendesk customers with larger user deployments, GoodData is a built-in application for the analysis of your ticketing data. Its power allows for reporting on any aspect of a ticket or groups of tickets, and can display data in many ways.

In the example below from GoodData the data compared are calls missed and calls taken, shown in terms of tickets per month: 

The variables highlighted in the red box correspond to the tags added by Events on the babelforce platform.

Using the methods for global and local Events outlined above, any type of instance on a call can be turned into data, reported to your Zendesk and presented for analysis, all updating itself in real time.  

We put together a few articles for you, giving examples (below just a few) how to use GoodData to create your KPI.

• Intro to Gooddata and custom fields
• Average Handling time
• Service level reports