9. Delivery, Triage & Recovery

Weighing contract value, risk of churn, severity, and strategic importance consistently means the decision can be explained the same way every time, not reconstructed after the fact to justify whichever choice already felt easiest.

A clear "not today, and here's why, and here's when" — grounded in the same criteria used every time — preserves the relationship far better than silence or an unexplained delay.

This is Section 3's ICP-as-capacity-allocation logic under live time pressure — the rubric built there for choosing accounts is the same rubric that should decide which account gets today.

Ask specifically: is this blocked because the product can't do it, because it hasn't been built yet, because a system won't connect, because data isn't there, because security hasn't approved it, or because people won't use it. Each answer points to a different owner and a different fix.

Misdiagnosing category means escalating to someone who can't actually resolve it, then re-diagnosing and escalating again — slower overall than taking the extra minute to categorize correctly first.

This connects directly to Section 8's organisational resistance lesson — "we're stuck" that's actually a resistance problem needs a completely different response than "we're stuck" that's a genuine integration blocker.

Under customer pressure, guessing at a fast fix feels productive. It usually isn't — a wrong guess wastes time and may not address the actual cause, while the same methodical chain that works offline still finds the real issue fastest, even under pressure.

(Decision tree)

Trace inspection first, then retrieval quality, then prompting — the order doesn't change just because the customer wants an answer immediately.

This is Section 5's RAG diagnosis tree and Section 6's incident response discipline, applied simultaneously, under the added pressure of a customer watching in real time.

Discovery and offline evaluation (Section 6) test against a fixed, known set of cases. Real usage generates cases no one anticipated — this is expected, not a sign the earlier work was wrong.

A genuinely failing deployment needs the same methodical diagnostic approach as any other AI failure — panic and quick, unverified fixes tend to make a bad situation harder to reason about, not better.

A retrospective without a committed fix plan doesn't actually recover anything — diagnosis alone is only half the job.

Pair an honest retrospective (what went wrong and why) with a concrete fix plan — specific changes, owners, and timeline — not just a diagnosis without a committed path to resolution.