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 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?
-
@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,
-
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 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.
-
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.
-
@Nicholas, @Zach, you guys are awesome!
-
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.
-
Hey Justin!
The usual culprit in these cases is another trigger that's messing with your conditions. Triggers fire in the order in which they're arranged, so if a previous trigger is changing some part of the ticket so it doesn't match the conditions of the BBS trigger, the BBS won't fire.
Can you post a screenshot of the trigger? That might help us get to the bottom of this.
Vous devez vous connecter pour laisser un commentaire.
88 Commentaires