Case studies / Operations
Case studyA support agent that earned its autonomy through approval gates
An operations support desk handed routine requests to an AI agent that asked permission for every action at first, and gained autonomy only as its accuracy was proven.
Overview
The internal operations support desk of a facilities and property services group in Northern Europe, serving employees, contractors and tenants across more than forty managed sites from a single team.
Scale. Roughly 6,000 requests a month, about two-thirds of them routine: access-card changes, password resets, booking amendments, copies of invoices and status questions.
The challenge
The support desk was busy in the wrong way. Its twelve agents spent most of each shift on requests that followed a script: reset a password, reissue an access card, change a meeting-room booking, resend an invoice. Each took a few minutes, but together they filled the queue and pushed genuinely difficult cases to the back.
Response times had drifted from same-morning to next-day. Tenants noticed, site managers complained, and experienced staff were leaving because the work had become repetitive. Hiring more people would have bought time but not changed the shape of the problem.
Leadership was open to automation but wary of it. The desk had authority to change building access and customer accounts. An agent that acted wrongly could lock someone out of a site or send financial documents to the wrong person, so any solution had to show it could be trusted before it was allowed to act alone.
The solution
The agent sits behind the existing ticketing tool rather than replacing it. Requests arrive as before; the agent reads each one, classifies it and checks whether it falls within the types it is permitted to handle. If it does, it gathers the facts it needs, such as the requester's identity, account status and the relevant policy, and prepares a resolution.
What happens next depends on the approval stage for that request type. In the early stage, the proposed action appears in the ticket for a person to approve, edit or reject. In later stages, low-risk actions run immediately and are sampled for review the next day. Every action, approved or automatic, is written to a log with the evidence the agent used.
Escalation is deliberately simple. If the agent is uncertain, if the requester is unhappy, or if the request touches anything outside its limits, it hands over to a person with a short summary so the requester does not have to repeat themselves. A monitoring dashboard shows volumes, accuracy by request type, approval rates and escalations, and the support lead reviews it weekly.
The engagement
- Six months
- Five specialists
- Request analysis, agent design and build, approval workflow, integration with ticketing and identity, monitoring and a staged handover to the support team.
Integrations
- Ticketing system
- Knowledge base
- Customer and tenant account systems
- Identity and access management
- Analytics and monitoring dashboard
How we delivered it
- 01
Analyse the request types
Four weeks
We classified six months of tickets by type, volume, steps and risk. Eleven request types accounted for most of the routine load. Each was rated on how reversible its actions were and how much harm a mistake could cause, which set the order in which the agent would take them on.
- 02
Build the agent with hard limits
Seven weeks
The agent was built to classify requests, gather what it needed from the knowledge base and customer systems, and propose a resolution. It could only use a fixed set of actions, each with its own permission in the identity service, and anything outside those limits went straight to a person.
- 03
Run with approval for every action
Eight weeks
For the first two months, every proposed action waited for a staff member to approve it in the ticketing tool. Approvers saw the request, the agent's reasoning and the exact change it intended to make. Rejections and edits were recorded against the request type.
- 04
Reduce approvals as accuracy proved
Seven weeks
Once a request type passed an agreed accuracy threshold over a meaningful sample, approval moved from every action to a daily sample, and later to exceptions only. High-risk actions, such as granting new site access, kept a person in the loop permanently.
Results
- Routine requests closed faster, with a median time measured in minutes
- Support staff refocused on complex and sensitive cases
- All agent actions logged with reasoning and evidence
- High-risk actions kept under permanent human approval
Routine requests now close in minutes rather than hours. Within six months the agent was resolving a large share of the routine load end to end, and preparing most of the rest for quick approval. The queue that once hid difficult cases has shrunk to a size the team can work through in a morning.
Staff time moved to the complex cases that need judgement: disputes, access problems at sites with special rules and requests from tenants with unusual contracts. Two experienced team members who had planned to leave stayed on to supervise the agent and maintain the knowledge base.
Because every action was logged with its evidence, the operations director could answer the question that matters to auditors and customers: why did the system do that? That record also made each decision to relax a gate straightforward to defend.
We never had to take the agent on trust. Every step towards more autonomy came with the numbers to back it, and we could see exactly what it had done and why.
What made the difference
Approval gates were relaxed only with evidence. Each request type earned its autonomy separately, on measured accuracy over a real sample, and the riskiest actions never lost their human check.
