Digital operations accumulate irritations. A screen loads slowly. A report needs one extra export. A form asks for information twice. At the same time, less visible weaknesses may be building: an integration that can silently drop transactions, a workflow that depends on one employee, an unsupported database, or a finance process with no reliable reconciliation.
If every complaint is treated as urgent, improvement work becomes reactive. If visible irritation is ignored, staff lose confidence and workarounds spread. The useful discipline is to evaluate problems by business consequence rather than by the volume of complaints.
Urgency should follow exposure, not noise.
Why the loudest problem is not always the most important
Complaint volume measures how many people notice a problem and how often. It does not measure what the problem could cost. A slow screen used by forty people every day generates constant feedback. A nightly integration that occasionally fails to pass orders to the warehouse may generate none at all until a customer complains that their delivery never arrived.
Several biases push the wrong items to the top. Visible problems feel more real than latent ones. Senior people's irritations travel further than frontline ones. Recent incidents feel more likely than they are. And problems with a clear technical fix are more attractive to work on than ambiguous ones involving ownership or process.
Start with the outcome that can fail
Ask what business outcome the system supports. Revenue collection, customer onboarding, fulfilment, payroll, regulatory evidence and service continuity deserve different treatment from a minor convenience feature. The same technical defect can therefore have very different urgency depending on where it sits.
A useful first test is: if this fails completely tomorrow, what stops? If the answer is "almost nothing", the problem may be annoying rather than urgent. If cash, customer commitments, safety, compliance or critical decisions are affected, the issue belongs much higher in the queue.
Continuity planning offers a helpful question to borrow. NIST defines maximum tolerable downtime as the amount of time a business process can be disrupted without causing significant harm. Its contingency planning guide uses a business impact analysis to help organisations decide contingency requirements and priorities. Asking "how long could we tolerate this being broken?" separates problems more quickly than asking "how annoying is it?".
Score exposure across four dimensions
Risk management usually treats risk as a combination of two things: the adverse impact if an event occurs and the likelihood that it will, as in NIST's definition of risk. For operational systems, two further dimensions are worth adding.
- Impact: how serious is the consequence if the problem materialises?
- Probability: how likely is the failure or recurring disruption?
- Dependency: how many other workflows, teams or systems rely on it?
- Reversibility: how difficult is recovery once something goes wrong?
High-impact, hard-to-reverse failures should normally outrank highly visible but reversible inconvenience. A manual workaround may be acceptable for a low-frequency task; it is dangerous when it is the only control protecting a high-value process.
Keep the scoring simple. A three-point scale for each dimension, applied consistently and with a sentence of reasoning, is more useful than a precise-looking model that nobody trusts. The value lies in making the reasoning visible and comparable.
Illustrative comparisons
| Problem | Visibility | Exposure | Likely classification |
|---|---|---|---|
| Expense system takes several seconds to load each claim | High: many users complain | Limited, reversible, no downstream dependency | Annoyance; fix when convenient |
| Order integration fails silently a few times a month | Low: few people notice | Lost or late orders, customer harm, hard to reconstruct | Urgent improvement |
| Payroll adjustments rely on one person's spreadsheet | None until they are absent | Business interruption, control failure | Important but planned, rising to urgent before peak periods |
These are hypothetical examples. The point is the reasoning, not the specific answers, which will differ between businesses.
Look for hidden multipliers
Some problems appear small because the cost is distributed. Five minutes of repeated manual checking can look trivial until it occurs hundreds of times each week. A weak handoff can seem like a people issue until missed context creates rework across several teams.
Frequency, scale and coordination cost should therefore be included in the assessment. This is why operational friction often deserves more attention than the individual symptom suggests.
Warning signs that something annoying is becoming urgent
- A workaround has become the only thing standing between the business and a failure.
- The number of people who understand the fix is falling.
- The same "minor" issue appears in several teams under different names.
- Errors are being found by customers rather than by internal checks.
- Recovery depends on reconstructing data from emails or memory.
- The issue sits on a process with a fixed deadline, such as payroll, month-end close or regulatory reporting.
Separate incident urgency from improvement priority
An active outage may need immediate containment even if the long-term system is not strategically important. Conversely, a fragile architecture may deserve high improvement priority even when nothing is currently broken.
Use two queues: incident response for live disruption, and improvement prioritisation for structural risk and recurring cost. Combining them creates a permanent firefighting culture in which preventive work never reaches the front.
A practical decision rule
Classify a problem as urgent when delay materially increases exposure to lost revenue, customer harm, control failure, unrecoverable data loss or business interruption. Classify it as important but planned when the issue creates recurring cost or fragility without an immediate failure condition. Treat it as an annoyance when the impact is limited, reversible and contained.
This does not mean ignoring annoyances. Many small annoyances are signals, and a backlog that never fixes anything visible will lose the trust of the people reporting problems. A sensible compromise is to reserve a small, fixed share of improvement capacity for quick fixes to common irritations, while protecting the rest for higher-exposure work. The point is to prevent annoyances from displacing issues with greater business consequence.
A short diagnostic for your current backlog
- For the top five items, can anyone explain in one sentence what business outcome each one protects?
- Is there anything on the list that would stop cash, customers or compliance if it failed tomorrow, and is it near the top?
- Which known weaknesses are not on the list at all because nobody complains about them?
- Are live incidents and structural improvements competing in the same queue?
- When was the ranking last revisited, and what changed?
What better looks like
A mature improvement backlog can explain why one item sits above another. Leaders see the business exposure, teams understand the trade-off, and limited capacity is directed toward problems that remove the most risk or friction per unit of effort. Quiet, high-exposure weaknesses are found deliberately rather than discovered through failure. Related reading: why every important integration needs an owner and key-person dependency is a systems problem.
Sources and further reading
- risk - Glossary - CSRC (last verified 10 October 2026)
- Maximum Tolerable Downtime - Glossary - CSRC (last verified 10 October 2026)
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems - CSRC (last verified 10 October 2026)
Related Mellorca reading
- How to decide what technology problem to solve first
- Piling on more software is not digital maturity
- How to build a business case for systems improvement