The business case for an in-app agent, and its missing number

Every ROI model for this category has the same structure and the same hole. The structure is a funnel with a cost line under it. The hole is the single input that decides the answer: how much a conversational path changes completion, for your users, on your flow.

There is no credible public number for that. Vendor case studies report it, and almost none of them trace to a methodology you can inspect. This post is about building the model anyway, honestly, and about which parts of the result you will be able to defend afterwards.

Start from what you already know#

Pick one flow rather than the whole app. Take the number of users who reach its first step in a month, and the number who finish. That gap, multiplied by what a finished one is worth, is the entire size of the prize. Everything else is a fraction of it.

Do the same for support. Count contacts on the topics an agent would cover, and multiply by your cost per contact. Most teams have that number and have never put it next to a product decision.

Those two figures bound the upside. If the gap in your flow is small, or the support topics are not ones an agent could answer, the model is finished and the answer is no. That happens more often than vendor content admits, and finding it out in an afternoon is worth more than a quarter of building.

The number nobody can give you#

Two sourced figures are worth holding in view while you set the assumption.

Gartner surveyed 5,728 customers and found that only 14% of customer service and support issues were fully resolved through a company’s self-service channel. That is the base rate for self-service resolution as it exists in the world, across every channel and vendor. Any model assuming an agent will resolve most of what it sees is arguing with that figure and should say why.

Contentsquare’s digital experience benchmark, drawing on “99 billion web and app sessions across 6K+ sites” and published 9 March 2026, puts conversion at 2.9% for returning visitors and 1.7% for new ones. Those are the orders of magnitude your flow is moving within. A model predicting a large absolute lift on top of a 2% baseline is predicting something unusual.

Set your assumption inside those bounds, write it down as an assumption, and design the first release so it produces the real number within a few weeks.

What an agent can actually change#

The mechanism is specific. An agent removes steps where the step exists because the interface needed the user to supply something one field at a time. It does nothing about a step that exists because a decision has not been made, or because your price is wrong, or because the item is out of stock.

Baymard’s cart abandonment list is the best available map of which is which. The headline 70.22% is “an average calculated based on 50 different studies”, last updated 22 September 2025, so treat it as a rough constant of the medium rather than a current reading. The breakdown is what matters. Excluding people who were only browsing, 18% abandon over mandatory account creation and 17% over a checkout that is too long or complex. Those are the structural ones. Another 40% abandon over extra costs, and no conversational interface has ever made a shipping fee smaller.

So the honest version of the claim is narrow: an agent can plausibly act on about a third of the reasons people leave, and only if your flow actually has those reasons in it. Check your own exit data before assuming it does.

Which levers you can defend afterwards#

The upper band is the set you should instrument before the first release, because after launch there is no way to reconstruct it. Task completion per intent is the one that matters most, and it has to be per intent: an agent that answers balance questions perfectly and refund questions badly has a fine average and a specific problem.

The lower band is where most published ROI claims live. Tickets never opened cannot be counted. Counterfactual conversion needs a holdout, and most teams will not run one on a flow that touches revenue. Say so in the model rather than filling the cell.

If you can run a holdout, run it. A fifty-fifty split on one flow for four weeks answers the question the entire model was guessing at, and it is the only thing that will.

The cost side#

Two lines, and one of them is not the one people budget for.

Running cost per turn is the visible line. It scales with usage and you can estimate it from a vendor’s pricing or from your own inference spend. Our own turns are input-dominated, because the system prompt and the tool schemas are re-sent every time, which means cost tracks the size of your tool surface more than the length of the conversation.

The line people miss is the tool layer. Naming your operations, writing the error text, deciding what may write, and designing the confirm card is engineering that does not finish at launch. Anthropic’s own note on building agents puts it bluntly: “We actually spent more time optimizing our tools than the overall prompt.” Build versus buy prices the version where you own the rest of the stack too.

The vertical question#

The original version of this post promised sector-specific conversion data for banking, delivery and commerce. That data does not exist in a citable form, so it is not here.

What does transfer across sectors is the shape of the opportunity. Look for a flow with many required inputs and a high abandonment rate, and a support queue with repetitive questions that have a data answer. A bank has both. A delivery app has both. A single-product subscription app usually has neither, and no agent will invent them.

How to present it#

An ROI model for this reads better as a range with a named assumption than as a single number with a confident total. The single number invites an argument about the number. The range invites an argument about the assumption, which is the conversation you actually want.

Show the size of the prize first, because it is the figure nobody disputes: the gap between users who reach a step and users who finish it, multiplied by what a finished one is worth. Then show what share of that gap is structural, using your own exit reasons rather than an industry average.

Then state the assumption on its own line, with the sentence that justifies it and the date you will replace it with a measurement. A model that says which cell is a guess is more persuasive than one that hides it, and it survives contact with a finance team that has seen this genre before.

What to build first#

Build the read-only version of one flow, instrument the upper band, and ship it to a slice of users. Measure completion per intent for four weeks. Then decide whether to extend it to the write path, which is where the real value and the real risk both live. What the first week of real traffic shows is worth reading before you set expectations for that window, because the surprises are consistent across tenants.

Time to a first working turn is a bad proxy for any of this. Nordic APIs makes the point about APIs generally and it applies exactly here: “Making a first call is very different from someone becoming an active user.”

Two posts follow from this one. What the complete stack costs to own covers what you are buying, and the metrics that tell you it is working covers the instrumentation in detail.

Sources#

• CX Today, Only 1 in 7 customer service queries resolved with self-service, Gartner study finds, 19 August 2024, reporting a Gartner survey of 5,728 customers. Accessed 12 September 2026.
• Contentsquare, Digital Experience Benchmark: conversions, published 9 March 2026. Accessed 12 September 2026.
• Baymard Institute, Cart abandonment rate statistics, last updated 22 September 2025. Accessed 12 September 2026.
• Anthropic, Building effective agents, 19 December 2024. Accessed 12 September 2026.
• Nordic APIs, Why time to first call is a vital API metric, 9 November 2021. Accessed 12 September 2026.