Zendesk on Zendesk: Bump Bump Solve

Zendesk on Zendesk is a day-long discussion about a specific topic and how Zendesk Support uses Zendesk. Each session is hosted by a member of our Support team.

This session is about business rules we use at Zendesk to gently remind customers about tickets, and automatically close them if the customer is ready. It's something we like to call Bump Bump Solve. This session covers:

Overview of Bump Bump Solve and how it works

Configuration of Bump Bump Solve so you can set it up too

Benefits and modifications of Bump Bump Solve over time

This session is hosted by Matt M, who is a member of our Support Ops team in Melbourne.

Part 1: Overview

At Zendesk we are always trying to think of new ways that we can make life easier for our Support Team.

Like many other support teams we love to use Zendesk, (it would be wrong if we didn’t right?) so our workflow revolves around the following ticket status':

New - untouched tickets that customers are waiting for an answer on

Open - tickets that the customer and and advocate are actively communicating

Pending - where the advocate is waiting for the customers response back.

Solved - yay!

Sounds familiar I’m sure. And it works really well. Though we wanted something even better, something that would make our Advocates lives even easier.

Over the course of an advocate’s day, there would usually end up being around 15-20 pending tickets in an agent’s workload. If a customer does not respond after a few days the advocates would manually have to go back and prompt the customer for an answer--usually more than once. We felt this was holding the advocate back, and taking up time that could be spent with new inquiries. This generated a discussion whereby we felt that agents would start their day by going back through all the pending tickets to update them in an effort to get something back from the customer as to whether it could be solved or they needed assistance.

Naturally we turned to Zendesk for answers, and an idea was born. What if we could take all the advocates pending tickets and auto prompt the customer after a certain amount of days? What if we could actually solve those tickets if we didn’t get a response back from the customer?

Enter Bump Bump Solve.

A series of automations and triggers designed to help advocates move forward. The idea was simple:

Part 2: Configuration

While the process sounds quite simple in theory, there is little more to it on the back-end. Let’s take a look first at the automations, then we’ll look at the triggers.

Setting up the automations

They do the heavy lifting, and are the rules that send the notification to the customer. (Note that using the tag no_bump can be used to exclude particular tickets from being bump-bump-solved.)

Depending on your Zendesk configuration and business needs, you can change the times and also change the conditions to reflect calendar hours instead of business hours.

Conditions for our first Bump Bump Solve automation:

Actions for our first Bump Bump Solve automation:

The conditions are slightly similar on our second automation, as we need to take into consideration the amount of time that has passed, and also allow for the time which the last bump happened - as this counts as a ticket update.

Conditions for our second Bump Bump Solve automation:

And our actions will also be a little different from the first automation.

Actions for our second Bump Bump Solve automation:

As you can see there are various tags being used, which will make a bit more sense when we go through the triggers. (Also, note that we used to actually bump the customer twice so the tags are bbs_1 etc. Now we've moved to just one bump, but it would be a bit weird if we used “bs” since... you know…)

This is also a fairly flexible automation, and if you have different groups that you want to add or exclude, you can do so in the ANY conditions part of the automation.

Setting up the triggers

Let’s take some time now to go through triggers, which act as the engine - watching, controlling, every time a ticket is updated.

Remove BBS tags upon reassign:

This will ensure that if the ticket is transferred to another employee that the Bump Bump Solve process will restart when it gets to that agent. The idea of reassigning the ticket would suggest that some work needs to be done by someone else.

Removing tags for open tickets:

This trigger takes into consideration the customer replying. If the customer replies (depending on your business rules) it will set the ticket back to open. If this happens, we certainly don’t want Bump Bump Solve to carry on, so we remove all the tags again and wait for it to go back to pending, where the automation will start the process again.

You also want to add the same actions with a different set of settings to allow for closed tickets reopening as new tickets, as they will inherit the tags from the closed ticket.

Removing tags for closed tickets:

That’s really the bulk of the setup. From the screenshots, you can also see a couple of b_track tags which are used for internal reporting. Things like this are completely optional, and you can make any additions that you need. It really just shows how a basic setup would look.

Part 3: Solved :)

