Stage History, Breaches and Attainment
Stage history records how long a case spent at each point in its lifecycle. It is what turns a set of deadlines into an understanding of where time actually goes.
Where to find it
Architect Panel → Automation:
- Obligations — each obligation, its stage history and its outcome
Architect Panel → Dashboards:
- Explore — attainment and breach reporting over that history
Why stage history matters
When a statutory deadline is missed, the useful question is not who was holding it at the end. It is where the time went.
A case that breached at twenty days having sat unallocated for twelve has an allocation problem, not a caseworker problem. Without stage history that investigation is a reconstruction from memory and email timestamps, and it usually concludes with the wrong person being spoken to.
Breaches are recorded, not inferred
A breach is written as a fact, so it can be counted, explained and reported. Record the reason where one exists — an obligation breached because the complainant did not respond is a categorically different thing from one breached because nobody picked it up, and a performance figure that conflates them is not useful to anyone.
Attainment against the original
Because the original due date is kept alongside the current one, attainment reporting can distinguish three things that are usually collapsed into one number:
- What was originally agreed or required.
- What the deadline became after legitimate holds.
- What actually happened.
"We agreed five days and took nine, of which three were on hold" is a far more useful sentence than "58% within target", and it is the sentence that survives a challenge.
Reporting
Obligations and their history are queryable like any other datastore, so a performance return is generated rather than assembled. That is usually the immediate reason a service adopts obligations at all — and it is worth building the report early, because it tells you whether the configuration reflects reality.
Use it to change the process, not to grade people
The pattern to look for is a single stage consuming most of the window. That is where an intervention belongs.
Adding a reminder two days before the deadline does not help if the case spent three weeks waiting for a decision that took ten minutes to make. Stage history tells you which of those you have, and they need completely different fixes.
Worked example — a housing repairs service
Repairs have a fourteen-day target. Attainment sits at 71% and nobody can say why. Stage history shows a median of nine days between "reported" and "surveyed", and two days for everything after. The intervention is survey capacity, not repair capacity — which is the opposite of what the team had assumed and had been recruiting for.
Recommendations
- Report medians as well as averages. A handful of very old cases will drag an average somewhere misleading.
- Break attainment down by stage before drawing conclusions. The headline number rarely tells you what to change.
- Record breach reasons consistently. A free-text reason nobody categorises cannot be counted.
- Publish the figures internally. Teams improve what they can see; a performance report that only leadership reads changes nothing.