The Way of the Do-Reply: self-triage methods with Zendesk

In this follow-up post, we’ll demonstrate two no-AI methods to allow your user base to self-triage their uncategorized Zendesk requests. The first method is straightforward and will take advantage of triggers. The second – and more advanced – example is more complex and will use triggers, webhooks and a bit of Guide code customization.

In From ‘do not reply’ to ‘do reply’ we proposed that modern customer experience email campaigns should stop using ‘do-not-reply’ addresses altogether. We shared multiple examples of these ‘processes’, a few of them borderline ludicrous, even.

We also promised to share a couple of ways to allow users to speed up their queries by self-triaging and categorizing their own requests… And here we are! Let’s see two examples of configuring self-triage using Zendesk Support (and a bit of Guide customization).

Method 1: keywords

This method – introduced on the previous post – is a simplistic yet effective approach: a user responds to our do-reply; this triggers a specific ‘request received’ notification which contains a group of keywords that the requester can use to confirm the context of their request.

It may coexist with any other semantic identification triggers you already have set up. Depending on the use case, you may need to adapt the existing workflow so that things smoothly merge and make sense for the end-user experience.

How this workflow works

Users receive a no-reply kind of email communication from us (e.g. newsletters, update to our terms and conditions, non-transactional alerts related to their account/service, etc.).

Users may choose to respond to that email communication for any reason:

Because we may not know what this is about (it all depends on how detailed our triggers are), the ticket created is uncategorized:

This is where we choose the course of things. Here’s an example of what users receive after their reply (like that shown in the example above):

The user never receives an error email, a “mailer-daemon”, “address does not exist”, and so on (you can see the examples in the first post). Because we DO reply. Whether the person used an appropriate or pertinent channel or message to reach out, still, it’s a legitimate request. It’s on us to decide what to do with it.

That said, our ‘request received’ notification does state that this is a low priority inbox (consequently, reply times are above average). Most importantly, the template also invites them to speed up the process by replying with a specific keyword.

The user decides to play the game and responds with the relevant topic keyword, updating the ticket and therefore categorizing their request. Consequently, ticket priority changes and a new SLA policy may be applied:

With the proper triggers in place, we can easily fill in our Topic field with the appropriate value:

This process is quite simple: it requires creating the appropriate rules in order to have one trigger per keyword and properly categorize each request based on the keyword sent by the user.

Another scenario is to present users with a button and simple form:

Method 2: CTA button and form

This is a more complex workflow to set up but it doesn’t require users to type anything. Because the users have already shared their issue on the first message by writing whatever they wanted (when they replied to our do-reply email), all we need now is some categorization if/when unavailable.

The goal here is exactly the same as in the previous scenario: to allow users to self-triage their requests by confirming the context or topic of their ticket submission.

The key difference here is they don’t have to type any keywords: they’ll click a button, select an option from a drop-down and submit. On Zendesk’s side, they will be unknowingly creating a ‘ghost ticket’ that will update a “Topic” drop-down custom field on their original request… ✨

Demonstration of the CTA ‘do-reply’ process

Here’s how it works. Users receive the usual no-reply do-reply notification:

After they respond to this email, our ‘request received’ template is different than the first method (less text, especially):

As with any ✨magic trick ✨, everything behind the curtains has been prepared in advance:

• We created some custom fields in Support and custom code in Guide
• The link leads to a pre-filled, custom ‘requests/new’ URL
• That URL triggers specific Javascript Guide customizations to minimize the page design and make it as easy and objective to the user (just as a customization example, of course)
• The user is in fact submitting another request… Only they’ll never know about it. Its purpose is to update the original request using a webhook.

Resuming: after clicking the link, users arrive at our cleaned-up new request form page, adapted to this specific workflow:

All they have to do is fill whatever custom fields we need them to, in order to categorize the request. This will create a ‘ghost ticket’ they’ll never see or have to worry about (neither will we).

Upon submission, their original request – that is, their response to our communication – will be immediately categorized:

Try it yourself

If you’d like to see this working yourself (from the end-user perspective), feel free to generate do-reply ticket notifications and interact with them using any of the following links:

Keyword workflow

• Send an email to [email protected] with a message containing the keyword doreply_kw
• Alternatively, click here to generate a ticket via form

CTA workflow

• Send an email to [email protected] with a message containing the keyword doreply_cta
• Alternatively, click here to generate a ticket via form

You should receive an email notification confirming that your choice updated the ticket; for example:

Note on data privacy: your submissions will create tickets stored in our own Zendesk account. They will contain any information you choose to input, including the email address. We will delete all this data – email address, demo tickets and anything else associated with your request – within a work week.

These are but two examples of approaching a do-reply strategy; there’s more than one way to cook an egg! And we do need to highlight that these are methods for businesses that do not use any AI functionality in their customer support systems.

Those already using machine learning and/or AI to triage requests (like Zendesk’s own AI features) should have no qualms about obliterating their ‘do-not-reply’ processes… And if you do need to go through pros and cons, do check out our first article on this topic.

Ultimately, the ‘do-reply’ approach is a simple but effective way to show customers that you care. And at Opservator we believe that it’s yet another simple way to improve customer satisfaction, regardless of how we choose to address and implement it.

Featured image: Pawel Czerwinski via Unsplash 🔗