156
Requests handled
Submitted across the four weeks. Every one of them has an owner in the record — none drifted without one.
Sample evidence pack
This is the report a pilot team receives at the end of week 4: what was handled, what the numbers say, what improved — and what missed, with the miss included. A report that only shows wins is not evidence.
A sample, not a result.
Illustrative workflow using sample data. No customer data shown.
Week 4
Four numbers, each with its definition agreed in week 0. Every one of them is fictional — this page shows the report's structure, not anyone's results.
156
Submitted across the four weeks. Every one of them has an owner in the record — none drifted without one.
91%
First-response targets met across all urgencies. The target agreed in week 0 was 90% — met, but not everywhere (see below).
14
Safety-flagged requests; 14 of 14 acknowledged within the 15-minute target. Zero unacknowledged, all pilot long.
38 min
Down from 2h 41m in week 1. The queue stopped being decided by whoever noticed a problem first.
Illustrative workflow using sample data. No customer data shown.
Volume & SLA
The overall number is 91% against a 90% target. The per-urgency breakdown is where the honest reading lives: Medium missed.
156 total across the pilot. Steady volume, not a launch spike.
Illustrative workflow using sample data. No customer data shown.
Black marker: the target agreed in week 0. Amber: missed.
Illustrative workflow using sample data. No customer data shown.
Safety
Safety escalations carry an explicit acknowledgement target agreed in week 0. This measure is reported separately from everything else, on purpose.
14 safety-flagged requests over four weeks.
Zero unacknowledged safety flags for the entire pilot. The median acknowledgement time for safety flags was 6 minutes.
Illustrative workflow using sample data. No customer data shown.
A blended SLA number can hide a safety failure inside a good average. So safety is counted on its own, every week, with its own target — and a single unacknowledged safety flag would put it at the top of this report, ahead of every win on this page.
This pilot had none. The report says so plainly because the weeks where it does not will say that just as plainly.
Vendors
A promise without a recorded date is not a commitment. The pilot tracked both: did we record the promised date, and was it met.
96 requests involved a vendor. Black marker: the 90% target.
75 of 96 vendor jobs had a promised date recorded; 48 of those 75 were completed by the promised date.
Illustrative workflow using sample data. No customer data shown.
The misses are the most useful part of this section. Two of the three regular vendors would not give promised dates by email, so engineers logged “TBC” — which is how 21 jobs ended up with no commitment at all. That is a process gap, not a vendor conspiracy, and it has an agreed fix in the section below.
Improvement
A pilot should show the operation getting visibly better — or say honestly that it did not. These two measures moved.
Minutes from submission to someone taking responsibility.
Illustrative workflow using sample data. No customer data shown.
Share of the open queue with no owner assigned, end of each week.
Illustrative workflow using sample data. No customer data shown.
Honest accounting
Three things did not hit their targets. Each one has a cause and an agreed fix — that is what makes the next four weeks different from the last four.
Why: Two of the three regular vendors would not give promised dates by email, so engineers logged “TBC” instead of a date. 21 of 96 vendor jobs had no recorded commitment — and a commitment you do not record is one you cannot hold.
Fix: Agreed fix: a vendor job can no longer move to “in progress” without a promised date. Phone confirmations count — logged with who confirmed and when.
Why: Three Medium requests missed the 24-hour first-response target. The furthest miss was a fictional request (JFS-2419), acknowledged 47 minutes late because the assigned owner was on leave and the request was never reassigned to the deputy.
Fix: Agreed fix: a deputy-owner rule for leave cover, so no request sits with someone who is not there.
Why: The loading-bay shutter has been reported three times this month (fictional JFS-2422). Each fix held for a week. Root cause is not yet established, so it is flagged as a problem-record candidate instead of being closed again.
Fix: It is in this report because closing it a third time without a root cause would be the point of the exercise failing.
Illustrative workflow using sample data. No customer data shown.
Method
The structure matters more than any number on this page.
Your pilot
Tell us what “working” means for your team, and we will build the pilot's success criteria around it — then report against them, misses included.