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 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.
-
Hi,
How can this solution be applied to chat tickets? Understand that it's only for emails
Thanks
-
Hi Isabella!
The bump-bump-solve automation will work on any ticket, not just email tickets. Or this is something you want to implements within Chat itself? Like some kind of automation to bump chatters if they haven't responded in-chat in a specific period of time?
-
Hello,
I am having issue while creating the triggers below you can see the screenshot.
Which action I need for both triggers?
-
Gregor
It looks like you want to remove tags when your condition is met. So add an action like this:
-
Add the condition:
Status: Is Not: Solved
That will do it
-
Also, as the error suggests, you need to tell the trigger what to do next.
Assign to: xyz (group)
Add Tag: xyz
-
Graeme,
Thanks that helped! -
This is great! I had something similar and simpler set up, but now I might upgrade to this style!
Quick maths question: if it's set to > 72 business hours, wouldn't that be 9 business days (assuming you had set your schedule to 8 working hours a day? So if I want to do 2 business days, I'd do 16 business hours?
Thanks!
-
Hi Fiona,
You're correct and if you want to account for 2 business days you'll set up your trigger/automation using 16 business hours.
Hope this helps!
-
When using this automation the email that is sent out seems to be sending from the account that created the automation. Is there a way to adjust it so that the follow up email is shown as sent by the agent who responded to the ticket?
-
Hi Jason Rowell,
Great question! I can't think of a way to make the automation use a different email address/user inherently. I wonder if you can make a series of automations that leverage the Notify Target feature. You'd have to set one extension/target up per Agent and a each automation would have to look for that Agent's tickets, essentially posting a public reply on the ticket automatically and therefore sending a Ticket Update trigger/email from their account?
I'm guessing, so I suggest testing it out if you think this might be what you're looking for!
-
We're running into issues with bump bump solve. In the conditions, it looks for "hours since update" but what happens if an agent goes back into the ticket and updates a field, or another automation runs (based on the due date, for example)? These seem to be counting as "updates" and interfering with the BBS workflow. I thought about "hours since requester update" instead of "hours since update" but I'm not sure if this will work well (what happens if someone who is cc'd updates the ticket?). etc. Any suggestions?
-
@...
We use the "hours since requester update" for our "bump bump solve" implementation.
It works well for us and we have not had many issues with it. Sadly, I am not sure if a CC responds if that counts towards the "hours since requester update" but from memory, I have not noticed that.
I can tell you that based on the wording of the "hours since update" that a CC response would most likely affect that as well. So, for your specific situation the best COA would probably be to use the "hours since requester update" as in the worst-case scenario it would not have a different result as the "hours since update" but would for sure ignore any ticket updates from automation or field changes. Also, as an added benefit it would not be affected by the agent putting in notes as well.
-
@... thanks! This is what I was leaning towards, but find it odd that the Zendesk recipes in a few articles use "hours since update" instead of "hours since requester update."
-
@...
It really depends on your use case.
Some companies may want the condition different for many reasons.
Off the top of my head, maybe they would like the time to be reset if they get a notification that the requester has read the message and would like the "bump bump solve" timer to go based off of that.
Also, the use case of the CC responding might be a reason to change the overall result as well.
Even more than that, there can be some unwanted results based on the condition chosen.
I recently found out that the "hours since assignee update" is broken if the assignee never updates the ticket in the first place. So, the "hours since update" is a good catch-all.
Sadly, I am not sure if Zendesk is going to fix the above-mentioned bug as the tech I spoke to does not consider it to be a bug.
-
Hello
I am trying to set up the BBS tag removal, but some of the options are not available/ seeing different values. For example, the article says Ticket status > Changed to > Open , but I don't see the value "Changed to" in my field.
All I see is the below values;
-
Nick
The condition Ticket Status > Change to> Open is for triggers, not an automation.
Automations fire at time intervals and so they do not look at ticket changes.
Triggers fire when a ticket is updated and so can evaluate changes to a ticket. If you recreate the described rule under Triggers, you should be fine.
-
Hi ,
I have added a condition to send first follow up email on tickets which are pending for more that 48 hrs , but the automation is not sending emails on few tickets and i have checked the tickets are pending for more than 3-4 days still no email is being sent , so please help.
-
@Gaurav,
You can check your automation conditions and compare it to your tickets to determine if all conditions were indeed met. Once you are certain that it should have fired, please contact us through Messaging and we'll gladly look into it directly for you.
-
Hi Dane,
i have one more query i have different schedules and tickets are assigned to different schedules depending on few conditions , so i have one schedule that is 24*5 and the other is 8*5 , so do i need to add different bum bum solve for both schedules , as i want to send the first follow up after 2 business day since pending and second follow up should go after 1 business day of the first and finally the ticket should be solved after 1 day of the second follow up .
Currently my automation is working fine for the tickets with 24*5 schedule , but for 8*5 schedule the first follow email is taking a lot of time .
So any suggestions ?
-
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.
-
Hi,
I'm trying to send 2 reminders (3 and 7 days later) to the requester no matter if there are any updates from either end. I was able to make it work using the time after a ticket was created, the problem is that the timer needs to start after a specific custom field is selected and this could happen 2 or 3 days after the ticket creation.
Any ideas how I can make this happen?
-
Hi Ulises, I see you posted this same question elsewhere - I've provided a suggestion there using the Task ticket type.
Please sign in to leave a comment.
83 Comments