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.
-
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.
-
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.
-
Hi Ken!
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.
Please let me know if you have any other questions!
-
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.
-
Hi Zeljka!
Can you describe exactly what isn't working with your workflow? ie: why removing the tag causes an issue? I'd like to understand it a little bit better; then I can help you figure out how to fix it!
-
I've recently implemented a version of this for our Zendesk. One difference is that I used "hours...is..." rather than "hours...is greater than...". I'm curious as to why you went with "is greater than" in your example? Does it confer an advantage that I missed?
-
Hey Ben!
Automations run on your account every hour. However, that doesn't mean that they start at, for example, 5 minutes after the hour, every hour, on the dot. Depending on how many Automations you have, and how many tickets those Automations needs to run on, it could take more than an hour to actually get through everything. Once it's finished, the system waits for an hour and the whole process starts again.
The hours > is condition means that an Automation will only run on a ticket when the hour is exactly what it stipulates in the condition. This means that if the system doesn't get to the ticket in time, the automation won't run.
By setting the condition to hours > greater than, you're avoiding that pitfall. Even if it takes more than an hour for the system to get to that ticket and run that Automation, the Automation will still fire because the condition is met.
Hopefully that clears things up a bit!
-
Hi Jessie,
Thanks for taking the time to get back to me. If that were so, I would think it extremely odd, given that (according to your own documentation) automations run only once in any given hour, and the chance of an automation running on the same minute in the hour as the ticket came to satisfy the condition is so minute as to make it a useless feature.
In any event, your own documentation seems to say otherwise, though admittedly without an explicit statement to that effect. This from https://support.zendesk.com/hc/en-us/articles/203662236-About-automations-and-how-they-work (emphases added):
(( BEGIN QUOTE ))
Now let's look at example with a time-based "Hours since" condition. Time-based conditions have to be satisfied within a window of time or after a minimum amount of time has passed. The first time an automation runs after an event occurs counts as "zero" hours since that event happened (because it's less than one whole hour).
Suppose you have an automation that performs an action two hours after the ticket is solved and the ticket is solved at 9:15am. Here's what will happen:- If your automations run at 10:10am, the ticket has been solved for only 55 minutes and the automation will not fire.
- Automations run again at 11:10am, the ticket has been solved 1 hour and 55 minutes, which the automation counts as one hour (because it is less than two hours).
- Automations run again at 12:10am, the ticket has been solved 2 hours and 55 minutes, which the automation counts as two hours. This means the condition is met and the automation will fire and update the ticket.
((END QUOTE))
Moreover, by experience, I've seen the automation fire with use of "is" rather than "is greater than" at this end, and in fact it was necessary for me to use "is" else it grumbled about the automation's conditions being satisfied more than once.
Is there anything else, though, that the use of "is greater than" as opposed to "is" might affect in this regard?
-
Has anyone else using this noticed a significant rise in the number or pending tickets in their Zendesk? From implementation of the bump, we've seen approximately a 200% increase.
-
I have just set this up and since we are not receiving customer queries yet, think it is better to start sooner than later.
Just a comment about set up, as per this article (https://support.zendesk.com/hc/en-us/articles/203660716-Why-do-my-Automations-hate-me-) I had to set the conditions of "Ticket:Hours since update" and "Ticket: Hours since pending" to "(Business) Is", instead of "(Business) Greater Than".
If I didn't do that, I got an error message saying that an automation couldn't be done more than once.
Will it still work correctly with these amendments?
-
Hi Jennifer!
I think that (Business) Is could cause a problem where some tickets won't meet that criteria at the time the automation runs. You shouldn't be getting that error message as long as you've added another nullifying condition. In this case, it would be the bbs tags added as shown above. When the automations run, the appropriate tag is added. The presence of that tag is added as a condition for the next automation in the series, thus preventing the automation from running on a ticket more than once.
Feel free to post screenshots of your automations if you'd like us to take a look!
-
Is there a difference between "Hours since update" and "Hours since pending" in terms of how it affects the automation?
I made a similar automation that runs based on two conditions:
- "Hours since pending" is "X"
- Tags contain "bump-solve"
Actions:
- Set ticket status to Solved
- Remove "bump-solve" tag
-
Hi Zach,
Yes, there is a difference. For this you would likely want Hours Since Pending. The difference is that if someone submits as Open or On Hold then the Hours Since Update rule would apply. That could result in things getting cleaned up that need attention.
-
Hello,
This solution is great! We have just finished implementing this.
Is it possible to get a breakdown of what kind of reporting you are using? I am interested to see what/how you are reporting on this.
Thanks!
Nick
-
Hi, tried setting this up as per the instructions in this article but could not get past the first automation. This is the error message I got
Please help.
Cheers,Terrie
-
Hi Terrie
Can you provide a screenshot of your automation? Maybe we can look at it and see what's missing. You get that if the action(s) you set do not nullify one of the conditions set.
So as an example, one condition could be Tag present: "bump1"
and the Action would need to be something like Remove tag "bump1"
-
Hi Zach
Sorry am extremely new to this.
The article outlines exactly what I wanted to set up for us. I copied the automation exactly as per the article for Automation Title Bump Solve 1. Do I need to do something else before creating that automation?
Cheers,Terrie
-
Hi Terrie
You're doing great so far! It looks like you can get back on track with your automation if you make one small tweek.
The main issue is that the condition for Ticket Tags is not nullified by the action to Add tags.
If you take a look at the example in the article, you notice that the condition the author listed for ticket tags in "Contains None"
Then they have an action that adds the ticket tags that are not present. This will nullify criteria the conditions section and keep the Automation from running in a loop.
I also agree with Nicholas that you don't need both of the 72 hour conditions. I would remove the one that says Hours since update, and keep the Hours since Pending.
-
We've been using this method to solve stale tickets for some time, and we've noticed a change in behavior and are wondering if there is something we can do to revert the changes.
Originally when this was setup we would see the email notification in zendesk,
However we no longer see these entries, we assume that the emails are still going out because we see the following in the ticket event log. 
Any suggestions on what might be causing this change or how we can address it? Our automation is below. 
Thanks! -
Hi Jason! Welcome to the Community!
To the best of my recollection, email notifications sent out via trigger have never added a comment to a ticket. Is there something else in your workflow that's changed?
-
Hi Jessie,
It is possible that something else in the workflow has changed, unfortunately I'm wasn't the Zendesk admin who originally setup the automation. Do you know of a trigger that would update a comment to the ticket?
-
Hey Jason!
No, triggers don't add comments to tickets. It seems likely that the comment was added via macro before the ticket was updated. You should be able to observe the differences by taking an older ticket with a comment, and comparing the ticket events with one of the new tickets that look different.
-
Jessie,
I was able to get this working using an extension, The extension is setup as follows:
Title: Pending Notification
URL: https://_________.zendesk.com/api/v2/tickets/{{ticket.id}}.json?ticket[comment][public]=true
Method: Put
Attribute Name: ticket[comment][body]
With the Basic Authentication setup as my account.The automation is then set as
Notification: Notify Target > Pending Notification
and our desired message after that.
-
Hey Jason! I'm glad you got it figured out!
-
At the "BBS - Tag Removal" and "BBS - Tag Removal - Closed Tickets" triggers part, I get a message that "Trigger must contain at least one action".
What action do I need to add to both of these triggers? These weren't in the above screenshots
Thank you
-
Hi Darren! Can you post a screencap of your Trigger? That'll help figure out what's going wrong.
-
Hey Jessie
Can I check this set up? We want to test this in a Category, to start!
Emailing a User following 48 hours in 'pending' and want to solve the ticket 24 hours later - this is the bit I can't seem to find.
Thank you in advance
-
Hi
We're trying to implement this automation but for some reason the conditions and actions in the article are blank?
-
Hi Afran,
Thanks for letting us know! There is an article here that explains this in further detail with screenshots:
Hope that helps!
-
I've setup my BBS per the instructions but for some reason it is not getting triggered. not sure what is broken there.
Iniciar sesión para dejar un comentario.
72 Comentarios