Zendesk on Zendesk: Bump Bump Solve

70 Comments

  • Graeme Carmichael

    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.

     

    0
  • Ken Shampo

    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.

    0
  • Jessie Schutz

    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!

    0
  • Zeljka P

    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.

    0
  • Jessie Schutz

    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!

    0
  • Ben Roberts

    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?

    0
  • Jessie Schutz

    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!

    0
  • Ben Roberts

    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:
    1. If your automations run at 10:10am, the ticket has been solved for only 55 minutes and the automation will not fire.
    2. 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).
    3. 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?

    0
  • Michael Craddock

    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.

     

    0
  • Jenniferhill

    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?

    0
  • Jessie Schutz

    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!

    0
  • Zach

    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:

    1. "Hours since pending" is "X"
    2. Tags contain "bump-solve"

    Actions:

    1. Set ticket status to Solved
    2. Remove "bump-solve" tag

     

     

    0
  • Nicholas McMurray

    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.

    0
  • Nicholas Vardis

    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

    0
  • Terrie Culmsee

    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

    0
  • Zach

    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"

    0
  • Terrie Culmsee

    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

    0
  • Zach

    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.

    0
  • Jason Rowell

    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!


    0
  • Jessie Schutz

    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?

    0
  • Jason Rowell

    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?

    0
  • Jessie Schutz

    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.

    0
  • Jason Rowell

    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. 

    0
  • Jessie Schutz

    Hey Jason! I'm glad you got it figured out!

    0
  • Darren Taylor

    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 

    0
  • Jessie Schutz

    Hi Darren! Can you post a screencap of your Trigger? That'll help figure out what's going wrong.

    0
  • Polly

    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



    0
  • Arfan Khan

    Hi

     

    We're trying to implement this automation but for some reason the conditions and actions in the article are blank?

     

    0
  • Dean Kenny

    Hi Afran,

     

    Thanks for letting us know! There is an article here that explains this in further detail with screenshots:

     

    https://support.zendesk.com/hc/en-us/articles/205693448-Using-business-rules-to-send-automated-reminders-to-customers 

     

    Hope that helps!

    0
  • Justin Hammill

    I've setup my BBS per the instructions but for some reason it is not getting triggered. not sure what is broken there.

    0

Please sign in to leave a comment.

Powered by Zendesk