Insights · Approach
AI agents: from pilot to production
A prototype is quick to build. Getting an AI agent to process real orders day to day usually takes more than a better model.
Why so many pilots get stuck
Many companies have launched AI pilots over the past few years: a chat over internal documents, an assistant for service requests, a prototype that pulls orders out of emails. The demos work. Only some of them make it into day-to-day operations.
The model is rarely the problem. What’s usually missing is everything around it:
- Isolated solutions: the pilot runs in one system or in its own interface, while the actual process spans SAP, Salesforce and Microsoft. Handovers stay manual.
- No write access: the agent may read and suggest. In the end someone still types the order in by hand, and the benefit stays small.
- No governance: until permissions, approvals and audit are sorted out, IT security won’t sign off on production access. Rightly so.
- No operations: nobody is responsible when the agent produces wrong results over the weekend. Monitoring, versioning and a controlled change process are missing.
- No business case: the pilot proved that something is technically possible, not what it’s worth. Without KPIs defined upfront, there’s no basis for a budget.
What a production agent needs
A production agent is part of the process landscape. It reads from and writes to the systems where the process happens, with its own identity and checked permissions. Fixed rules decide which cases it closes on its own and which go to a person. In voluro Nexus this is Guarded Autonomy: for every action, Nexus decides whether the agent executes it automatically, requests approval or is blocked.
Then there’s operations. Versioned deployments, separate development, test and production environments, monitoring and a complete audit trail are a given for any other enterprise software. Agents are no exception.
Start with one process
A common reflex in AI programs is breadth: many use cases in parallel, each with its own prototype. None of them goes deep enough to change a process in a way people notice.
A single process with real volume, measurable effort and handovers between systems is a better starting point. In many companies, order-to-cash fits that description. Between the won opportunity in Salesforce and the sales order in SAP sit checks, back-and-forth and manual data entry. Standard cases can be automated there, while exceptions go to the right decision-makers under control.
From process check to operating model
Start with one process, grow into an operating model. Here’s the path in four steps.
Process check
One concrete process, the systems involved and a first assessment of how much can be automated.
Proof of value
A Process Pack such as order-to-cash runs on voluro Nexus against your real systems in test or sandbox environments. KPIs and targets are agreed beforehand. You end up with a solid basis for a decision.
Production
The agent goes live with agreed policies and approval paths. Monitoring shows how the KPIs develop in daily operations.
Expansion
More processes follow, tools and policies are reused, and native agents such as Joule, Agentforce or Copilot are brought in. Step by step, an operating model takes shape.
The KPIs that matter
Whether an agent pays off comes down to a handful of KPIs. Measure the baseline before the proof of value starts, otherwise all you’ll have at the end is an impression.
| KPI | What it shows |
|---|---|
| STP rate (straight-through processing) | Share of transactions that complete without manual intervention |
| Manual interventions per transaction | How often someone still has to rework, complete or correct |
| Cycle time | Time from won opportunity to confirmed SAP order |
| Exception rate | Share of cases routed to a person as exceptions, and why |
| Cost per transaction | Internal effort plus operating cost per processed order |
What agents do has to be measurable.
The exception rate deserves a closer look. If it stays high, the cause may be incomplete master data or unclear rules rather than the agent. Findings like these are a useful by-product of the proof of value, because they improve the process whether or not AI is involved.
Frequently asked questions
Why a fixed price for the proof of value?
So the decision doesn’t hinge on open-ended effort. Process, scope and KPIs are agreed upfront, and you know from day one what you’re committing to.
Does the proof of value use production data?
It runs against your real systems in test or sandbox environments. We decide together with your IT and data protection team which data is used.
What if the targets aren’t met?
Then you’ve made an informed decision without production risk. In that case the proof of value also shows which prerequisites are missing, for instance in master data or rules.
Do we need our own AI team?
Not to get started. The voluro team takes the first process into production and supports the expansion. Through Continuous Enablement, your team builds its own expertise along the way.
Read on
Free process check
In 30 minutes, a verbal first assessment of whether a proof of value makes sense for your process.
Proof of value & go-live
Fixed price, 4–6 weeks, measurable KPIs.
Order-to-Cash Pack
The typical first process for a proof of value.
Operating model
How the first process grows into a manageable agent portfolio.
What is agentic process automation?
The fundamentals: definition, how it works and where it stops.
How AI agents write to SAP safely
The technical building blocks for agents that write.
AI agent, RPA or workflow?
Which process step needs an agent and where a workflow is enough.
Glossary
Human-in-the-loop, STP rate, AI register and other terms explained briefly.
Sources and further documentation
Start with one process.
30 minutes · free · with a senior architect. You get a verbal initial assessment and concrete next steps.