Recent searches


No recent searches

Best Practices? Communicating Bugs Being Worked on by Programming

Answered


Posted Sep 18, 2023

What are your Best Practices for communicating bugs that your programmers are already working on, to your Support Department?

Present Workflow

  • A client calls/emails in re: a bug.
  • A ticket is created by the agent
  • A side conversation ticket is created and assigned to the Programming Group. Programming will then assign the ticket to their internal org. 
  • The original ticket from the client is coded Type=Task, Due Date = 8 days after the original ticket was opened so that they can follow up with the programming ticket and inform the client of any change, and put On-Hold
  • When programming has fixed the bug or has further questions, they will respond to the side conversation ticket to the agent

Issue 

Unless the agent reviews all tickets under the internal org, they are not aware of an issue that has already been reported to Programming. This results in duplicate tickets being issued to programming. 

Possible solution

  • Programming creating a problem ticket under their internal org. However, this is not optimal as the software we support is complex and the subject line of each problem ticket may not be correctly reflected: basically back to having the agents review all tickets which is time-consuming and cx impacting

So, my question to the community is, how do you communicate existing bugs to your Support teams?

Thank you in advance!

Dana


0

9

9 comments

image avatar

Jacob the Moderator

Zendesk LuminaryCommunity Moderator

Hi Dana B 👋

Thanks for sharing your workflow; that is a good question that many can probably relate to.

We have a similar setup and do use Problem tickets to centralize known bugs and allow support to link Incidents to these. There are some benefits to this:

  • Incident tickets have number fields that allow us to capture the impact (users, devices, $ - whatever is an important metric for your business) a bug has per ticket, reporting lets us see the cumulative impact per problem/bug.
  • This 👆 gives us a quantifiable way to prioritize which bugs to attack first or throw the most resources at.  
  • Problem tickets are owned by a specific user who has ownership of the bug and makes sure that the subjects are concisely stating what the bug is about, and the description/comments detail known symptoms, developments on a resolution, workarounds, etc.
  • The problem owner can update and solve all connected Incident tickets with a single update to the Problem ticket (this is unfortunately not something we're currently using).

I hope this helps, please let me know if you have questions. I hope others will add their experience as well.

0


Jacob the Moderator Thank you! This leads me to other questions about how you use tickets. Do you have separate forms for Problem and Incident tickets that are not used for regular support tickets? Having several fields is great however, I am concerned about "Toggle Tax" (too many clicks) for the agents. I would love to discuss how you work your Zendesk. Is that something that can happen? Thank!

Dana

0


image avatar

Jacob the Moderator

Zendesk LuminaryCommunity Moderator

Dana B Glad you found it helpful!

We spent a lot of effort in creating forms that conditionally hide fields until required by the assignee in the ticket lifecycle - I didn't know the term "toggle tax" existed for that 😀
We have a checkbox field that will allow the agent to reveal all fields if necessary.

Incident tickets would usually be at L1, whereas the Problem ticket is owned by L2, and they would have distinct forms, both containing the Type field. To control who is able to create Problem tickets, we hide that option using the Ticket Field Manager app. 

0


image avatar

Douglas R.

Zendesk Luminary

Olá, dentro de nossa operação utilizamos formulários para abertura de chamada, com isso o cliente já classifica para a gente o problema que ele está tendo, com isso quando o ticket é aberto, já chega atribuido ao time correto, ocorrendo uma notificação via slack para o time responsável.

Quando é um caso em massa, utilizamos a ferramenta de ações em massa, para responder o cliente que o problema dele já está em tratativa, ou que o seu problema foi resolvido.

-------------------------------------------

Within our operation we use forms to open a call, so the customer already classifies the problem they are having for us, so when the ticket is opened, it is already assigned to the correct team, with a notification via slack to the team. responsible.

When it is a mass case, we use the mass actions tool to respond to the customer that their problem is already being dealt with, or that their problem has been resolved.

0


image avatar

Brandon (729)

Zendesk LuminaryUser Group LeaderThe Humblident Award - 2021Community Moderator

Hey Dana B

Agree with everything above.  You might also find the Notification App, built by Zendesk, helpful for rapidly communicating with Agents inside of Zendesk.

Brandon

0


You could setup a ZAPIER flow that creates a Zendesk problem ticket each time a new JIRA issue is created by a Developer in your company? 

Flow would be:

  • A Developer creates a JIRA issue
  • Based on specific conditions (e.g. issue has tag "Zendesk" or "customer related") trigger a Zapier flow that creates a new Problem ticket in Zendesk
  • A team lead links the problem ticket to the Jira issue (via the free Zendesk to Jira integration)
  • A customer agent gets a new ticket
  • They look through the active problems to see if something is related.
  • If so, they link the ticket as an incident to the problem ticket
  • If not, they raise a new issue via the Jira integration?

Might be a bit to complex, but might work.

0


image avatar

Ifra Saqlain

Zendesk LuminaryMost Engaged Community Member - 2022Most Engaged Community Member of The Year - 2021Community Moderator

Hi Dana Barr,

As per your question, I'm using Phabricator for the same so we don't need to do a long process or you can also use GIT for the same. You can use JIRA for collaboration.

And, community members have already shared very good solutions above.

 

Thank You

 

 

0


image avatar

Ashley Caputo

Zendesk Luminary

Our Product and Engineering teams use Jira, so we love the Jira integration for Zendesk. With the integration, you can both search for or create new Jira tickets from your Zendesk ticket. Support starts by searching for a similar jira ticket before creating a new ticket. And if duplicate Jira tickets happen (because they sometimes still do), they can be merged together in Jira.

0


image avatar

Fernando

Zendesk Luminary

We have a Slack channel dedicated to notifying Engineering/Programing every time a Jira is created via Zendesk's integration.
All of those tickets follow a specific wording by the use of a macro.  Our managers subscribe to the channel above, and when a pattern is recognized, we leverage the Problem/Incident functionality and post an announcement in our Support channel notifying the team

0


Please sign in to leave a comment.

Didn't find what you're looking for?

New post