Most BPO proposals describe the path that already works. Eighty percent of a document queue is repetitive: the file is complete, the fields match, a person or a model can close it. The other twenty is why operations leaders search for exception management. That minority is where cost, delay, and audit risk actually live. Outcome BPO is built around that minority.
Name the classes before you automate
An exception class is a sentence a new operator can follow. “Identity document expired.” “Name on the file does not match the application.” “Supporting proof is missing a page.” “Policy says a person must sign this jurisdiction.” If the class is only “other,” you do not have a design. You have a junk drawer, and the model will fill it.
We write the classes with the people who run the queue today. Then we decide, class by class, whether the model may close, whether a human must touch, and whether the case escalates. That list is the scope. Anything not on it is a discovery, not a surprise we hide inside a green dashboard.
Ownership is a desk, not a prompt
“The AI will flag it” is not ownership. Ownership is a role that sees the hold while it is still inside the window you agreed, and a record of what they did. Aging has to be visible. A case that sits in a shared inbox until the client asks about it has already failed the SLA, whatever the contract says.
- Every exception class has an owner before go-live.
- The queue shows age, not just volume.
- A close without a decision and a timestamp is not a close.
- If Xeres owns the desk, that accountability is in the statement of work.
Where this meets an agent
Agents are useful on the repetitive path and dangerous on an unnamed exception. The guardrail is the same trail we use everywhere else: input, draft, decision, owner, time. That operating model is governed AI ops. The commercial question — do you want us to own the desk — is outcome-based BPO. Email hello@xeres.tech with the queue that is breaking.