It is recommended that you first read the article on Events (linked just above), as the level of detail given here will be necessarily lower.
This article will be split up into:
- Planning and implementing a tagging system into your call flow
- Examples of how this tagging is interpreted in Zendesk
1. Planning & implementing
Depending on what data you would like to report on, you can add tags to Zendesk tickets in two ways. Global Events are triggered independently of which stage or application the call is currently at.
For example, if you create a trigger which tests whether a caller dialed the emergency hotline number, a global Event could be set up to add the tag "emergency_call" to the newly created ticket for that call. If you used a local Event to try and make the same thing happen at a specific application, this would never be reliable as the call is never guaranteed to make it to that particular point.
In your list of global Events, you would only need to ensure that your new Event "Update - add emergency call tag" has the correct priority value. This is because there has to have been a ticket created first, on which to perform the update! See below:
As you can see, all of the 'Update ticket' Events come lower down the order than the 'Create ticket' Events, including our newly created Event which we've given a priority value of 680. This, along with the 'Wait' switch shown to the right of the above picture, ensures that the Events are tested and performed in order, waiting their turn.
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 Event must be configured locally, because there exist other automated SMS options 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 Events 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.