Improve support response time with mandatory checklist items

[#1]

People often believe that things that are obvious to them are as obvious to others. This is one of the reasons why first-line support agents often receive support requests with barebones information (or worse yet, without a description whatsoever 😨). Escalating a ticket like that, even by accident, won’t do anyone any favors.

Not only are support agents, developers, and QA engineers a part of different teams with their own To Do’s and schedules, they are oftentimes located in different countries and time zones. Receiving a ticket, responding to it, and requesting more details to clarify the matter can add entire days to the support cycle. Entire days of useless back and forth. All while the client is expecting a swift solution with their patience running thin 🫠.

Stick to your processes

Communication is a nice first stepping stone for mitigating delays in customer service. There is always a minimum of information that engineers will need to understand a case. Let your support team talk to them and create a checklist of these mandatory items. This way you will be establishing a process in which the support team knows what’s needed to successfully resolve a case. Typically you’ll end up with a list of must-have info and a couple of details that are nice to have. For example:

A checklist like this can be automatically applied to Jira Service Management tickets (as well as Jira Software) with Smart Checklist. You can apply a certain template based on the request (or issue) type, based on the issue status or both. This way, your first-line support agents will always have a clear list of things to check every time a customer reports a bug (request type = bug). 

As you can see, there is a “!” in front of several checklist items. These items are considered mandatory, meaning the support agent will not be able to forward the ticket to development unless they are completed. The transition is simply blocked. 

Please note that you will need to add a validator to your workflow in order for this functionality to work. This process shouldn’t take longer than a couple of minutes if you were to follow this guide.

Keep in mind that the support agents aren’t the only ones who may need a handy checklist. The engineering team can have their checklist added (or appended) with certain items marked as mandatory once the ticket is transitioned to “in review by engineers”. Smart Checklist allows you to add a checklist on a workflow transition so a checklist for the developers will be appended or replaced.

You can append your checklists when transitioning from pending to work in progress, for example by adding a Modify Smart Checklist post function.

They may have their own mandatory items like reproducing the bug, confirming the root cause, and linking to internal issue ID. And there may be several optional items, like providing an ETA or escalating to management. 

Keep your clients in the loop

Checklists aren’t limited to internal use. You can keep your clients in the loop if you are using Smart Checklist with Jira Service Management. Enabling this feature lets your clients see Smart Checklist content from their customer portal view.

This feature is a nice way of keeping customers updated in real time and offering them peace of mind without adding more work to the support team.

Conclusion

You can’t expect your clients and your team to know and remember everything. But you can establish a reliable process that will guide everyone through the right steps and offload the burden of keeping everything in their mind and getting pressured by the team for not having right answers.

[Andrey Kiyanovsky]

How is it better than sub-tasks?

[Oleksandr Siryi_Railsware_]

Hey, @Andrey Kiyanovsky and thank you for your question!

I'd say it is different. 

1. You have all of your ToDos in one place. You see them as a checklist you need to go through.

2. Checklists are simpler to create, especially with Markdown support. 

3. You can block an issue from moving forward if a mandatory checklist item is not completed. So you can't escalate a ticket unless it includes all the details needed.

4. You can save your checklists and reuse them as templates in the process. 

5. The content of a checklist can be changed upon transition of the same issue.

Hope this helps?

[Scott Garner]

Improving support response time through the implementation of mandatory checklist items is a strategic approach that can significantly enhance troubleshooting efficiency and consistency. The first step involves identifying recurring issues based on historical support data, which serves as the foundation for creating detailed checklists. These checklists break down the troubleshooting process into clear step-by-step instructions, categorized by severity and priority. When support agents receive a relevant support request, they are required to follow the corresponding checklist before responding to the user. This approach streamlines the support process, ensures a systematic approach to problem-solving, and allows agents to address urgent matters promptly. 

[Andrey Kiyanovsky]

1. No, you don't. If I have checklists from different tasks, I can't see them in a single place. But I can see all sub-tasks in a single place.

2. Sub-tasks can be created as simple as ToDos - just enter a summary, the same process.

3. The same with sub-tasks.

4. Sub-tasks can be created automatically or from a template automation.

5. The same with sub-tasks.

And with sub-tasks, there is a million more possibilities.

And it's free.

[Oleksandr Siryi_Railsware_]

Hey, @Andrey Kiyanovsky 

So here we discuss the flow with JSM and support requests, normally it’s one Jira ticket that gets reassigned between the departments. In this sense you won’t have different tasks (and checklists) to switch between. Subtasks require you opening a new view if you want to check the details, it’s extra time.

It’s true that subtasks give you more possibilities, but for simpler flows this can be overwhelming.

E.g. the majority of ToDos for support process are on-line text items, you don’t need all the rest of the fields that subtasks have.

With checklist you can mark certain steps skippable if they are not applicable, with the subtasks you’ll need to update the status to close the ticket and this can influence the statistics (e.g. if you track number of resolved issues). And Smart Checklist has built-in automations that are easier to setup.

However I agree that for some processes subtasks are more suitable and make more sense.