Zendesk on Zendesk: Lifecycle of a Problem (and Incident) ticket

Comments

18 comments

  • Avatar
    Ryan Hester

    If we can't make this event, will it be recorded for later viewing? 

  • Avatar
    Nora Mullen

    Hi Ryan,

    This is actually an article and online discussion, so there won't be anything to record. :) You can check back on this page for the full article and comments anytime.

    Nora 

  • Avatar
    Wil

    We don't currently use this feature so it would be great to see how y'all use it! We do link tickets to JIRA though.

  • Avatar
    Immanuel Comer

    Looking forward to hearing your ideas

  • Avatar
    Joseph May

    Hey folks, the discussion is now live. I'd love to hear how your organization utilizes problem tickets.

  • Avatar
    Colin Piper

    Joseph, thanks for taking the time to post. It all seems like a robust process (as one would expect), but do you find yourself in unlinking tickets on a regular basis? 

    Last time I tried problem/iincident my agents could not reliably ascertain connections.  Does you engineering team provide internal updates that help confirm the connection? 

  • Avatar
    Janelle Dauenhauer

    We use Problem and Incident ticket types and appreciate the options.  We don't have On-Hold activated but will consider it.  Wish the On-Hold feature would stop the clock so the open ticket wouldn't indicate such a long period of resolution and throw off stats.

  • Avatar
    Joseph May

    Hi Colin-

    That's a great question. Overall I would say that reliability is high, as every linked incident has an owner who linked it in the first place. When I was very new, I attached an Incident ticket to a Problem erroneously, and it led to an extended support engagement. I believe this is a great opportunity to address workflow, should this become the case too often. I rarely see this happen these days.

    As far as internal updates, often our engineers will look at incidents as well (especially if replication isn't feasible). If it isn't the same/attached erroneously they reach out to the agent for further review.

  • Avatar
    Joseph May

    Hi Janelle- you can use the ([Text Field] Duration in minutes) fact for creating custom resolution metrics. I would recommend looking at this article about  Building Custom Metrics for the Events Model in Insights.

    Another option would be to create a custom metric that subtracts On Hold Time from Full Resolution Time.

  • Avatar
    Janelle Dauenhauer

    @Joseph, thank you!

  • Avatar
    Frank Mile (Edited )

    Thanks! @Joseph great article.

  • Avatar
    Makenzie Wells

    @Joseph, at what point in team size did this process make sense to implement?  Or, has it been there since the beginning of Zendesk on Zendesk? 

  • Avatar
    Joseph May

    Hi Makenzie-

    Great question, and one I don't know the exact details on - I would say day 1, if I had to venture a guess.

    What I did do was go back to look at the oldest recorded problem ticket we have - the team was a lot smaller back then, but the Problem/Incident workflow was around very early on.

    Was there anything specific in regards to your own Zendesk and how you use it that you would care to share, or have a question about?

  • Avatar
    Makenzie Wells

    Hi Joseph!

    I recently experienced something that would have been very well handled by the Problem/Incident workflow.  I spent a fair amount of time manually posting replies across multiple incidents regarding the same problem.  I can certainly see the benefit of tracking Problems in this way!

    Thanks for the great ideas/info!

    Makenzie

  • Avatar
    Dr. J

    @Makenzie - in my own Zendesk implementation, I'll use Problem/Incident workflows for something like a cancellation of a number of clients.

    I see a number of students weekly - if I have a gig, and need to reschedule, I make a Problem ticket out of it, and Incident each Student, so I can be sure that none fall through the cracks.  Since adopting this workflow, it's saved me a lot of headaches, and allows me to better take care of my people :)

  • Avatar
    Makenzie Wells

    Thanks @dr. j!  Great application of the Problem/Incident workflow!

     

  • Avatar
    Erik

    This is cool! 

    We're a bit new to ZD, so I'm trying to get my use-cases correct. 

    Am I right in thinking that Problem/Incident are best used for emergencies like outages, or situations where the message you use to solve the Problem will also apply to the Incidents? 

    One of our products doesn't have a lot of outages, but it does have consistent pain-point bugs. My initial idea with Problem/Incident was to link every report of a bug or improvement request to a Problem, link that problem with the associated JIRA, and we're good to go. When the JIRA's solved, it will update the Problem, and we can communicate with the subset of customers who were most interested in that issue's resolution. 

    Do any of you use Problem/Incident that way? Can you personalize the solve message enough with Placeholders? (https://support.zendesk.com/hc/en-us/articles/203662116-Using-placeholders)

    We're really low-volume, high-touch support--bunch of universities--so Problem/Incident would mostly help me with reporting. 

  • Avatar
    Dr. J

    Hi there Erik! - thanks for reaching out, and welcome to the family!

    Since many of our beloved customers are in the software incident, the natural design, and implication is that it's a "Problem" like an outage, but for me, I like to also use Problem tickets as a way to aggregate similar issues.

    To address your JIRA question, yes, we do almost the very same thing — personally, I feel that a JIRA question should only be linked to a Problem ticket (one which our agents are reviewing), not a customer ticket (incident), so the communication can be streamlined and consistent.

    I use Zendesk in my own small business, and like you, I don't have "infrastructure outages", but I do have occasions when I have to communicate with several customers (individually), and later as a whole, on a related subject.

    One example, is if I'm headed out of town, and need to reschedule a bunch of students - I create a Problem ticket for myself, then incidents for each student, until they're taken care of, then I solve out the problem ticket, wither with:

    • a nice public note - See you soon!
    • no public comment (since they've been addressed individually)

    Pro-Tip, is to also use placeholders — particulary the ticket.requester.first_name is one that I use a lot.

    If you really want to get sneaky - also take a look at using user, or org fields - this might help get you started.

Please sign in to leave a comment.

Powered by Zendesk