Warranty, remediation & constrained intervention
Which cases to fix first, when the queue is longer than the crew
Warranty claims, field defects, remediation orders, maintenance backlogs: in every one of them the queue is longer than the crew, and each case costs something different for every week it waits. Most companies work the queue by severity or by who shouted. We work out what each case will cost if it waits, and order the queue by that, so the scarce crew goes where the money and the exposure are. That is often some distance from the loudest complaint.
Test the priority decision on your own cases — the remediation priority check ↝
The decision
What the queue is hiding
Remediation looks like a service queue. Underneath, it is an allocation problem: finite crews, budget and parts, against cases that differ in what they cost to fix, what the contract says, what the customer is worth, and how fast the loss grows while nothing happens.
-
Which cases to handle first?
A prioritisation that reflects the downstream loss of waiting as well as the age of the ticket or the volume of the complaint.
-
How to balance the competing stakes?
Cost to fix, contractual exposure, customer lifetime value and risk rarely point the same way. The order that minimises spend is not the order that protects the most value.
-
What is the downstream loss of waiting?
A defect that will escalate, breach a warranty, or lose a key account is worth acting on before a cosmetic issue that will not, even when the cosmetic one is cheaper to close.
-
Repair, replace, compensate or defer?
Each case has more than one resolution. The cheapest action today is sometimes the most expensive once the exposure it leaves behind is priced in.
Why it matters
Why the order matters more than the speed
Loss compounds while you wait
Some cases sit still and some get worse. Working them in arrival order lets the ones that get worse grow into the expensive ones: a breached contract, a lost account, a recall.
Exposure is invisible in the ticket
The penalty clause, the strategic customer, the defect that turns out to be in the whole batch: none of it is on the ticket. A first-in-first-out list sorts by symptom, and the money is somewhere else.
The cheap fix can be the costly one
Deferring or patching frees a crew today and leaves an exposure that comes back later at a higher price. The action that minimises this week's cost quite often raises the year's.
How we approach it
What we do about it
We estimate what each open case will cost if it waits, using whatever history you have and estimating where you have none. Then we assign the finite crews, budget and parts to protect the most value. The output is an order you can defend to the crew and to the customer, with the reason written beside each line.
For the owner
- A prioritised order for open cases that reflects the cost of waiting, the exposure at stake and the resource each one consumes.
- For each case, a recommended resolution, repair, replace, compensate or defer, with the reasoning made explicit.
- A view of where scarce crews, budget or parts are the true bottleneck, so the constraint that binds is the one you relieve.
For the technical reader
- Prioritisation under constraints, modelled as allocation / assignment of finite remedial capacity across competing cases.
- Expected-downstream-loss estimation per case, with competing-risks thinking where a case can resolve, escalate or breach along different paths.
- Min-cost-flow for the assignment structure where it applies, giving an exact, auditable solve in place of a heuristic ranking.
- Risk-adjusted objectives so the policy is scored on its tail exposure, the rare, costly escalation, as well as its average spend.
- Each policy is compared against the current working order on a shared benchmark before it is trusted, and the comparison is reported as it comes out, including where it does not help.
What we need to see
A record of cases with their cost, contractual terms, customer context and how each resolved, plus the crews, budget and parts that constrain the response. Where the downstream loss of waiting was never recorded, estimating it is the first deliverable, because a priority order is only as honest as the exposure it is built on. The examples on this page illustrate the pattern, and an engagement begins with your own baseline.
Where to start
Where to start
A Decision Opportunity Audit runs on a slice of your open cases, estimates the downstream loss of the current working order, and ends with a clear recommendation. Sometimes that recommendation is that your triage is already close to optimal. If the value is there, a proof of value tests a prioritisation policy against that baseline before anything is built. We do not claim outcomes we have not measured on your data.
The loop
- 1. Baseline & the cost of the current order
- 2. Estimate expected downstream loss per case
- 3. A prioritisation policy under your constraints
- 4. Measured outcome vs. the baseline
The research behind it
The method, published
When this fits
- Remedial demand exceeds the crews, budget or parts available to meet it.
- Cases differ materially in cost, exposure, customer value and how fast the loss grows.
- Someone can change the working order, and act on a resolution recommendation.
When it does not
- Capacity easily clears the queue, so the order barely matters.
- Cases are near-identical, or their downstream loss cannot be estimated at all.
- No route to case, cost or contract data, and no one able to change triage.
FAQ
Questions about remediation
Isn’t worst-first the obvious way to prioritise?
It is the obvious way, and it is usually wrong, because "worst" is judged by how the case looks today and the loss is decided by what it does while it waits. A cosmetic defect on a contract with a penalty clause costs more per week of delay than an ugly one on a contract without. So we order the queue by what each case costs if it waits, and the order that comes out usually looks wrong to the crew for about a week, until the numbers are on the wall.
What does an engagement deliver?
Three things. A prioritised order for open cases that reflects the cost of waiting, the exposure at stake and the resource each one consumes. A recommended resolution per case (repair, replace, compensate or defer) with the reasoning written out. And a view of where scarce crews, budget or parts are the true bottleneck.
What data do you need to start?
A record of cases with their cost, contractual terms, customer context and how each resolved, plus the crews, budget and parts that constrain the response. Where the downstream loss of waiting was never recorded, estimating it is the first deliverable, because a priority order is only as honest as the exposure it is built on.
What if our current triage is already good?
Then the audit says so, and recommends against building anything. We do not claim an improvement we have not measured on your own cases, and "your triage is fine" is a finding we have delivered before.
Is the prioritisation a black box?
No. The output is an order you can defend to the crew and to the customer, with the reason for each position. Where the assignment structure allows it, min-cost-flow gives an exact, auditable solve in place of a heuristic ranking, and each resolution recommendation carries its reasoning explicitly.
Are the examples on this page from clients?
They illustrate the pattern and make no claim about a particular organisation. An engagement begins with your baseline, and the comparison is reported as it comes out, including where a proposed order does not improve on your current one.
Start with the decision
Bring us the queue
A slice of your open cases is enough. A short audit run by a partner will estimate what the current working order is costing you in loss that could have been avoided, and whether a better order is worth building a system for. The fee is fixed before we start.