Salto for
Zendesk
Articles
SHARE
Jude Kriwald
October 3, 2023
6
min read
In this article, we’ll cover the different ways to build your skills as a Zendesk administrator and the practical steps you can take within Zendesk to learn its intricacies without breaking your live setup. We’ll also discuss how to get help when you just can’t work out the problem yourself.
We’ll look at growing your Zendesk skills organically “on the job” whilst working as part of a broader role which requires a small bit of Zendesk work. This has the benefit of allowing you to learn organically and without the need to dedicate extra time and money towards a specialised course.
In our next series, we’ll talk about how to take a more intentional approach, using online resources, courses and programmes to quickly build your skills up to the level required to administer multiple Zendesk environments.
Like myself, many experienced Zendesk admins never set out to learn Zendesk with the initial aim of turning their Zendesk skills into a reliable source of income. Instead, many Zendesk admins begin their journey as a member of a company’s operations or customer service team. This will often be a full-time, in-house (employed) role such as a customer service team leader, operations associate or operations manager.
These roles are multifaceted and often don’t focus solely on Zendesk, at least to begin with. My story is a good example. I was at Deliveroo in 2015 when the business was tiny compared to its size today. Having started out as a cyclist delivering food, I was soon asked to join the team in the office as an ops associate. A small part of my role was to answer emails from riders, using Gmail. Riders would also often text or call my phone.
Sooner or later, someone suggested that we should try out Zendesk as our Gmail was getting out of control and we were getting fed up using separate mobile phones to talk to riders.
The task was initially a straightforward one. I was assigned one agent to help me answer tickets and was told to figure out how to make Zendesk work. Bear in mind that we were still very small, and only needed Zendesk’s basic features to improve our situation from Gmail, so the task was quite straightforward. I set up views to distinguish riders based on their location within London, and created our first macros to respond to riders more easily and helpfully. This was already an improvement on our previous setup. I quickly found that I liked the black-and-white nature of configuring Zendesk. You set rules and it performs actions based on them.
Fast forward three years and I’d moved from an operations associate with one agent helping me, to an ops manager and then Head of Support operations with 200+ staff across the UK and Philippines helping our riders 24 hours a day using Zendesk. By that point, our Zendesk setup was incredibly complex with multiple bespoke configurations and integrations applied to it.
The point here is that if I’d been asked to take on Zendesk at that stage, when we had 200+ staff and a very complex instance of Zendesk Enterprise running, I would have had no chance. Instead, I was fortunate enough to start at the shallow end, with a basic setup using the Zendesk Team plan. As the business grew and our requirements changed, I was able to learn new Zendesk skills one at a time.
I did this with extensive research online, mostly via Google. We didn’t have access to a sandbox for a lot of my development, meaning I had to find innovative ways to test new configurations without potentially impacting the thousands of tickets and calls we were receiving per day.
This in-house, learn-as-required approach also benefited my employer in that they could assign responsibility over Zendesk to someone whose ability and time spent on it could grow as required. This is preferable over hiring a full-time Zendesk admin at the start as this would have been overkill with not enough Zendesk-only work to justify the salary.
Similarly, hiring a contractor to run Zendesk from the start would have been risky as the contractor is less tied in to sticking around and will have a less intricate knowledge of the company’s operational requirements.
Let’s discuss the innovative methods you can use to test configurations without a sandbox, as well as the best ways to get help when you’re stuck and a key review of the attitude required to learn quickly.
One simple way of testing new features, without a sandbox, is to limit the new configuration so that it only applies to tickets you send, not any other requester. Imagine you want to test a new inbound email trigger. Create the trigger as you think it needs to be set up. Before you save it, add one final condition to the “ALL” section. The condition should state something like: Comment description contains the string “test_by_jude_123” (or any other string which has 0% chance of appearing in a ticket from a real requester).
With this, you can go ahead and use a dummy email address to send a ticket to Zendesk and see how the trigger works. Be sure to include your unique string to ensure the experimental trigger fires. An alternative to the unique string condition is to specify that the requester must be an admin, but this can sometimes have unintended consequences if another admin is unaware of your testing. Zendesk can also sometimes treat tickets created by agents/admins differently, so be sure to test extensively.
For new configurations that can’t benefit from being filtered in this way, Zendesk does offer us some built-in options for ensuring our testing doesn’t impact live tickets/agents if it goes wrong. Macros and views, for example, both have the option of being limited so that they are only visible to you. Make use of these for testing before setting any new features live.
Unlike other roles within your company, chances are there isn’t anyone else who has as good or better knowledge of Zendesk as you do - so asking a colleague for help is often not possible. If you get particularly stuck and Google can’t help you either, there’s always Zendesk’s own support, normally delivered via live chat/email. The speed of response will depend on two variables: the Zendesk plan you’re on and the severity of the issue you report.
In the top right of any Zendesk user interface is a small person icon. Click on this and then “Get help”. This will open up a chat box that will allow you to share details of your issue, as well as whether the issue is minor, major or severe.
Arguably the most essential element to becoming a Zendesk expert with this approach is having the right attitude. It’s essential that you are willing to think outside the box, test new ideas, and don’t be afraid of temporarily breaking something (I did this lots in my early days). Zendesk has so many options, and each company’s use case is so unique, that it’s likely you’ll have to get experimental and really put your mind to the challenge of making Zendesk's various features click together in a way that you can’t read about online. Be brave and experiment! If you try something and it works - great, you’ve solved the problem. If you try something and you break the system, undo it and take note of what you’ve learned about Zendesk in the process.
As part of your experimentation and attempts to create new Zendesk configurations, things will go wrong. That’s not necessarily a bad thing as it contributes to your long-term goal of learning more Zendesk skills. If you can work out how to fix your Zendesk issues now, you’ll probably be very well placed to work out someone else’s (e.g. a future employer’s or a future client’s) Zendesk problems in the future. Not sure if something works this way or that way in Zendesk? Probe it until you know for sure.
If you need help troubleshooting unexpected errors in Zendesk, check out my previous articles on how to do that here.
In our next article, we’ll talk about how to take a more formal approach to learning Zendesk skills, using online resources, courses and programmes to quickly build your abilities up to the level required to administer multiple Zendesk environments.
Salto for
Zendesk
Zendesk
SHARE
Jude Kriwald
October 3, 2023
6
min read
In this article, we’ll cover the different ways to build your skills as a Zendesk administrator and the practical steps you can take within Zendesk to learn its intricacies without breaking your live setup. We’ll also discuss how to get help when you just can’t work out the problem yourself.
We’ll look at growing your Zendesk skills organically “on the job” whilst working as part of a broader role which requires a small bit of Zendesk work. This has the benefit of allowing you to learn organically and without the need to dedicate extra time and money towards a specialised course.
In our next series, we’ll talk about how to take a more intentional approach, using online resources, courses and programmes to quickly build your skills up to the level required to administer multiple Zendesk environments.
Like myself, many experienced Zendesk admins never set out to learn Zendesk with the initial aim of turning their Zendesk skills into a reliable source of income. Instead, many Zendesk admins begin their journey as a member of a company’s operations or customer service team. This will often be a full-time, in-house (employed) role such as a customer service team leader, operations associate or operations manager.
These roles are multifaceted and often don’t focus solely on Zendesk, at least to begin with. My story is a good example. I was at Deliveroo in 2015 when the business was tiny compared to its size today. Having started out as a cyclist delivering food, I was soon asked to join the team in the office as an ops associate. A small part of my role was to answer emails from riders, using Gmail. Riders would also often text or call my phone.
Sooner or later, someone suggested that we should try out Zendesk as our Gmail was getting out of control and we were getting fed up using separate mobile phones to talk to riders.
The task was initially a straightforward one. I was assigned one agent to help me answer tickets and was told to figure out how to make Zendesk work. Bear in mind that we were still very small, and only needed Zendesk’s basic features to improve our situation from Gmail, so the task was quite straightforward. I set up views to distinguish riders based on their location within London, and created our first macros to respond to riders more easily and helpfully. This was already an improvement on our previous setup. I quickly found that I liked the black-and-white nature of configuring Zendesk. You set rules and it performs actions based on them.
Fast forward three years and I’d moved from an operations associate with one agent helping me, to an ops manager and then Head of Support operations with 200+ staff across the UK and Philippines helping our riders 24 hours a day using Zendesk. By that point, our Zendesk setup was incredibly complex with multiple bespoke configurations and integrations applied to it.
The point here is that if I’d been asked to take on Zendesk at that stage, when we had 200+ staff and a very complex instance of Zendesk Enterprise running, I would have had no chance. Instead, I was fortunate enough to start at the shallow end, with a basic setup using the Zendesk Team plan. As the business grew and our requirements changed, I was able to learn new Zendesk skills one at a time.
I did this with extensive research online, mostly via Google. We didn’t have access to a sandbox for a lot of my development, meaning I had to find innovative ways to test new configurations without potentially impacting the thousands of tickets and calls we were receiving per day.
This in-house, learn-as-required approach also benefited my employer in that they could assign responsibility over Zendesk to someone whose ability and time spent on it could grow as required. This is preferable over hiring a full-time Zendesk admin at the start as this would have been overkill with not enough Zendesk-only work to justify the salary.
Similarly, hiring a contractor to run Zendesk from the start would have been risky as the contractor is less tied in to sticking around and will have a less intricate knowledge of the company’s operational requirements.
Let’s discuss the innovative methods you can use to test configurations without a sandbox, as well as the best ways to get help when you’re stuck and a key review of the attitude required to learn quickly.
One simple way of testing new features, without a sandbox, is to limit the new configuration so that it only applies to tickets you send, not any other requester. Imagine you want to test a new inbound email trigger. Create the trigger as you think it needs to be set up. Before you save it, add one final condition to the “ALL” section. The condition should state something like: Comment description contains the string “test_by_jude_123” (or any other string which has 0% chance of appearing in a ticket from a real requester).
With this, you can go ahead and use a dummy email address to send a ticket to Zendesk and see how the trigger works. Be sure to include your unique string to ensure the experimental trigger fires. An alternative to the unique string condition is to specify that the requester must be an admin, but this can sometimes have unintended consequences if another admin is unaware of your testing. Zendesk can also sometimes treat tickets created by agents/admins differently, so be sure to test extensively.
For new configurations that can’t benefit from being filtered in this way, Zendesk does offer us some built-in options for ensuring our testing doesn’t impact live tickets/agents if it goes wrong. Macros and views, for example, both have the option of being limited so that they are only visible to you. Make use of these for testing before setting any new features live.
Unlike other roles within your company, chances are there isn’t anyone else who has as good or better knowledge of Zendesk as you do - so asking a colleague for help is often not possible. If you get particularly stuck and Google can’t help you either, there’s always Zendesk’s own support, normally delivered via live chat/email. The speed of response will depend on two variables: the Zendesk plan you’re on and the severity of the issue you report.
In the top right of any Zendesk user interface is a small person icon. Click on this and then “Get help”. This will open up a chat box that will allow you to share details of your issue, as well as whether the issue is minor, major or severe.
Arguably the most essential element to becoming a Zendesk expert with this approach is having the right attitude. It’s essential that you are willing to think outside the box, test new ideas, and don’t be afraid of temporarily breaking something (I did this lots in my early days). Zendesk has so many options, and each company’s use case is so unique, that it’s likely you’ll have to get experimental and really put your mind to the challenge of making Zendesk's various features click together in a way that you can’t read about online. Be brave and experiment! If you try something and it works - great, you’ve solved the problem. If you try something and you break the system, undo it and take note of what you’ve learned about Zendesk in the process.
As part of your experimentation and attempts to create new Zendesk configurations, things will go wrong. That’s not necessarily a bad thing as it contributes to your long-term goal of learning more Zendesk skills. If you can work out how to fix your Zendesk issues now, you’ll probably be very well placed to work out someone else’s (e.g. a future employer’s or a future client’s) Zendesk problems in the future. Not sure if something works this way or that way in Zendesk? Probe it until you know for sure.
If you need help troubleshooting unexpected errors in Zendesk, check out my previous articles on how to do that here.
In our next article, we’ll talk about how to take a more formal approach to learning Zendesk skills, using online resources, courses and programmes to quickly build your abilities up to the level required to administer multiple Zendesk environments.