LEARN. PRACTICE. GROW.1. Separate milestone from outcome
Imagine a fictional customer requesting a statement to finish reconciliation. The portal confirms submission, but the statement may arrive incomplete later. There are two different milestones: submitting and obtaining usable information. Define the start and end of each measure without losing the complete path. The first milestone helps locate interaction failures; the second assesses the intended outcome. Page availability replaces neither. Map the path with waiting, returns and customer tasks. Ask at which point the user can actually continue their work.
2. Investigate missing groups
A preference reported by a sponsor is useful information, but it needs evidence from affected people. If the night shift supposedly prefers chat, observe the task, working environment and current help-seeking behavior. Include people who abandon, need support or did not respond to an invitation. More interviews with the group already able to use the service do not address missing groups. Record hypothesis, observation and degree of confirmation separately. These research techniques complement DSV themes; GOV.UK documentation concerns government services and does not establish mandatory bank procedures.
3. Compare what is included
Do not compare two offerings only by name and price. “Support included” may mean request receipt in one offering and diagnosis with intervention in another. Make hours, tasks, dependencies, demand limits, ownership and exclusions explicit. In the local example, Base covers 08:00–18:00 at 900 euros monthly and Extended covers 08:00–24:00 at 1300. Usage from 10:00 to 22:00 is not fully covered by Base without another approved solution. Extended satisfies the hours condition, but still needs cost approval and checks against other requirements. An informally available person does not automatically become part of the offering.
4. Negotiate a feasible commitment
The customer may need 55 same-day responses while the offering supports only 40. Moving 15 to tomorrow changes the promised outcome. Expose the gap and discuss capacity, scope or timing with authorized decision-makers. If delivery depends on a supplier without agreed timing, do not turn the desired hour into a guarantee. Document partial states: approved scope, pending cost and hours under analysis can coexist. An overall approval message would erase those conditions; saying nothing was decided would also be inaccurate. The relationship becomes more predictable when every decision has an identified state, condition and owner.
5. Define population and rule before the result
A measurable SLA needs an outcome, window, population, data source and exception rule. In this workshop’s fictional rule, only tests identified at entry are excluded. Of 100 requests, ten tests leave 90 eligible; 81 on-time requests represent 90%. Do not remove nine late real requests to obtain 100%. If a supplier failed, explain that cause separately while retaining the current rule. Any future change needs agreement. Segmentation is another dimension: if the minimum is 95% per shift, an overall average above 95% does not compensate for a shift at 60%. Acceptance criteria determine the conclusion.
6. Agreement workshop and summary
Prepare a short proposal for the fictional statement customer: usable outcome, delivery window, expected volume, support coverage and validator. Add two evidence rows: 110 on-time day requests out of 110 and six night requests out of ten. Under a 95%-per-shift rule, identify the night failure and propose investigation without inventing the cause. Also show the aggregate of 116/120, about 96.7%, explaining why it does not change the conclusion. Summary: start from the task, validate needs, compare concrete offerings, negotiate conditions and retain a stable measurement rule understood by the parties.
Population: 100 requests
Tests excluded at entry: 10
Eligible real requests: 90
On-time real requests: 81
Result: 81 / 90 = 90%
Late real requests remain in the denominator.Day: 110/110 = 100%. Night: 6/10 = 60%. Overall: 116/120 ≈ 96.7%. A 95% minimum per shift is not met.
Common pitfalls
Solution as need; authority as evidence of preference; price as complete value; retrospective exclusions; overall average as per-group compliance.
Related topics: Customer journey · Service levels
A useful agreement defines the needed outcome and makes delivery and measurement conditions verifiable.
Reference: ITIL 4 Specialist: Drive Stakeholder Value · ITIL 4 DSV; observed JA v1.0.1 (2025 copyright), current EN revision comparison pending