Salto for
Zendesk
Articles
SHARE
Jude Kriwald
June 28, 2023
3
min read
Read Part 1 and Part 2 of this series in our blog.
To add another attribute, we’ll need to use the row element, as adding another column to a column graph would get messy (you can try it to see for yourself)!
As before, under Rows, click “Add >”. Then search for “updater name” and select that option. This should break the report down further by those who updated the ticket
Now, if your report is anything like mine, you might panic as your report has largely disappeared, and lots of unintelligible names have appeared.
Whilst we have done everything correctly up to this point, our report has not returned the results we would logically expect. I have intentionally kept this step in to show you that, sometimes, Explore doesn’t work as expected, requiring us to be extra specific with what we want it to do.
What’s happened here is that Zendesk is showing us all the names of anyone who updated a ticket, not just agents. One would assume that the metric “agent updates” would only show updates by agents, but that doesn’t quite seem to be the case. It seems to be showing the names of anyone who has updated a ticket, including end-users.
In Explore, you’ll often find, by looking carefully, that metrics don’t fully align with what you’d expect them to, or even what they say in the official reference documentation.
This is easily fixed though. Knowing how to make Explore be extra specific, when you need it to, is an essential skill to producing accurate reporting. Let’s learn how to do it now.
Looking through the list of names of updaters, we’ll see that there are end-users included in there. Let’s remove them.
Add another filter at the top of the screen. This time, select Updater role.
Once you have selected it, click the grey filter you just created.
Next, select Agent to tell Explore to only show data where the role of the updater was an agent.
That’s much better! The Updater name selector no longer has hundreds of mysterious names populating it. Instead, we can see our two agents’ names.
Note that only one name is highlighted in the selector. Holding down the Shift key, click on the top and bottom names in the selector to tell Explore to show data for all of your agents.
That’s so much more useful. Now we can see, side by side, how many updates each of our agents are doing per day. The insights you draw from this are up to you and will depend on your team’s setup. One clear insight, although we can’t conclude its cause, is that Ellie consistently updates slightly more tickets per day than Mel.
This view is useful for comparing agent output but what if we want to see the team’s productivity as a whole, but still broken down by contribution per agent.
To do this, we can change the column chart to a stacked column chart.
Click on the Chart configuration button again, then select Chart
Then check Stacked.
Wait for it…
And there we have it, our first report, clearly detailing the number of updates made per day and per agent last month.
I’m all too aware that it can be confusing understanding when to use rows or columns. A simple way to visualise this is to imagine, or actually to make, your report as a table first.
This is also an excellent way to troubleshoot a report that isn’t working as you’d expect it. It shows you what’s really going on behind the scenes of the pretty graphs.
Select the Visualisation type button, then select Table.
Now, you can quite simply see where all four of your elements play their part on the output of the graph. Just like a spreadsheet, columns go along the top, rows down the side, with the metric in the middle. And all three of these can be affected by your filters.
When you’re happy with your report, rename your report at the top and centre, and then click Save in the top right corner.
If you click the arrow on the end of the button, you’ll see other options too, such as adding your report to a dashboard. Whilst you won’t be able to add your report to any of Zendesk prebuilt dashboards, you can add it to your own. We’ll cover how to create, organise and share your own dashboard in another article soon.
What a whirlwind! Over the course of three parts, we have covered why reports are useful, what datasets are and how to pick the right one, learned about the various elements that are used to build a report, and then practised putting them all together to create a beautiful, insightful report for your team.
We have barely touched the surface of what is possible with Explore, and will surely delve deeper into other aspects further down the line. As we saw, there are lots of quirks and tricks to be aware of when building in Explore, and it’s always worth sense-checking your reports as it's common for company leaders to make big decisions based on the reporting produced in Zendesk.
As a next step, I encourage you to try reproducing the above again on your own, and then creating your first report of your own, for something that might be useful, or just interesting, to you or your team.
Salto for
Zendesk
Zendesk
SHARE
Jude Kriwald
June 28, 2023
3
min read
Read Part 1 and Part 2 of this series in our blog.
To add another attribute, we’ll need to use the row element, as adding another column to a column graph would get messy (you can try it to see for yourself)!
As before, under Rows, click “Add >”. Then search for “updater name” and select that option. This should break the report down further by those who updated the ticket
Now, if your report is anything like mine, you might panic as your report has largely disappeared, and lots of unintelligible names have appeared.
Whilst we have done everything correctly up to this point, our report has not returned the results we would logically expect. I have intentionally kept this step in to show you that, sometimes, Explore doesn’t work as expected, requiring us to be extra specific with what we want it to do.
What’s happened here is that Zendesk is showing us all the names of anyone who updated a ticket, not just agents. One would assume that the metric “agent updates” would only show updates by agents, but that doesn’t quite seem to be the case. It seems to be showing the names of anyone who has updated a ticket, including end-users.
In Explore, you’ll often find, by looking carefully, that metrics don’t fully align with what you’d expect them to, or even what they say in the official reference documentation.
This is easily fixed though. Knowing how to make Explore be extra specific, when you need it to, is an essential skill to producing accurate reporting. Let’s learn how to do it now.
Looking through the list of names of updaters, we’ll see that there are end-users included in there. Let’s remove them.
Add another filter at the top of the screen. This time, select Updater role.
Once you have selected it, click the grey filter you just created.
Next, select Agent to tell Explore to only show data where the role of the updater was an agent.
That’s much better! The Updater name selector no longer has hundreds of mysterious names populating it. Instead, we can see our two agents’ names.
Note that only one name is highlighted in the selector. Holding down the Shift key, click on the top and bottom names in the selector to tell Explore to show data for all of your agents.
That’s so much more useful. Now we can see, side by side, how many updates each of our agents are doing per day. The insights you draw from this are up to you and will depend on your team’s setup. One clear insight, although we can’t conclude its cause, is that Ellie consistently updates slightly more tickets per day than Mel.
This view is useful for comparing agent output but what if we want to see the team’s productivity as a whole, but still broken down by contribution per agent.
To do this, we can change the column chart to a stacked column chart.
Click on the Chart configuration button again, then select Chart
Then check Stacked.
Wait for it…
And there we have it, our first report, clearly detailing the number of updates made per day and per agent last month.
I’m all too aware that it can be confusing understanding when to use rows or columns. A simple way to visualise this is to imagine, or actually to make, your report as a table first.
This is also an excellent way to troubleshoot a report that isn’t working as you’d expect it. It shows you what’s really going on behind the scenes of the pretty graphs.
Select the Visualisation type button, then select Table.
Now, you can quite simply see where all four of your elements play their part on the output of the graph. Just like a spreadsheet, columns go along the top, rows down the side, with the metric in the middle. And all three of these can be affected by your filters.
When you’re happy with your report, rename your report at the top and centre, and then click Save in the top right corner.
If you click the arrow on the end of the button, you’ll see other options too, such as adding your report to a dashboard. Whilst you won’t be able to add your report to any of Zendesk prebuilt dashboards, you can add it to your own. We’ll cover how to create, organise and share your own dashboard in another article soon.
What a whirlwind! Over the course of three parts, we have covered why reports are useful, what datasets are and how to pick the right one, learned about the various elements that are used to build a report, and then practised putting them all together to create a beautiful, insightful report for your team.
We have barely touched the surface of what is possible with Explore, and will surely delve deeper into other aspects further down the line. As we saw, there are lots of quirks and tricks to be aware of when building in Explore, and it’s always worth sense-checking your reports as it's common for company leaders to make big decisions based on the reporting produced in Zendesk.
As a next step, I encourage you to try reproducing the above again on your own, and then creating your first report of your own, for something that might be useful, or just interesting, to you or your team.