Decagon pricing: model the curve, not the quote

TL;DR

Decagon doesn't publish pricing anywhere on its site, and that's not an oversight, it's the model. Decagon sells custom enterprise contracts priced mainly on usage or outcomes (most commonly tied to resolved conversations) plus a platform or implementation fee, quoted only after a sales call. The number you actually need isn't a sticker price, it's a shape: how that cost moves as your automation rate climbs. Buyers who model that curve before the call negotiate from evidence; buyers who don't walk in asking sales to name a price they've already decided not to publish.

What Decagon actually charges for (since there's no list price)

Search "decagon pricing" and you'll land on a page that asks for your work email. That's consistent across the AI customer support agent category, and it's a deliberate go-to-market choice, not a placeholder for a page still in progress. Enterprise CX buyers are used to it from Sierra and several others in the space: no tiers, no self-serve checkout, no calculator.

What's publicly inferable, from Decagon's own positioning and how the category talks about itself, is the shape of the contract rather than a number. It's usage or outcome-based (charging primarily against resolved conversations, not seats), layered with a platform or implementation fee that covers setup, integration, and account management. Everything else, the actual rate, minimums, and definitions, is negotiated per account and disclosed only inside a signed deal.

That distinction matters more than it looks. A per-seat SaaS price tells you your cost ceiling on day one. A per-resolution price doesn't have a ceiling until you define one in the contract, which is exactly why the next section matters more than the number you were hoping to find.

Why the whole category prices this way, not just Decagon

It's tempting to read Decagon's silence as evasiveness. It's more useful to read it as a category norm. The dominant AI customer support agents have converged on usage or outcome pricing because it solves a sales problem for the vendor: it ties the invoice to a number the buyer already cares about (resolutions, deflected tickets, cost per conversation), which makes the ROI story easy to tell in the room. A per-seat price has to be justified against headcount you're trying to replace, an awkward pitch. A per-resolution price sells itself as "you only pay when it works."

Intercom's Fin is the clearest public data point in the category: Fin is billed per resolution, a rate Intercom actually publishes, which makes it the closest thing to a public benchmark for what "outcome pricing" costs at the low end of the market. Sierra and Decagon both price on a similar outcome basis but keep the number behind an enterprise sales process, reserved for accounts large enough to negotiate custom terms.

Once you see it as a category pattern rather than a Decagon quirk, the buyer's job changes. You're not trying to guess a hidden number. You're evaluating a pricing mechanism, and mechanisms can be modeled even when the specific rate can't.

The cost curve nobody shows you

Here's the part sales calls tend to skip: in a per-resolution model, the same metric you use to prove the agent is working is the metric that grows your bill. That's not a flaw, it's how the incentive is designed to align vendor revenue with customer value. But it means your total cost isn't flat, and it isn't just a function of ticket volume. It's a function of your own automation success.

Picture a contact center with 100,000 conversations a month and a flat per-resolution rate. If the agent resolves 40% of those conversations in month one, you're billed for 40,000 resolutions. If the rollout works and automation climbs to 80% by month six (the outcome everyone in the room was hoping for), your bill roughly doubles, even though conversation volume never moved. The ROI case that got the deal approved ("we'll automate 40% of volume and save X") quietly turns into a bigger invoice the better the product performs.

None of this makes outcome pricing a bad deal. It makes it a variable-cost model that needs to be modeled as a curve, not budgeted as a line item. The buyers who get burned aren't the ones who signed a per-resolution contract, they're the ones who built next year's budget on this year's automation rate and never updated the model when the rate improved.

A criteria framework for evaluating Decagon (or any outcome-priced vendor)

Since the rate itself isn't public, the leverage in a Decagon evaluation comes from the questions you bring to the call, not the number you're hoping to extract from it. Sales conversations move faster, and end in better terms, when the buyer arrives with a checklist instead of a budget ceiling.

Before signing anything, get specific, written answers to:

• How is "resolved" defined, contractually? A conversation the customer abandoned isn't the same as one they confirmed solved their issue; the gap between those definitions is where invoices get contested later.
• Is there a rate floor or cap as volume or automation rate scales? Ask directly whether the per-resolution rate changes at higher volume, and whether there's a ceiling if automation outperforms projections.
• What's the contract minimum, and what happens below it? Usage pricing with a high minimum behaves like a fixed cost; know which one you're actually signing.
• What counts toward overage, and how is it billed? Get the trigger, the rate, and the billing cadence in writing, not verbally.
• Can you see cost per intent, not just cost in aggregate? If the platform can't show you which conversation types are expensive to resolve, you can't manage the curve, only absorb it.
• What happens to pricing at renewal? Year-one rates in usage-based enterprise SaaS are frequently promotional; ask what the model looks like at 2x your current volume.

Where architecture changes what you can control about that curve

Some of this risk is inherent to any black-box, outcome-priced agent: you're trusting the vendor's resolution definition and accepting that cost and success move together by design. That trade buys simplicity, and for teams that want the vendor to own the model, routing, and infrastructure decisions entirely, it's a reasonable one.

Where architecture starts to matter is in how much visibility and control you retain once the contract is signed. A platform that exposes which model runs on which intent, shows usage and cost data before it hits an invoice, and lets a team route cheap, high-volume intents to smaller models while reserving larger models for complex cases gives the buyer levers instead of just a bill. Voiceflow's platform is built around that kind of transparency, with usage visibility and model routing controls documented in its product docs, which is a meaningfully different proposition from a fully managed, opaque per-resolution contract: you trade some of the "it just works" simplicity for the ability to actively manage where your cost curve goes.

Neither approach is categorically wrong. The point of the table isn't to declare a winner, it's to make the tradeoff explicit before you're three weeks into a procurement process and negotiating terms you can't verify.

Key takeaways

• Decagon does not publish pricing; expect a custom, enterprise-quoted contract priced mainly on usage or outcomes (typically per resolved conversation) plus a platform fee.
• This is a category pattern, not a Decagon-specific choice: outcome-based pricing ties vendor revenue to a metric buyers already care about, which is exactly why it's become the default in AI customer support agents.
• Per-resolution pricing means your bill scales with your own automation success. Model that curve against realistic automation-rate improvements before you build a budget or an ROI case around it.
• Bring a written checklist to the sales call (resolution definition, rate caps, contract minimums, overage terms, renewal pricing), not just a budget number.
• Evaluate cost-control levers, like per-intent visibility and model routing, alongside the headline pricing basis; they determine whether you manage the curve or just absorb it.

FAQ

Does Decagon publish its pricing anywhere? No. Decagon sells through an enterprise sales process with custom quotes; there is no public pricing page, calculator, or self-serve tier as of this writing.

What does "outcome-based" or "per-resolution" pricing mean for AI customer support agents? It means the vendor bills primarily for conversations the agent successfully resolves, rather than charging a flat fee per seat or per license. The exact definition of "resolved" is set contractually and varies by vendor, which is why it's the first thing to pin down in negotiation.

Is per-resolution pricing more or less expensive than per-seat SaaS pricing at scale? It depends entirely on your automation rate. At low automation, per-resolution pricing can look cheaper than staffing or seat costs. As automation rate climbs, the bill climbs with it, which can eventually cost more than a comparable fixed-fee model. Model both scenarios before comparing quotes.

What should I ask Decagon's sales team before signing a contract? At minimum: how "resolved" is defined, whether the per-resolution rate has a floor or cap as volume scales, what the contract minimum is, how overages are triggered and billed, and what pricing looks like at renewal once volume grows.

How is Voiceflow's pricing model different from outcome-based pricing? Voiceflow publishes starting usage-based tiers with enterprise pricing available above that, and exposes per-intent cost and model routing controls in-platform, so teams can see and actively manage where spend is going rather than receiving it as a single aggregate invoice.