Salto for
Zendesk
Articles
SHARE
Jude Kriwald
March 2, 2025
7
min read
In Part 1, we walked through an example Answer and analysed its essential functions.
In Part 2, we’ll go through some of the lesser-known but more powerful functions of an Answer that can really make the difference between a run of the mill bot that your customers are apprehensively expecting, and a best-in-class CX experience that pushes your Net Promoter Score higher and higher.
At the end of part 1, we worked our way from the top of an Answer to the bottom, ending with the Transfer function. It’s in this transfer function that a powerful but understated feature can be found; the tag field
Not only can you create a unique tag for each branch of your Answer, such as talk_to_human_online and talk_to_human_offline (these can be great for reporting), but you can also use it to populate ticket fields on the ticket that is about to be created.
Many Zendesk admins create ticket fields to capture the category or topic of a ticket. This helps route tickets to the right team and provides essential reporting with the data it needs.
Imagine that you have one branch of an Answer that supports customers wanting to initiate a return, and another for customers who have a complaint. Using tags, you can populate a custom ticket field, such as ticket category, with either category_refund or category_complaint. So long as the tag you use at the end of each brand matches the tag of a ticket field value, Zendesk will find that ticket field and populate it with the respective value according to the tag used.
Zendesk bots are meant to save your customers and agents time. With a little forethought like this, we can ensure that when a ticket does have to be solved by an agent, they can be forearmed with as much information as possible: customer name, email address, query type and so forth.
The method above works well to populate your custom fields when you want every ticket created from that specific branch to have a pre-defined value for its conditional fields.
What if, however, you want your ticket’s conditional fields to be populated not based upon the branch that a customer followed in your Answer, but instead by a value they selected or entered along the way? This works well when, as before, you want to capture all the relevant information from your customer, but you don’t necessarily want or need to send them down different branches based on their answers. This can massively simplify the Answers you build, allowing more variables to exist within a single branch, rather than having to build a new branch for each possible variable.
An example of this might be towards the end of your flow. Let’s imagine a customer has told the bot they’d like to return an item. The final stage of your process is to ask the customer whether they’d like a refund to their original payment card, credit applied to their account, or a replacement item sent out.
With a custom field set up to capture “Return Outcome”, we can build a step into our Answer that asks the Customer to fill out their desired return outcome.
Add a new “Ask for Details” step before the Transfer step.
In the drop-down, select the custom field that you want the customer to populate.
That’s it! It’s that simple. Now, when the ticket is created after the upcoming Transfer step, its Return Outcome field will be populated with whatever your customer selected, saving your agents a huge amount of time, and ensuring that the correct SLAs and routing are automatically applied.
If the customer selected “refund to payment card”, for example, the ticket can be routed to the finance team, whereas, if they selected that they’d like a replacement product, the fulfilment team can be assigned the ticket.
You could, of course, go one step further, and send a message via API to Shopify, or whichever system you use, to enact the return based on the selection above, and then skip the ticket creation altogether. More on that below.
It’s worth remembering that one of the key motivators behind having a truly high-performing bot is to reduce the workload on your CS team, especially when it comes to the more repetitive questions which bots are so well-suited to answering.
With this in mind, it’s essential to get familiar with how Answer Bot can check if, by whatever means, the bot has actually resolved the customer’s query. If so, we don’t need to get to the Transfer stage and we can save a ticket ever being created.
Although it’s probably one of the simplest functions available in the bot, it’s arguably the most important as, without it, all you're really doing is creating a delay before your customer inevitably reaches your CS team, without deflecting any of the inbound queries.
Click on Add Step again and then “Ask if question resolved”.
From here, you’ll see the simple question that the bot can ask the customer to check if the issue has been resolved. I suggest rewording it, as I have done below, to something that matches your brand’s tone of voice and is also sensitive to the context of what your bot and the customer have just been discussing.
The good news is that if a customer selects the resolved option, the flow can end (with a follow-up message if you wish) and no ticket is created for your team to handle. You can monitor the success of your bot in automatically resolving conversations on the Insights tab (at the same level as the Answers tab). It's worth noting that a conversation resolved this way counts as an Automated Resolution, of which your account will only have so many available before they become chargeable.
As your Answers grow, you’ll occasionally find yourself a little bit lost as to where exactly in the Answer you are. This is where the overview window (in the bottom right) comes in. Not only does it quickly show where you are (the example below is from a typical, fairly well-established Answer that I built for one of my clients), but you can also drag the white highlight section to quickly move around the Answer branches.
You can also use the zoom button in the bottom left or your scroll wheel to quickly zoom out and back in on the area you’re after.
With these new skills in your armory, have a go at sketching out an Answer flow to help your customers on your most prolific use case to begin with. Add in which Answer functions you could use to empower the bot, and then have a go at building it in the Answer builder. You’ll be amazed at how quickly you can create a powerful, fun and insightful bot that delights both your customers and your finance department!
Salto for
Zendesk
Zendesk
SHARE
Jude Kriwald
March 2, 2025
7
min read
In Part 1, we walked through an example Answer and analysed its essential functions.
In Part 2, we’ll go through some of the lesser-known but more powerful functions of an Answer that can really make the difference between a run of the mill bot that your customers are apprehensively expecting, and a best-in-class CX experience that pushes your Net Promoter Score higher and higher.
At the end of part 1, we worked our way from the top of an Answer to the bottom, ending with the Transfer function. It’s in this transfer function that a powerful but understated feature can be found; the tag field
Not only can you create a unique tag for each branch of your Answer, such as talk_to_human_online and talk_to_human_offline (these can be great for reporting), but you can also use it to populate ticket fields on the ticket that is about to be created.
Many Zendesk admins create ticket fields to capture the category or topic of a ticket. This helps route tickets to the right team and provides essential reporting with the data it needs.
Imagine that you have one branch of an Answer that supports customers wanting to initiate a return, and another for customers who have a complaint. Using tags, you can populate a custom ticket field, such as ticket category, with either category_refund or category_complaint. So long as the tag you use at the end of each brand matches the tag of a ticket field value, Zendesk will find that ticket field and populate it with the respective value according to the tag used.
Zendesk bots are meant to save your customers and agents time. With a little forethought like this, we can ensure that when a ticket does have to be solved by an agent, they can be forearmed with as much information as possible: customer name, email address, query type and so forth.
The method above works well to populate your custom fields when you want every ticket created from that specific branch to have a pre-defined value for its conditional fields.
What if, however, you want your ticket’s conditional fields to be populated not based upon the branch that a customer followed in your Answer, but instead by a value they selected or entered along the way? This works well when, as before, you want to capture all the relevant information from your customer, but you don’t necessarily want or need to send them down different branches based on their answers. This can massively simplify the Answers you build, allowing more variables to exist within a single branch, rather than having to build a new branch for each possible variable.
An example of this might be towards the end of your flow. Let’s imagine a customer has told the bot they’d like to return an item. The final stage of your process is to ask the customer whether they’d like a refund to their original payment card, credit applied to their account, or a replacement item sent out.
With a custom field set up to capture “Return Outcome”, we can build a step into our Answer that asks the Customer to fill out their desired return outcome.
Add a new “Ask for Details” step before the Transfer step.
In the drop-down, select the custom field that you want the customer to populate.
That’s it! It’s that simple. Now, when the ticket is created after the upcoming Transfer step, its Return Outcome field will be populated with whatever your customer selected, saving your agents a huge amount of time, and ensuring that the correct SLAs and routing are automatically applied.
If the customer selected “refund to payment card”, for example, the ticket can be routed to the finance team, whereas, if they selected that they’d like a replacement product, the fulfilment team can be assigned the ticket.
You could, of course, go one step further, and send a message via API to Shopify, or whichever system you use, to enact the return based on the selection above, and then skip the ticket creation altogether. More on that below.
It’s worth remembering that one of the key motivators behind having a truly high-performing bot is to reduce the workload on your CS team, especially when it comes to the more repetitive questions which bots are so well-suited to answering.
With this in mind, it’s essential to get familiar with how Answer Bot can check if, by whatever means, the bot has actually resolved the customer’s query. If so, we don’t need to get to the Transfer stage and we can save a ticket ever being created.
Although it’s probably one of the simplest functions available in the bot, it’s arguably the most important as, without it, all you're really doing is creating a delay before your customer inevitably reaches your CS team, without deflecting any of the inbound queries.
Click on Add Step again and then “Ask if question resolved”.
From here, you’ll see the simple question that the bot can ask the customer to check if the issue has been resolved. I suggest rewording it, as I have done below, to something that matches your brand’s tone of voice and is also sensitive to the context of what your bot and the customer have just been discussing.
The good news is that if a customer selects the resolved option, the flow can end (with a follow-up message if you wish) and no ticket is created for your team to handle. You can monitor the success of your bot in automatically resolving conversations on the Insights tab (at the same level as the Answers tab). It's worth noting that a conversation resolved this way counts as an Automated Resolution, of which your account will only have so many available before they become chargeable.
As your Answers grow, you’ll occasionally find yourself a little bit lost as to where exactly in the Answer you are. This is where the overview window (in the bottom right) comes in. Not only does it quickly show where you are (the example below is from a typical, fairly well-established Answer that I built for one of my clients), but you can also drag the white highlight section to quickly move around the Answer branches.
You can also use the zoom button in the bottom left or your scroll wheel to quickly zoom out and back in on the area you’re after.
With these new skills in your armory, have a go at sketching out an Answer flow to help your customers on your most prolific use case to begin with. Add in which Answer functions you could use to empower the bot, and then have a go at building it in the Answer builder. You’ll be amazed at how quickly you can create a powerful, fun and insightful bot that delights both your customers and your finance department!