Triage Trainer Glossary
Keep this open while you work

Everything you need to triage a ticket

One page. Read it once properly, then use it as a lookup. If you can hold the four types, the priority grid and the six destinations in your head by Thursday, you can work a real queue.

1 · The four types

Get this wrong and everything after it is wrong, because the type decides which process the ticket follows and how it is measured.

TypeWhat it meansThe testWhat it sounds like
IncidentSomething that used to work is broken.Did this work yesterday?"It was fine on Sunday and now it will not open."
Service requestSomeone wants something new or standard from the catalogue.Did they ever have it?"Can I have access to the Finance folder."
ProblemRepeated incidents that share one cause. Raised by IT, not by a user.Have we fixed this same thing before?"That is the sixth time this month."
ChangeA planned modification to a service. Needs approval before anyone touches it.Is the current behavior deliberate?"Can you set the timeout to one hour."
The two that catch everyone. A service request written angrily is still a service request. An incident written politely as an order ("can I order a new keyboard, the keys stopped working") is still an incident, and it should not wait for purchase approval.

2 · Priority is calculated, never chosen

You judge two things separately. The priority falls out of the pair. The user does not set it and neither do you, directly.

Impact: how many, how important
  • High a whole site, a department, or a critical business service, and money or reputation at risk counts here too, even when only one person is typing
  • Medium a team or a group
  • Low one person
Urgency: how fast it must move
  • High work is stopped now, or the deadline is today
  • Medium degraded, but a workaround exists
  • Low it can wait, or it is cosmetic, or it is in the future
High urgencyMedium urgencyLow urgency
High impactP1P2P3
Medium impactP2P3P4
Low impactP3P4P5
LevelWhat it meansWhat it looks like
P1 CriticalA site, a department or a critical service is down, or money and reputation are at risk right now.The whole floor cannot log in. Payments are failing.
P2 HighSerious, and either wide or fast. It gets attention ahead of everything below it.A team cannot work. One critical service is degraded.
P3 ModerateReal disruption with a workaround, or something narrow that is moving fast.One person completely blocked. A department slowed down.
P4 LowOn the clock, at the back of the queue. Somebody is waiting, it has a target, and it ages.A slow laptop. Access that is needed this week.
P5 PlanningNo clock. Nothing is stopped and nobody is blocked. Done when there is capacity, often batched with similar work.A second monitor. A nice-to-have setting. Something for a future date.
The test that separates P4 from P5. Ask who is waiting. If you can name a person and say what they cannot do until it is done, it is P4 and it has a target. If the honest answer is that nothing is stopped and it would simply be better once it exists, it is P5. Both get done. Only one of them ages.

Read the test in the right place. It decides the bottom row of the grid, where one person is affected and P4 and P5 sit side by side. It is not a way around the grid: a ticket that affects a whole team is medium impact, and medium impact stays at P4 even when nobody is waiting, because the number of people carried it there.
The habit worth building. Before you accept the scope a user gives you, check it yourself. Ask two other people near them, or open the same page from another machine. "Everyone is down" is one person about half the time, and one quiet person is occasionally a whole floor. The scope is yours to establish, not theirs to declare.

3 · Where work goes

DestinationTakesDoes not take
L1 service deskPassword resets, access that is already approved, known how-to answers, basic device help, swapping a failed part from stock.Anything needing a config change on a server or a network device.
L2 technical supportEndpoint faults, one desk with no network, printing, application errors on a machine.Platform-wide outages, identity changes, anything touching a server role.
L3 enterprise systems and infrastructureServer and service faults, identity, platform configuration, network design, address pools, wireless.Single-user issues that have not been ruled out as local.
Cyber GRCAnything suspected security: phishing, suspicious access, possible data exposure, suspected fraud, a device you think is compromised.Nothing. If you suspect security, it goes here.
VendorA system a third party runs and we do not. You still own the user's ticket and the updates.Anything we can fix ourselves.
Not ITFacilities, HR, Finance. Hand it over properly, with a name and a reference.Being closed silently. That is how people learn not to log tickets.
The one rule with no exception. Anything you suspect is a security matter goes to Cyber GRC, and only to Cyber GRC. They are the single door. Do not contact a security operations team directly, do not investigate a mailbox yourself, and do not delete the evidence to be helpful. If you are not sure whether something counts, send it. Being wrong there costs nothing.

4 · When to ask instead of act

Guessing what a user meant is the most expensive habit on a service desk, because you spend an hour on the wrong thing and the user waits anyway. Ask when you cannot answer all four of these:

Ask for all of them in one message. Asking three times in three days is worse than not asking.

5 · The first response

People tolerate waiting far better when they know they have been heard. The first response matters more than most fixes, and it is the part you fully control.

Acknowledge Hello [name], thank you for [calling / writing / coming down]. Reference This is ticket [ITSD-xxxx]. What is true [What you have already established, in one sentence.] What happens [What is being done, and by whom.] When [When they will next hear from you. A real time.] Meanwhile [A workaround, if one exists.]
Do
  • Give a time you will actually meet, even if it is only "before the end of the day"
  • Say what you have already checked, so they know it is being worked
  • Offer the workaround before they ask for it
  • Write for the person, not for the ticket system
Do not
  • Promise a fix time you do not control, especially with a vendor involved
  • Use words the user does not use: SVI, DHCP relay, group membership
  • Blame another team, another user, or the person themselves
  • Close a ticket without telling the person what the answer was

6 · The note you leave behind

Your notes are read by whoever picks it up next, and by you in three months when it happens again. Write what you did and why, not just that you did it.

Not this

Fixed. Closed.

Nobody can repeat this, nobody can count it, and when it recurs next month it starts from zero.

This

Machine held a 169.254 address, so it had no lease. Port Gi1/0/9 on the Floor 2 switch was in VLAN 99, not VLAN 10. Moved the port back to VLAN 10 and renewed. Confirmed with the user that the shared drive opens. Second time this month on a re-patched desk, so I have noted it against the desk move work.

Repeatable, countable, and the last sentence is how a problem record gets found.

7 · Words to avoid with a user

Do not saySay
"Your DHCP lease failed and you are on APIPA.""Your computer did not get an address from the network. I know why and I am fixing it."
"That is a layer 2 problem, not my team.""This one is handled by our network team. I have passed it to them and I will keep you updated."
"It works on my machine.""It is opening from another machine, so this looks specific to yours. Let me check what is different."
"You should have logged a ticket.""I have logged it for you now, so it is not lost. Next time the portal gets it to us faster."
"I will fix it soon.""I will come back to you by two o'clock, even if I do not have the answer yet."

If you remember five things