Use a real service request to evaluate what the workflow accomplishes, how it handles exceptions, and whether the result is useful to the person and the business. Inspect the conversation alongside the resulting system state and any work that reaches a team member.
The worksheet is for one defined workflow, such as changing an appointment. It is an operator tool; it reports no Koltra test results.
First, make the evaluation specific
Record the request type, the systems involved, and the person responsible for reviewing the result. Agree what a useful outcome means, which cases are included, and what should remain with people.
For an appointment change, the intended outcome might be a permitted change reflected in the scheduling system and clearly communicated to the person. If no suitable option exists, record that outcome separately from a successful change. A well-handled unresolved request can be useful without being counted as a completed appointment change.
Download the blank evaluation worksheet to record your own cases. Repeat its seven-question block for each case.
The worksheet
Record evidence status separately from outcome assessment. Evidence can be observed, not demonstrated, or need follow-up. The assessed behavior may meet the agreed case outcome, fail to meet it, or remain unassessed. An observed failure supplies evidence of a problem. Add its evidence reference and the action needed; keep that separate from a passing result.
| Question | What to inspect | What to record |
|---|---|---|
| Did the workflow understand the need? | The request, relevant preferences, and any clarification. | Misunderstandings, corrections, and missing context. |
| Did it perform the intended action? | The corresponding system result, not only the response spoken to the person. | Action attempted, result verified, and anything still pending. |
| Did it stay within its permitted scope? | A case involving an exception, ambiguity, or an action it should not take. | Whether it followed the agreed route and which person remained responsible. |
| Could a person continue the work? | What reached the receiving team and whether responsibility was accepted. | Missing context, ownership, and any period without a clear next step. |
| Was the experience useful to the person? | Whether the next step was understandable, plus relevant direct feedback. | Confusion, repeated effort, or needs left unresolved. |
| Did it help the business? | The outcome that matters locally and the effort or cost of producing it. | Useful results, rework, staff effort, and measurement limits. |
| Did a proposed improvement help? | Subsequent comparable work after the change. | What changed, what was observed, and other plausible explanations. |
Try more than the easy case
Include an ordinary request, an unavailable option, an ambiguous request, a system failure, and a case requiring a person. Add cases that reflect the actual service and its users. Record how they were chosen; a curated demonstration is not a representative performance estimate.
Repeat the cases after meaningful changes and retain unsuccessful examples. Mark an action not demonstrated when the evidence is unavailable.
A worked example
Scenario: a person asks to move an appointment and the agent says the change is complete.
Evidence inspected: the conversation records the request, but the available evidence contains no confirmation from the scheduling system.
Assessment: the conversation was observed; the appointment change was not demonstrated. The next step is to inspect the system result or reproduce the workflow in an appropriate test environment. The result remains unassessed until that evidence is available.
If the workflow instead reports that no suitable appointment is available and the practice accepts the follow-up, record an accepted handoff with the appointment request unresolved. That is different from both a completed change and work left without an owner.
This example is synthetic and is not an evaluation of a customer deployment.
Keep the measures interpretable
Define the start, end, and included cases before reporting a completion rate. Keep abandoned, failed, and partially completed attempts visible in the appropriate denominator. The GOV.UK Service Manual provides a useful general explanation of that relationship; its service-specific rules should not be transplanted automatically. Completion-rate guidance
Choose a small set of measures that answers whether this workflow is useful. Staff time released is different from cash saved; an offered appointment is different from realized revenue; inferred sentiment is different from reported satisfaction. Record how each measure is obtained before using it to justify a business claim.
Finish with a decision: which cases are acceptable, which need more evidence, and which require changes. Assign the next action to a person who can resolve it.
See the blank Operation Record reference for optional supporting fields. Use only the parts that help your evaluation.