Plan requirement
| Subscription | Any plan |
| Access | Agent |
For agents: linking a ticket to a development issue, and what to tell the customer while it is open.
Link a ticket
- Open the ticket and find the Jira app on the right. If it is not there, click Apps.
- Check whether the issue already exists. If it does, click Link Issue, enter the issue key or paste its link, and click Link issue.
- Only if nothing matches, click Create Issue, choose the Project, write the details, and click Create issue.
- Note in the ticket that it is linked.
Copy fields from this ticket takes the subject and the most recent comment across, and nothing else: no custom fields, none of the earlier conversation. Whatever a developer needs has to be written into the issue itself.
Add reporter as a watcher puts the person you named on the issue's watcher list, which is how they hear about it without anybody remembering to tell them.
Search before creating
Most bugs are already reported. Linking to the existing issue shows the development team how many customers are affected, which is what gets it prioritised.
Creating a duplicate does the opposite: it splits the evidence and adds triage work.
Write the issue for somebody who was not there
What the customer did, what happened, what should have happened, and how to reproduce it. A developer reading it in three weeks has none of your context.
An issue that says "customer reports it does not work" gets closed as unreproducible, and the customer waits for nothing.
What the agent sees, and what travels
The app shows the issue's name, summary, description and comments, with an eye icon, Show More Details, for the rest. So an agent picking up the ticket next week can see where it stands without a Jira account.
Be careful in the other direction: comments added to the Support ticket are shared with the linked issue, and that includes internal notes. Anything written for colleagues on a linked ticket is readable by everybody with access to the issue.
Do not promise a date
A linked issue is not a commitment to fix, and certainly not to a timeframe. "This is with our development team and I will let you know when there is news" is honest.
Anything more specific will be quoted back.
Keep the ticket open or close it deliberately
Decide as a team which. Leaving tickets open for months waiting on development clogs the queue; closing them means somebody must remember to tell the customer later.
Both work. Doing it inconsistently does not.
Tell the customer when it changes
The status coming back is only useful if somebody acts on it. A fixed issue with no message to the customer is the failure mode of this integration.
Comments
0 comments
Article is closed for comments.