I'm a senior service designer with 15+ years inside complex organisations. I find how the work actually gets done, including the loops, workarounds and judgement calls no SOP records, then design where agents, code and people each belong.
Most AI efforts stall for the same reason: nobody mapped the real work first. The official process says six steps. The reality is closer to fourteen, with loops, workarounds and a few people who simply know how things get handled.
"Just apply AI" runs into several systems of record, regional variations and knowledge that lives in people's heads. An agent built on the clean version of the process automates the wrong thing, faster.
That gap is where I work. I'm a service designer, not an agent engineer. I lead the discovery, process re-engineering and human-in-the-loop design, and partner with engineering teams so what they build rests on an accurate process map.
Structured interviews with the people who do the work, from heads of function to the person who has handled exceptions for twenty years. This is where tacit knowledge surfaces: why things are done this way, which steps are theatre, and what happens when it goes wrong.
Stakeholder interviews, systems observation, documentation review.
I document the process as it really runs, across teams, systems and channels, including the exceptions, loops and workarounds, and how often each one happens. Often it is the first time anyone has seen the whole thing on one page.
As-is process map, loop and exception frequencies, systems-of-record inventory, handoff analysis.
Every step is sorted into one of four buckets: delete it, handle it with plain code, give it to an agent, or keep a human on it. High-risk steps stay with people, and agents are designed to work inside the systems your teams already use.
Four-bucket redesign, human decision points and handoffs, agent scope and exception handling.
I baseline performance before anything is built, so improvement can be shown rather than asserted: cycle time, straight-through rate, cost per transaction and exception rate, then the same measures again afterwards.
Baseline KPIs, target metrics, before/after measurement plan.
3–4 weeks
Interviews, systems observation and documentation review on one high-value workflow. You get the full as-is process map, a four-bucket redesign, baseline KPIs and an estimate of the impact.
2–4 weeks
I define what an agent should and shouldn't do: scope, exception handling, human decision points, success metrics and how it connects to your existing systems of record. You receive an engineer-ready specification for your team or partners to build from.
Ongoing
Ongoing ownership of process mapping, stakeholder alignment and measurement inside a larger forward-deployed or AI transformation engagement, so engineers keep building on an accurate picture as it changes.
I've worked embedded in complex organisations including BT, National Grid, Waitrose, Publicis Sapient, the Ministry of Justice, House of Fraser, Bupa and Sky. The methods are classic service design. The difference is what they now unlock.
| Deep stakeholder interviews | Creating the "human API": tacit knowledge that lives in people's heads, made usable |
|---|---|
| Process and journey mapping | As-is reality maps, including exceptions, loops and workarounds, not the clean SOP |
| End-to-end service design across teams, systems and channels | Agents designed to live inside existing systems of record, not a new surface |
| Designing decision points and handoffs | Sorting every step: delete, plain code, agentic or human-in-the-loop |
| Baselines and before/after measurement | Cycle time, straight-through rate, cost per transaction and exception rate, proven rather than asserted |
| Translating operational mess into plain language | A case CFOs, CROs and ops leaders can act on |
I'm not a production agent engineer, and I don't build or evaluate multi-agent systems. I lead the process-reengineering and human-in-the-loop design layer, and I partner with engineering teams so agents are built on an accurate map.
A forward deployed engineer (FDE) embeds inside a client organisation to build and deploy AI agents on real workflows. I'm not an FDE and I don't build production agents. I'm a service designer who does the process discovery, redesign and measurement that forward-deployed work depends on, and I work alongside engineering teams.
A short engagement on one high-value workflow. I interview the people who do the work, observe the systems, and review the documentation. You get an as-is process map showing the exceptions, loops and workarounds, a redesign that sorts each step into delete, plain code, agentic or human-in-the-loop, baseline KPIs, and an estimate of impact.
Most stall because no one mapped the real work first. The official process says six steps; the reality is often closer to fourteen, with loops, regional variations and knowledge that lives in people's heads. An agent built on the clean version automates the wrong thing, faster.
Deciding which steps an agent should never take alone, such as approvals, payments, negotiation and sign-off, and designing the handoff so a person can review, challenge and override. It is a service design problem as much as an engineering one.
No. I define the agent's scope, exception handling, human decision points, success metrics and integration points with your existing systems of record, and hand over an engineer-ready specification. Your engineering team or partners build it.
Yes, for work where AI, automation or complex multi-system services are involved. I have 15+ years of service design, UX and research experience in large organisations including BT, National Grid, Waitrose, Publicis Sapient, the Ministry of Justice, House of Fraser, Bupa and Sky.
I'm based between London, UK and Kuala Lumpur, Malaysia, and work with clients globally. Email hello@stephenaris.com with the workflow you suspect is messier than the SOP says, and I'll tell you honestly whether a Process Diagnostic is the right next step.
If you have a workflow you suspect is messier than the SOP says, or an AI programme that needs an accurate process map underneath it, tell me about it. I'll say honestly whether a Process Diagnostic is the right next step. No pitch deck or formal brief needed.