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.
See all of the Zendesk on Zendesk series discussions.
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 th 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.
-
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 have something like this already in place. Another trick that helps to ensure that reps don't mistakenly set the wrong status is to have macros set the status for them.
-
this is awesome...
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.
(Diane wants MORE MORE MORE of these kinds of things!!!)
-
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?
-
Matt
That is an excellent article.
Setting the correct ticket status is an area that I see agents do very poorly. For example, I see comments like, 'Here is an update, I'll get back to you tomorrow'- status pending.
I would recommend that supervisors review pending tickets from time to time to ensure that they are truly pending so that they do not drop off the agent's radar or corrupt SLAs.
-
Graeme, Kraven, and Diane,
Thanks for your input and recommendations!
Matthew should be online soon to respond to comments as well. :)
-
Great stuff! We also do a bump-bump-solve here :)
-
@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.
-
Thanks @Kraven @Nicholas - now I just need to teach my agents not to use it as a burial ground for unwanted tickets that they are avoiding responding to
:- )
-
@Ben, if I can add some clarity from a customer to customer perspective.
Automations as you say require you to nullify the conditions before they can save. This is to say that once the automation has fired, the actions must ensure that conditions cannot still be true. In the example given on this thread, it is the adding of tags that prevents this automation looping and hence nullifies the conditions.
This use of tags therefore allows the greater than condition to be used. Using "greater than" removes the limitations if "is" that Jessie discussed where an automation may not run within each 60 minute window,
-
HI Terrle,
It looks like you have 2 lines in the "all conditions" section that say "ticket: hours since pending - 72". Try removing one of those and see if it works. The other thing I noticed is that you have a check for tags "at least one - no_bump, bbs_1, bbs_2" and in the action section an "add tag bbs_1". If the first part doesn't work try removing "bbs_1" from the "at least one" list; it may be detecting that as a loop.
-
@Nicholas, @Zach, you guys are awesome!
-
@Graeme, agree! We run Insights reports on Pending tickets to make sure they don't blow out, but the majority are taken care of by the bump solve process.
@Kraven, this helps also push the ticket to work with this kind of process rather than relying on an agent to do it manually.
@Diane, some of our advocates had this setup as well, we thought it would be great to just have everyone do it, then automate it :)
-
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.
-
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?
-
@Joe, for the automation, you can use the Notifications: Email user option, and it will automatically select "requester" in the adjacent field that will appear.
This would count as an update to the existing ticket, so that if the end user replies, it will just add on the reply to the existing ticket as well.
-
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?
-
@Joe If they reply to that email it will update the same ticket so don't worry about it! The same happens for Satisfaction rating request emails.
@Jonathan I don't think Zendesk has any kind of auto-processing for suspended tickets, but nevertheless the customer can always reply back and reopen the ticket when s/he gets back.
-
I don't have the ticket status Hours Since Pending or Hours Since Update. Do I need to update or is this my plan?
-
To all,
Great stuff!
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.
(A) All CSC Pending tickets 21
(B) Pending tickets - Over 2 days (48hrs) 7
(C) Pending tickets - Over 3 days (72hrs) 10
(D) Pending tickets - Over 5 days (120hrs) 4
To manage pending tickets, our agents only refer to views B, C, and D.
Hope this helps?
Pierre
-
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?
-
Hi Andrew!
The notification should be going out as part of the automation that adds the tags...can you tell me the names of your automations so I can hop into your account and take a peek?
-
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?
-
Jonathan J
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.
-
Jonathan J
This is tricky.
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.
Please sign in to leave a comment.
67 Comments