Support agents — scripted bots versus agents, and outcome pricing
Customer-facing AI divides into scripted bots that branch through anticipated questions and agents given a goal and a set of tools. They are different products with different deployment plans and different commercial models. Outcome-based pricing is the clearest signal of that difference.
AI Tools Hub Editorial · published · updated
The two shapes
| Scripted | Agent | |
|---|---|---|
| How it is built | A tree of anticipated questions and answers | A goal plus the tools it may use |
| Unanticipated questions | Cannot answer; transfers to a human | Reasons and attempts a response |
| Preparation | Enumerating question patterns | Documented procedures and a current knowledge base |
| Predictability | High — it does what was defined | Lower — requires validation |
| Actions available | Showing an answer | Operating systems: returns, rescheduling, refunds |
| Billing | Seats or conversations | Outcome-based models are appearing |
The scripted ceiling is that it answers only what its author imagined. Real enquiries spread wider than that, so coverage plateaus — and pushing coverage up by adding branches eventually makes the thing unmaintainable.
An agent reads the knowledge base and reasons, so a differently phrased question still lands. The cost is that what it will say is not fixed in advance, which means validation and monitoring become part of the deployment.
Why outcome pricing appeared
Sierra states publicly that it prices on outcomes — payment tied to value delivered rather than to seats or conversation counts.
That is possible because an agent deployment can measure resolution. A conversation where the customer did not come back and no transfer occurred can reasonably be counted as resolved. A traditional bot only knew that it had displayed an answer.
For the buyer, the appeal is that poor performance costs less. The negotiation then centres on the definition: does a transferred conversation count, and what happens when a customer returns about the same issue a week later? Settle that in writing before signing.
Deciding what to hand over
Designing for full coverage from day one fails. Widen in stages.
- Stage 1: questions the FAQ already answers; everything else transfers immediately
- Stage 2: add read-only operations such as order status lookups
- Stage 3: add write operations such as accepting a return or changing a booking
- Stage 4: delegate some exception handling
Stage three is the boundary. Once the agent writes to systems, a wrong action persists in real data. Move only after the design is reversible — queue the action for human approval, or make it automatically revertible within a window.
What to check for non-English deployments
- Can register and tone be tuned? Excessive formality reads badly
- Can apology wording be controlled? A casual apology can read as an admission
- Can the transfer criteria be specified in prose?
- Are the conversation logs readable in that language for audit and improvement?
The second is underrated. An automatic 'we are sorry for the trouble this has caused' can become a record of accepting responsibility. If the agent takes first-line complaints, confirm that apology language is controllable.
What happens to the human team
Once AI takes first line, what reaches people is only the hard cases. That does not reduce load. The easy enquiries that provided breathing room disappear, and difficult cases arrive back to back.
Redesign the human role at the same time as the deployment. Cutting headcount on the assumption that volume falls leaves a smaller team facing a harder average case.
Frequently asked questions
How good does our knowledge base have to be?
It is the project. An agent inherits whatever the documentation says, so stale articles become confident wrong answers. Budget the clean-up before the deployment, not after.
Is outcome pricing always better for the buyer?
Only if the definition of an outcome is tight. A loose definition can count transfers and repeat contacts as successes, which is worse than paying per seat.
Related
More articles
Opinion
Why AI rollouts fail in Japanese companies — four structural reasons
For business
Enterprise AI rollout checklist — SOC 2, ISO 27001, DPAs and personal data
For business
Japanese-developed LLMs for business — ELYZA, Sakana AI, NTT tsuzumi and PLaMo
Comparison
AI coding tools compared — Cursor, Copilot, Claude Code, Windsurf and Codeium