How to save as draft service ticket and why for? Real life use case

[#1]

A customer may need information to create a request that he doesn't have at the moment. To avoid the situation where information is lost due to too many people being involved, he would prefer that this information be able to be entered later or that competent people be able to enter this missing data. 

Problem: 

With that not completed ticket, agents start their task, and here we have a million questions and spare communication due to a lack of information at the very beginning. The effect we get is its nervous agent and long ticket resolution. This is how you change it. 

💡 USE CASE - challenge

The dev team uses the planning poker addon and has noticed it is crushing. The topic was brought up at the retrospective. Scrum master John decides to pass this information to the project admin. Project admin Tom decides it is necessary to report the problem to the vendor, and that's what he does. 

The flow – 5 steps you should take 🐾

1️⃣ A banner at the portal with a pleasant message about filling in all needed information.

2️⃣ Tom fills in the fields where he is sure: app name, hosting, and instance URL. Unfortunately, he cannot access the SEN license number for the addon. He also doesn't know exactly what the plugin's instability manifests as, so he leaves these fields blank and creates a ticket. The ticket is created as a DRAFT status. If he doesn't want to add anything to it, let him click the SUBMIT button. However, Tom knows that he needs the support of his colleagues to make the submission rich in information.

3️⃣ Tom joins two people: Greg, who is the site admin, and Beth, who is the dev team leader. Tom can share the ticket thanks to the native Jira functionality Share with. Greg enters the request, clicks Edit request, and fills in information about SEN. Beth, on the other hand, describes the problem in detail. After each action, a comment is added to the task, stating who edited what field and when.

4️⃣ Tom enters the request, clicks on the Edit request button, and completes the Project type field additionally - company-managed software. On this screen, he also chooses to change the status to OPEN. 

5️⃣ The ticket is in the queue that catches OPEN statutes. The agent can work on this with all essential data packages; all concerned are already added to the ticket.

🔎 If this seems to be a solution for you, learn more HERE

 

Why is it worth it?  

• Agents with access to all necessary data: They have all crucial information in the ticket.
• Agents don't get stuck due to waiting for answers: Without spare communication and billions of the same questions, they can resolve tickets much faster. 
• Meeting SLA faster: Happier customers! 
• No rush decisions: Reporters can take their time to collect information and save tickets as drafts.
• Editing requests prevents making mistakes or filling in wrong data: When it happens, the reporter can edit ticket (admin decides who, when, and how many times it can edit).
• One source of truth: Without other channels, side conversations – all at once in the right place with notification for all concerned.
• Transparent communication: It makes it easier for the agent. 

🔎 If this seems to be a solution for you, learn more and check how to configure it  HERE

Configuration video inside 👆

Solution and tools you need:

Native functionalities in Jira Service Management:

• request form
• workflow
• queues

Apps:

 Feature Bundle for Jira Service Management:

• displaying customizable announcements on the portal
• allowing customer to edit request on the portal