Originally we actually ran with Bump Bump Solve, so we would bump the customer twice, and then the third time would be the solved message. This would take about 9 business days, before the ticket was solved. With the weekends in there as well, it would be around the 2 week period before it was solved.

We decided to remove one of the bumps, and thus reduce the amount of time the ticket was sitting in a pending state. Remember though, if you use calendar hours, your bumps will be inclusive of weekends.

We like to think of Bump Solve as a win-win. It makes the advocates lives and days easier, and also, we don’t have to constantly hassle the customer (or solve their ticket too early).

To give a small insight into some numbers, for Q1 this year we had over 8000 tickets that were solved by Bump Solve alone. This represents around 15-20% of ticket volumes over the course of a normal working day.

By implementing this kind of workflow, we are able to keep our advocates focused on their new and open tickets. For tickets that don’t get updated, it’s no longer a matter of going through a manual process. The advocates can confidently work forward, knowing that their pending tickets will take care of themselves. We found it saves the advocate a small but considerable amount of time.

Do you think this would be something that would save your team time? Let us know in the comments below.

i have a Diane-o-mation version of this using two macros. Basically, my first macro is "have you resolved your issue, I see you haven't responded", and then a "couple days" later as i'm reviewing my pending YET AGAIN, i have a second macro for "i see you haven't responded, so we're closing this ticket, but if you need help, simply respond and we'll continue our conversation"...or something like that.

I've been meaning to make this into an automated process but didn't have the brain power assembled until my summer down-time season.

Has this negatively impacted your SATISFACTION rate any? When the client is offered the opportunity to rate the service are you getting any negative ratings due to the automated solve or is the satisfaction offering suppressed?

@Jeremy, as an e-commerce site with a relatively high volume of customer contacts through ZD, we've found that this process has not negatively impacted our NPS scores since we implemented this over a year ago. Wording is key of course.

The timeline we utilize is as follows. An automation sends a reminder after 48 hours for Pending tickets, and Solves at 72 hours. Solved tickets send an automated survey (with a SurveyMonkey link) at 5 days, and Closes the ticket at 7 days after Solve.

We use a similar setup where we bump the customer 2x and then solve the ticket, all with automations. Works out great. To Jeremy's question, every now and again we get back a negative rating. It's rare though and is just as common as it was with a manual process.

Jeremy, this has impacted our satisfaction a bit, yes. We solved it by setting two different automations for Satisfaction requests.

For regular solves, we send the regular stuff. "Hey, did you like it? We'd love to know!" or something.

For bump solves, we send something around "Hi! Your ticket was automatically set to solved because we didn't hear from you. Not satisfied? Please reply to this email and we'll keep talking until you're happy!"

Of course there are always those unhappy people who just tap "I hate you" and forget to read it, but this has reduced the practice almost completely. I feel that most people don't know exactly what to do and feel left out so that's why we came up with this.

We're a little new to zendesk so this is exactly the type of thing we're excited about.

The one thing I'm not sure works so well is the lack of "Ticket: Comment" as an action in the automation or otherwise. I would much prefer to comment within the actual ticket rather than sending a new email, which would result in a new ticket if the customer replies. I think most of our customers would simply reply to the email rather than clicking on the ticket link, even if we asked them to.

We'd then need to make sure we're looking out for this and merge the tickets, which seems like a hassle. Would this be the case, or am I understanding the process wrong?

I love this implementation, so thank you for sharing this with us, Matt.

I am very interested to know how you handle out-of-office responses with these automations. I know they end up in 'Suspended Tickets', but if you are aware a customer is out of the office for longer than the automation kicks in, how do you deal with this - do you add the tag to prevent the automation from taking place and remove it when they are back?

I set my Triggers and Automations (similar process to the above) about 10 months ago due to the large amount of pending tickets we had at level 1 Support. Since introduced, it's certainly speeded things up. Works 100%.

*My only addition was some extra views for level 1 support.

Example: When the agent applies a macro (e.g 'B') the ticket goes into the holding pen (A) until 72hrs comes around... (escalates to 'C') and so on. The final macro (D) notifies the end-user that the ticket will considered closed within 24 hours. This is done automatically.

I have been trying to do something like this for quite some time. I followed all the steps listed above yet after the specified amount of hours the tags get removed but an email message is not sent to the client. Any suggestions?

