Who Owns the Call? Decision Rights for AI-Assisted Service Operations
Photo: https://www.flickr.com/photos/mattbuck007/, CC BY-SA 2.0, via Wikimedia Commons
AI triage, copilots and automated routing are now part of the everyday operating model in many UK service teams. They shorten queues, surface knowledge and push work to the next available person. They also create a quiet governance problem: when a case is misrouted, a customer receives the wrong remedy or a vulnerable claimant is missed, the workflow may show activity but not ownership. The accountability layer is the part of the service operating model that answers a simple question: who owns the call, and on what basis?
The accountability gap is an operating model problem
It is tempting to treat accountability as a training issue or a model-risk artefact. In practice it is a design choice. AI changes the sequence of work, but it does not absorb responsibility. A copilot can draft a response; a human still needs the authority and evidence to approve it. Automated routing can move a case; someone still needs to own the outcome when the route is wrong. In regulated services, the Senior Managers and Certification Regime and sector conduct rules make that ownership explicit. In non-regulated services, the same logic applies through customer outcomes, complaint handling and UK GDPR obligations.
The operating model therefore needs an accountability layer: a documented set of controls that sits across intake, decision rights, escalation and audit. It should be light enough to use in a weekly service huddle and robust enough to satisfy an internal audit review.
Four components to design
Intake: capture the context, not just the request
AI-assisted intake often starts with classification. That is useful, but the operating model must record the facts that drive accountability: customer segment, vulnerability indicators, regulatory status, previous commitments and the source of the request. Without that context, the model can route accurately by topic and still miss the reason the case matters. Operations leads should define mandatory fields for high-risk journeys and a manual override for ambiguous cases.
Decision rights: name the owner and the basis
For each significant decision, the canvas should state who decides, who advises, who must be informed and who can stop the process. A useful distinction is between automated recommendation, human approval and human decision. The first needs a named reviewer; the second needs a named approver; the third needs a named decision-maker with the competence to depart from the model. Decision rights should be recorded at role level, not just team level, so that absence and handover do not create orphans.
Escalation triggers: define when the human takes over
AI-assisted operations need explicit triggers for human review. Typical triggers include low model confidence, conflicting data, vulnerable customer indicators, regulatory time limits, repeated contact and any case where the automated route would create a detrimental outcome. Triggers should be tested in simulation and reviewed monthly. A trigger that never fires may be too narrow; one that fires constantly will be bypassed.
Audit trails: make the decision inspectable
The audit trail should show the input, the recommendation, the human decision and the reason for any override. It does not need to capture every keystroke. It does need to answer three questions: what did the system suggest, what did the human decide, and what evidence supported that decision? For regulated services, this should align with existing record-keeping and complaints evidence. For non-regulated services, it is still the minimum for a credible root-cause review.
A practical canvas for operations leads
| Layer | Core question | Evidence to capture | Named owner |
|---|---|---|---|
| Intake | What facts determine risk and priority? | Mandatory fields, source, vulnerability flags | Head of service intake |
| Decision rights | Who can approve, override or stop? | Role matrix, delegation limits | Service owner |
| Escalation | When must a human take over? | Trigger list, test results, review log | Operations manager |
| Audit | Can we reconstruct the decision? | Decision log, override reasons, review sample | Quality lead |
The canvas works best when completed for one customer journey at a time. Start with the journey that has the highest regulatory exposure or the highest complaint volume. Do not attempt to map the whole operation in a single workshop; the output will be too abstract to govern.
Regulated and non-regulated services
In regulated services, the accountability layer should connect to existing governance: conduct risk, model risk, complaints and the senior manager responsible for the activity. The language can be proportionate. A bank does not need a new committee for every copilot, but it does need a clear line from the model to the accountable executive. In non-regulated services, the layer can be simpler: a service owner, a decision log and a monthly sample review. The principle is the same. AI can change the workflow; the operating model must still make accountability explicit.
Making it stick
Treat the canvas as a live control, not a one-off document. Review escalation triggers after every material incident. Sample audit trails monthly. Add decision-rights changes to change control. And in 2026 planning, give the accountability layer a named owner in the service operating model. The aim is not to slow AI down. It is to make the human contribution visible, testable and defensible.
