Urgency vs. Impact: How I Triaged Tickets on a Factory Floor

On a help desk, the word "urgent" loses its meaning fast. Every caller's problem is the most important problem in the building, at least to them. And honestly, from where they sit, they're right. If your machine won't start, your workday has stopped.

When I worked as an IT Support Specialist at a manufacturing plant with more than 1,200 users, I couldn't fix everything at once. Neither could anyone else on the team. What kept us effective wasn't working faster. It was deciding, quickly and consistently, what to work on first.

This article explains the simple approach I used: rank every issue by urgency and by impact, and let those two answers set the order. It's not a new idea. Most IT service management frameworks use some version of it. But I want to show how it works in a busy, real-world environment, and why the same thinking sits at the heart of security incident response.

Two questions, not one

Most people prioritize by asking one question: "How bad is this?" The problem is that "bad" mixes two different things.

Urgency is about time. How quickly will things get worse if nobody acts? A problem that stops work right now is urgent. A problem that will matter next week is not.

Impact is about scope. How many people, processes or systems are affected, and how important are they to the business? One user's slow laptop is low impact. A label printer that stops a production line is high impact, even though it's only one device.

Separating the two gives you a grid with four boxes.

The matrix

High urgency, high impact: drop everything. A network switch fails and a whole section of the floor loses access to the systems that track production. A shared server stops responding. These issues affect many people and are getting worse by the minute. They get immediate attention, and usually more than one person.

High urgency, low impact: fix fast, but keep it small. One supervisor can't log in five minutes before a shift handover. It matters right now, but only to one person. The goal here is a quick workaround: a spare machine, a password reset, a temporary account. A full root-cause investigation can come later.

Low urgency, high impact: plan it properly. A known fault affects many users but has a workaround, or a system will need replacing before it fails. These are easy to postpone forever, which is exactly why they need a plan, an owner and a date. In my role, the network infrastructure upgrade projects I helped coordinate often started as issues in this box.

Low urgency, low impact: queue it. A request for a second monitor, a cosmetic software glitch, a "nice to have." These still deserve a response and a realistic timeframe. They just don't jump the queue.

How it worked on the floor

In practice, triage happened in seconds, often while the caller was still talking. I'd ask a few short questions:

• What exactly can't you do? "My computer is broken" isn't actionable. "I can't print shipping labels" is.
• Is anyone else affected? One person or a whole line changes everything.
• Is there a workaround? If you can use another machine or another printer for now, urgency drops.
• When does it need to work? Before the next shift, before a shipment leaves, by the end of the week?

Those answers placed the ticket in one of the four boxes. Then I recorded the reasoning in the ticket itself, so anyone picking it up could see why it had that priority.

That last step mattered more than it sounds. Priorities change. A low-impact issue becomes high impact when the same complaint arrives from ten more people. If the original ticket explains the reasoning, it's easy to re-rank it. If it just says "P3," nobody knows what assumption changed.

The traps I learned to avoid

The loudest voice isn't the highest priority. Some people escalate everything. Others never complain, even when their problem is serious. Asking the same questions every time removes personality from the decision.

Seniority isn't impact. A manager's request is sometimes high impact because of what they're responsible for, but not automatically. A machine on the production line can matter more than an executive's second monitor.

"Quick wins" can eat your day. It's tempting to clear lots of small tickets to make the queue look healthy. That's fine, unless a high-impact issue is waiting while you do it.

Workarounds can become permanent. A temporary fix lowers urgency, which is good. But if nobody comes back to address the cause, the same issue resurfaces later, often at a worse time. I learned to log workarounds clearly and leave the ticket open for the real fix.

Patterns hide in single tickets. Three separate users reporting slow file access might be three low-impact tickets, or one high-impact problem with a shared server. Looking across the queue, not just at the ticket in front of you, is part of triage.

Communication is part of the fix

Triage only works if people trust it. A user whose ticket is placed lower in the queue will accept that if they understand why and when to expect help.

So I always tried to tell people three things: what I thought the problem was, where it sat in the queue and roughly when they'd hear back. If the estimate changed, I updated them before they had to chase me. It sounds simple, but it prevented a huge number of follow-up calls and frustrated escalations, which freed up more time to actually fix things.

Why this is security work too

When I studied Cybersecurity and Threat Management at Seneca Polytechnic, I noticed how closely incident response mirrors help desk triage.

A security team receives a constant stream of alerts. Most are harmless. Some are false positives. A few matter a great deal. Analysts can't investigate everything at the same depth, so they triage, using the same two questions in different words:

• Urgency: Is this attack active right now? Is it spreading? Will waiting make it worse?
• Impact: Which systems and data are involved? How sensitive are they? How many users or customers could be affected?

An alert on a single test machine with no sensitive data is very different from suspicious activity on a server holding customer records, even if the alerts look similar at first.

Security triage adds a few extra questions, like whether the activity matches known attacker behaviour and how confident the detection is. But the core habit is the same one I practised on the factory floor: decide quickly, record your reasoning, communicate clearly and revisit the decision when new information arrives.

What I'd tell a new help desk analyst

If you're new to support, triage can feel uncomfortable at first. You're making judgment calls about other people's problems, and some of them won't like your answer. A few things helped me.

Be consistent before you're clever. Asking the same four questions every time matters more than finding the perfect priority for any single ticket. Consistency is what makes the queue fair, and fairness is what makes people accept it.

Escalate early, not late. If a ticket looks like it could be high impact and you're not sure, flag it to a senior colleague straight away. A false alarm costs a few minutes. A missed outage can cost a shift.

Learn the business, not just the technology. Triage depends on understanding what matters to the organization. At the plant, I learned which systems each line depended on, which shifts were busiest and which deadlines couldn't move. That knowledge turned "a printer is offline" into "the shipping label printer is offline two hours before a dispatch," which is a very different ticket.

Own your queue. Check in on your open tickets even when nobody is chasing you. The issues that quietly sit for days are the ones that come back as complaints, or as bigger problems.

Protect your focus for the big ones. When a high-urgency, high-impact incident hits, it's fine to let low-priority work wait. Tell people that's what's happening, then give the incident your full attention until it's stable.

A simple template you can use

If your team doesn't have a clear triage method, try this for a week:

1. For every new ticket, write one line on what the user can't do.
2. Rate urgency as high or low: will it get worse soon if nobody acts?
3. Rate impact as high or low: how many people or how much business is affected?
4. Place it in the matrix and record the reason in the ticket.
5. Tell the user where it sits and when they'll hear back.
6. Review open tickets daily and re-rank anything where the facts have changed.

You'll find the queue becomes calmer, escalations drop and the important work gets done first. And if you're thinking about a move into security, you'll be practising one of the most important skills an analyst needs.

How does your team decide what gets fixed first?