Notifications seem to be going out based on the automations I mirrored from this article. Analysts have mentioned that they have gotten responses from customers referencing a "bump bump" email but there is no copy of the email logged in the ticket? Is there a step that maybe I missed that would add this to the ticket notes?

@Chris yes, there is a copy! You can click on "View all events" to track all triggers and automations that worked on a ticket, and from there you can see all notifications the users received. You can find the email under the automation that popped it.

I'm just about to implement this on our account, but we have a few custom fields that we require to be filled in before a ticket can be solved but not before pending. Would the automation still set the tickets to solved without those fields?

If not, any suggestions for the best way to handle this?

I'm thinking that if the fields weren't filled out it could reopen but keep the bbs etc tags so that the agent can make the selection from the fields and then solve the ticket without interrupting the flow too much.

Matthew, the answer is yes, setting a field with business rules will ignore dependencies except for permissions. So the ticket will be marked as solved.

What I do is to run another rule ahead of this one that will invalidate the conditions of the solving rule if my dependencies are not met. For example i have an automation that sets the ticket as solved after being pending for x days. I have two variations of this automation, one that tests for a field being blank and the other does not have this test. In the first I do not set the status to solved but instead send an email to the agent.

We have additional automations set up (such as if ticket has been going on for X days, notify manager) that are interfering with the 'Bump Bump Solve' automation as Zendesk seems to classify other automations as an update to the ticket.

What would be a suitable workaround? Am I right in thinking that "Ticket: Hours since update" includes automations?

You also have under the ALL Conditions, 'hours since requester update' and 'hours since assignee update'. You may be able to use these as conditions to identify how long before a human has touched a ticket.

@Graeme, a good suggestion, thanks! The only problem I would face then is that if I want to identify how long before a human has touched a ticket using this method, it would have to be under the 'Meet any of the conditions' (so that it is either the assignee OR requester instead of meeting both conditions) where you cannot select this condition unfortunately.

I think for this to work with the current controls Zendesk offers, I would have to prevent any automations from running in between a ticket being on pending and the Bump 1/2 automations.

If we assume that agents and customers are both humans, then to identify tickets that have not been touched by either, both conditions need to be in the ALL section.

For example, if an agent has not touched the ticket for 11 hours and the requester not touched it for 1 hour, then the condition in the ALL section would be:

Hours since requester update > 10 (comes out false)

Hours since assignee update > 10 (comes out true)

So this evaluates to FALSE as a customer has touched the ticket. Only when both have not touched the ticket for 11 hours does it become true. The conditions are effectively asking if the ticket is untouched by a human. Consequently, the customer asking for an update every hour will stop this automation from firing.

If your main concern is agents not touching the ticket for 10 hours, then drop the requester condition.

If you really want an OR condition, then use 2 automations. One to test for the requester update and one for the assignee update. If you test for requester update first, include a tag to stop the assignee automation from firing too.

First off I want to say I love this. I noticed this when submitting Zendesk Tickets, and it instantly went on my todo list. We spend way too much time tracking down customers so this was a great addition for us.

I see this was partially talked about, but from a different standpoint. Is there a way to get the bump bump solve notifications to appear as comments on the ticket. My agents at first were not sure if it was working correctly as they were not able to visibly see the emails had gone out. For now I have them click on "show all events", but it would be ideal if the email could translate into some sort of comment whether it be public or private, just to let them know it has triggered without taking the extra steps.

There isn't a way to add a comment to a ticket using a trigger, but there are a couple other options you could use to make that information more easily visible.

The first option is to direct your agents to look for the tags that are set each time the BBS triggers fire; when I was a Tier 1 Advocate, this was my prefered way to identify BBS tickets.

The other option would be to include some custom fields (such as checkbox fields) that would be populated for each BBS notification that's sent. Those fields would appear in the sidebar of the ticket with your other fields, and your agents could tell at a glance which (if any) BBS notifications have been sent. This might be useful if your tickets tend to have lots of tags on them.

This solution works nicely, except if we have 1 step between two bumps. We want to reopen a ticket for an agent to call, then continue with the process. This isn't working well with the trigger that removes tags associated with this setup. Any experience with this? We can have agents managing tags manually at the end, but we would like to automatize.