basic question about the solutions that are requested when closing a ticket.

[Ingo Syllwasschy]

Hello,

I have a basic question about the solutions that are requested when closing a ticket. As I see it, the entry that I select there is saved in the Ticket. Nothing else happens with it, correct? In your opinion, are there any other “things” for which they can be used? What would they be?

Thanks

Ingo 

[Paul Wiggers · Accepted solution]

Hello Ingo,

Could you clarify your question a bit? 

Are you asking about the resolutions in combination with the status? If so, you can use the resolution to get custom trend reports.

For example, you can set the Status to "Done" and select the Resolution "Not possible". You can have another issue with the Status "Done" and the Resolution "Resolved with phone call". 

You can then use that information to find out how many customer requests were not possible to resolve or how many customer requests were resolved by giving the customer a call.

If you mean something else, please provide some additional information and explain what you would like to achieve.

Kind Regards,

[Ingo Syllwasschy]

Briefly about my background: I didn't shout ‘no!’ loud enough when my boss was looking for an admin for Atlassian Cloud. Now I have to manage somehow. :-(

Thanks, that's what I thought. My users want to use the status ‘added as development issue’ as a trigger to open a new ticket in the product management board (Jira SM). I think this is a completely disastrous approach. And I haven't managed it with automation either.

I will take your answer as a basis that it doesn't work that way.

[Paul Wiggers]

I could have sworn that I wrote a reply to this yesterday, but perhaps I didn't hit the Reply button hard enough. Anyway, let's give it another try.

The solution you are talking about, is what we are using as well and it works relatively well.

When a request requires development work, we transition it to "Offer to development". This will pause the SLA, add the product owners and scrum masters as approvers and places it in a different queue.

If the issue is rejected, it is transitioned back into "Waiting for Agent". When it is accepted, it is transitioned into "In Development", an issue is created within the Jira software project and the new issues is linked to the JSM issue. When the Jira issue is updated, or when either the Jira or JSM issue receive a comment, it is duplicated to the linked issues. This keeps the customer up-to-date on the status. 

When the Jira issue is released, the linked JSM issues are resolved as well. 

This allows for a rather smooth workflow that doesn't require a lot of hands on work from the service desk agents. 

However, there are some points to take into consideration.

• You need to make sure that the offered issues are checked quick enough to prevent a build-up
• You need to make sure that the "In development" issues are check on a regular basis. Perhaps a customer replied with another email address (not a request participant), an automation didn't run, or the issues was "accidently" forgotten to be added to a sprint, causing unnecessary delays.

Once the early roadblocks have been tackled though, things work rather well.

Perhaps this might help you decide on the path forward. Don't hesitate to reach out if you have any questions.

[Marc - Devoteam]

Hi @Ingo Syllwasschy 

Resolutions are useful for reporting,

Issues Done, you Won't Do, Duplicates, etc..

The resolutions can even be used in SLA goals, that a specific resolution has to be set to stop a Resolution or start to finish process SLA.