Slide 1 of 4
Severity is a routing instruction
It is not a label describing how annoying something is. It answers one question: who needs to see this, and how quickly.
Governing agentic GTM
DoLesson 5 of 7Route the review
Mapping severity to owners
Assign each severity level to the role that should hold it, and produce a routing map that survives people changing jobs.
25 minAdvanced
Part 1 of 3
What severity is for
Severity is routinely treated as a description of how bad something is, which makes it a matter of opinion and leads to long arguments that resolve nothing. It is more useful (and more accurate to what it does) to treat it as a routing instruction. Severity answers who needs to see this and how quickly, and nothing else.
That reframing makes the levels definable. Instead of arguing about whether a missing close date is "major" or "moderate", you ask who should act on it and within what window. If the answer for two levels is the same person within the same window, they are one level with two names, and collapsing them is a straightforward improvement.
Part 2 of 3
Define each level by who acts and how fast
Write each level as a test someone else could apply without asking you. A definition that requires your judgment to use is a definition that will be applied inconsistently the moment you are on holiday, and inconsistent severity is worse than no severity, because it makes the routing untrustworthy without making it obviously broken.
Prefer three well-defined levels to five aspirational ones. Every additional level needs a real distinction in owner or urgency to justify it, and in most organizations there are about three genuinely different responses: someone fixes it in the normal course of work, someone is told now, or something stops until it is resolved.
- Name the role that acts — not the person, and not the team in general
- State the window they act within
- Write it as a test a colleague could apply without consulting you
- Collapse any two levels that route identically
Part 3 of 3
Roles, and a load check
Route to roles rather than named individuals, for the same reason plays route to roles: people move, and a map built on names decays quietly. The failure is not visible (exceptions keep routing successfully to somebody who no longer owns the thing) which makes it worse than a loud failure.
Then check the load. For each level, estimate how many exceptions per week it will produce against the rules you authored, and divide by the people holding it. A level firing forty times a week at one person is not high severity in practice regardless of its name, and the fix is upstream: tighten the rule scope, or move the level. Doing this now costs twenty minutes; discovering it after enablement costs the credibility of the whole rule set.
Do this in the product
Build the routing map
- List your severity levels. If there are more than three, look for pairs that route to the same role within the same window.
- For each level, write the role that acts and the window they act in.
- Rewrite each definition as a test a colleague could apply without asking you.
- Map each of your five rules to a level using those definitions.
- Estimate the weekly exception volume per level, and divide by the number of people holding it.
- Where a level would overload its owner, tighten the rule scope or move the level, before enabling anything.
- Confirm every level routes to a role or function, with no named individuals in the map.
Key questions
You should be able to answer each of these from memory before opening it. Recalling the answer is what makes it stick; recognizing it when you read it does not.
What question does severity actually answer?
Who needs to see this, and how quickly. Treating it as a description of how bad something feels makes it a matter of opinion and produces arguments that resolve nothing.
You have five severity levels. How do you know if that is too many?
Then apply the collapse test from the previous chunk to whatever you have written, and check what survives it.
What check do you run before enabling the map?
Estimated weekly exception volume per level divided by the people holding it. A level firing forty times a week at one person is not high severity in practice, whatever it is called.
What to take away
- Severity is a budget, not a label.
- Define each level by who acts and how fast, not by how bad it feels.
- Check the load before you publish the mapping.
Teach this lesson
The argument in 4 slides, for presenting it to your team
Slide 2 of 4
Define each level by who acts
- If two levels route to the same person with the same urgency, you have one level
- Three well-defined levels beat five aspirational ones
- Write the definition as a test someone else could apply
Slide 3 of 4
Route to roles, never to names
A map built on individuals is correct on the day it is written and wrong after the first reorganisation, silently.
Slide 4 of 4
Check the load per level
A severity level that fires forty times a week at one person is not high severity in practice, whatever it is called.
Demo
Try the demo.
See agents carry the repeatable work of GTM across sales, marketing, customer success, and RevOps. Every action prepared, reviewed, and recorded. Fictional data, real product.
Explore the demo