Imagine three messages arriving together. A buyer cannot complete an order. Another wants an invoice copy for next month. A third writes URGENT above a request to change a profile photo. The capital letters do not tell you where to start.
Support ticket priority is the order in which your team should act. Decide it from the impact of the problem, how quickly harm can grow and whether a safe alternative exists. Write the reason down so the next person can understand the decision.
The idea, at a glance
Choose the next action from the facts.
- 01Impact
What is blocked, and for whom?
- 02Urgency
What gets worse if this waits?
- 03Alternative
Is there a safe, usable fallback?
- 04Review
Change priority when the facts change.
Ask what is blocked
Find out what the customer cannot do, who else is affected and whether there is a deadline. Ask only for the detail needed to decide the next step. An incomplete report deserves a quick check, not an automatic low-priority label.
Atlassian distinguishes severity from priority: the size of an impact and the order of action are related but not identical. Its examples concern technical incidents. The small-team table here is an original operational exercise.
Agree a small priority table
Make each level observable
Avoid definitions such as “very important”. Two people should be able to look at the same facts and reach a similar decision. Use your own service commitments and escalation requirements to set actual response times.
| Working level | Example situation | First move |
|---|---|---|
| Immediate assessment | Reported safety concern, suspected account misuse or broad service failure | Contact the designated responsible team |
| High | Essential action blocked with a near deadline and no workable alternative | Assign an owner and confirm impact |
| Normal | Individual request with time to investigate | Set a realistic next update |
| Planned | Improvement idea with no current service blocked | Record it for a planned review |
Keep a route for uncertainty
The table is not a substitute for emergency, security, clinical or other specialist procedures. Give staff a named route for uncertain reports. They should not investigate beyond their authority or ask customers to send sensitive evidence into an ordinary shared inbox.
Check the workaround before reducing priority
A workaround means another acceptable way to complete the task. “Try another browser” is only useful if it has a reason and is practical for that customer. Ask whether the alternative works and whether it changes cost, access or risk.
In an invented example, a downloadable invoice may replace a broken email attachment for a buyer with account access. It does not help a buyer who cannot sign in. The same visible symptom can therefore need a different next step.
Reassess when the facts change
If five more customers report the same failure, link their requests to the shared issue and review priority. Keep each person's contact history, but avoid five separate investigations of one cause.
Atlassian's incident handbook includes assessing customer impact and coordinating a response. Use the escalation worksheet to pass new facts to the right person rather than merely changing a coloured label.
Audit decisions without punishing difficult work
At the end of a working period, review a small mix of urgent, ordinary and still-waiting requests. Ask whether the recorded facts justified their place in the queue. Also inspect older work: low urgency today does not mean a request can wait forever.
The support-metrics guide helps show waiting work alongside completed work. Pair it with the enquiry tracker so every priority still has an owner, an action and a review time. A sensible queue should change when the situation changes.
A conversation worth having
Reader comments
What has worked in your business? Share a useful example or ask a question. Comments are reviewed before publication.
Loading comments…