# Three customers call on the same morning: how an FDE ranks work by severity, urgency and SLA

> The customer who shouts loudest is not always the one who needs you first. If you work on reflex, you can breach an SLA before you have opened a single log.

Original: https://fdetimes.net/en/guides/fde-incident-triage-severity-urgency-sla/

Picture this: it is 8:40 in the morning and your phone buzzes three times in ten minutes. Three customers, three urgent voices, and each one is sure their problem comes first.

At this point most engineers act on reflex: they deal with whoever is loudest, or whoever called first. Either way, you can breach a signed commitment without noticing.

Suppose you look after three deployments, and each customer has its own contract, working hours and importance. The skill you need is to put the work in order within fifteen minutes and be able to explain why.

## Three different questions, not one

The root mistake is to squeeze everything into a single word: "urgent". Each call actually contains three separate questions, and each has its own answer.

The first is severity: how much harm the incident does to users and to the business. At the top of the scale, PagerDuty gives the example of SEV-1, a critical incident that affects a large number of customers, usually needs a public notice and calls for someone to work directly with senior leadership.

The second is urgency, meaning how sensitive the problem is to time. A small bug can still be very urgent if the customer has to submit a report at 2pm.

The third is the response time you have committed to. As Plain describes it, a support SLA is a measurable commitment to the customer about how quickly you respond and how quickly you resolve. The answer here does not depend on anyone's feelings. It is in the contract.

Priority is not a fourth question but the result of the other three. It decides when you start work and how fast you react. The ITIL approach sums it up as Priority = f(Impact, Urgency).

## One morning, three calls

Back to the hypothetical. Customer A is a logistics company: the report export is broken for one analyst, and the report has to go to the board at 2pm. Small impact, high urgency.

Customer B is a retail chain: the agent that answers stock questions is giving wrong numbers to every store employee. Wide impact, and assume the contract promises a first response within 30 minutes for P1.

Plain says the typical first-response target for a P1 incident is 15 to 60 minutes, so this assumed figure sits within the usual range.

Customer C is a bank running a pilot, the most strategically important account. They complain that model latency has risen slightly on an internal dashboard, and there is no deadline. Low impact, low urgency, but a very big name.

The table below is a sample matrix for turning the two axes into a priority level. The exact thresholds will differ from company to company. What matters is having the matrix before the phone rings.

| | Urgent deadline | Distant deadline |
|---|---|---|
| **Wide impact** | P1 — customer B | P2 |
| **Narrow impact** | P2 — customer A | P3 — customer C (before considering an upgrade) |

The sensible order: B first, then A, with C scheduled. But the order in which you fix is not the order in which you get in touch, and this is exactly where many people lose marks.

## Respond first, fix second

Plain splits the SLA into two clocks: first response and resolution. Resolution time is harder to control because some bugs need the engineering team, so Plain recommends setting a separate target for each priority level. The first response, by contrast, is entirely in your hands.

So at 8:50, before opening any logs, you send three messages. To B: "Acknowledged, classifying as P1, next update at 9:20." To A: "Understood, your deadline is 2pm; you will have a solution before 11." To C: "Received; we will assess it this afternoon and report back before the end of the day."

**Key point:** Reply to every customer first to keep your commitments, then fix in order of severity and deadline.

Writing these three messages takes only a few minutes. In return, B has had a first response within the committed window, A knows you understand their deadline, and C knows they have been heard even though they are not being dealt with yet.

For A, an urgent deadline does not mean the root cause must be fixed now. A manual CSV export, sent before 11, meets their real need, which is a report for the meeting. The underlying bug can be fixed tomorrow.

## Can a big customer jump the queue?

incident.io acknowledges that a less severe incident affecting a large customer may deserve a higher level. That is fair, and you could well raise customer C from P3 to P2. But raise it for a reason you can write down, such as the pilot's review meeting coming up soon. Do not raise it out of fear.

If you let customer C jump ahead of customer B, thousands of retail staff will keep getting wrong stock figures while you tune an internal dashboard. When someone asks about it later, you will have no argument to defend that decision.

## Try it: five steps in the first fifteen minutes

Step one: write each call down in one sentence: who is affected, how many people, what the symptom is. Step two: score severity by the number of users and business processes blocked, not by the caller's tone of voice.

Step three: ask directly: "By what time do you need a result, and why?" The "why" often reveals a workaround. Step four: look up each customer's SLA and send the first responses, starting with the customer whose committed window is shortest.

Step five: post the priority order and the reasons in the team's shared channel. When a manager or account manager asks why customer C has to wait, the answer is already there.

## The familiar traps

The most common trap is treating severity and priority as the same thing, so a small bug with an urgent deadline is forgotten until 1:55pm. The second is promising a resolution time over the phone, when the only thing you truly control is the response time.

The third trap is going silent while you fix. The customer cannot see you reading logs; they only see that no message has arrived. Set the time of the next update and keep to it, even when there is no news.

## Turn the skill into evidence

When you read an FDE job description, look for phrases such as on-call, SLA, escalation and working with several customers at once. They signal that the role demands exactly this skill. In interviews, tell the story of a real triage across all three axes, impact, deadline and commitment, then say what you chose and why.

On a CV, one specific line carries more weight than "works well under pressure". For example: "Triaged incidents for four customers in parallel with no first-response SLA breaches in a quarter". Only include figures you can prove.

The morning of three calls will come again. With a matrix and message templates ready, the first fifteen minutes will be far less frantic.

**Try this week:**

- Go back over your last 10 tickets, score the severity and urgency of each, and compare that with the order you actually worked in.
- Read the contract or SLA of the customers you look after and write down the committed first-response time for each priority level.
- Draft a first-response message template with three points: acknowledged, being assessed, time of the next update.

## Sources

- [Understanding the differences between severity vs priority in incident management](https://incident.io/blog/differences-between-severity-and-priority)

- [Incident severity vs priority: What's the difference?](https://firehydrant.com/blog/incident-severity-and-priority-101/)

- [Incident Severity Classification: Best Practices to Speed Resolution](https://www.pagerduty.com/resources/incident-management-response/learn/incident-severity-classification/)

- [How to Create Priority Calculation](https://oneuptime.com/blog/post/2026-01-30-priority-calculation/view)

- [Customer Support SLAs for B2B SaaS: How to Set, Measure, and Actually Hit Them (2026)](https://www.plain.com/blog/customer-support-slas-b2b-saas-2026)