Research-backed calculator guide

AI Support Cost per Conversation vs Per Resolution: Find the Billing Break-Even

Compare AI support cost per conversation with per-resolution billing using a denominator check, break-even equation, worked example, and invoice audit checklist.

Why the denominator changes the answer

A conversation is a volume unit. A resolution is an outcome unit. They answer different questions:

• Conversation billing asks: How many eligible interactions did the AI handle?
• Resolution billing asks: How many interactions met the vendor's success condition?

That difference creates two opposing cost curves. Conversation billing is easier to forecast from traffic because the bill does not depend on whether the AI solved the issue. Resolution billing can produce a lower effective cost per conversation when the resolution rate is modest, but its billed volume changes as the AI succeeds more often.

Neither description is enough for procurement. Ask what starts and ends a conversation. It might be a helpdesk ticket, a channel-specific session window, or a thread that closes after inactivity. Ask what counts as a resolution. It could require an explicit confirmation, allow customer inactivity after an answer, or include a configured workflow handoff. Intercom's published rules, for example, count a resolution when a customer confirms an answer or leaves without requesting more help, while a successful Procedure handoff is another billable outcome. ^[2]

This is why a lower sticker price can be misleading. A $0.80 conversation may be more expensive than a $0.99 resolution if every conversation is billed and only half of them reach a billable outcome. The reverse can also happen when an AI resolves nearly every eligible interaction or when a per-resolution contract adds a large platform minimum.

The break-even equation

Start with the two monthly cost equations:

Cost_conversation = C × p_c + F_c

Cost_resolution = C × r × p_r + F_r

Here, F_c and F_r include fixed platform, seat, minimum-commitment, implementation, or required add-on fees that belong in the comparison period. To solve for the resolution rate at which the offers cost the same:

r_break-even = (C × p_c + F_c − F_r) ÷ (C × p_r)

When fixed fees are equal or intentionally excluded, this reduces to p_c ÷ p_r. Keep the rate as a decimal in the calculation, then convert it to a percentage for the decision. A result over 100% means the resolution offer is cheaper at every feasible resolution rate under the stated assumptions. A negative result means the fixed-fee difference has already made the resolution offer more expensive before usage is considered.

The equation is a comparison tool, not a prediction. It assumes the units cover the same traffic, the rate is measured over the same period, and the vendor does not apply different minimums, free allowances, overages, channel multipliers, or outcome exclusions. If those conditions fail, use the extended equation and split the traffic into comparable cohorts.

Worked cost example

Assume a buyer is comparing two illustrative offers for the same 12,000 monthly support conversations. These rates are intentionally hypothetical so the reader can see the method; they are not a quote from either vendor. Fixed fees are excluded because the first pass tests the usage meter alone.

At 65%, the per-resolution offer costs $1,878 less each month. The result is not because “resolution pricing always wins.” It follows from the rates and the fact that only 65% of the common denominator becomes billable. At 80.81%, the resolution offer would bill approximately 9,697 outcomes and cost about $9,600, matching the conversation bill when the stated rates are held constant; the exact equality is reached by the equation, not by rounding the table.

Now add fixed fees. If the conversation vendor requires $1,200 per month for a platform and the resolution vendor requires $2,400, the resolution offer has a $1,200 fixed-fee disadvantage. With 12,000 conversations, its adjusted break-even rate becomes:

(12,000 × $0.80 + $1,200 − $2,400) ÷ (12,000 × $0.99) = 70.71%

That adjustment is material. A buyer who compares only usage prices could choose the wrong model because the fixed platform difference moves the threshold by more than ten percentage points.

Separate vendor facts from your normalized model

Public prices are useful inputs, but they should not be treated as a universal price index. On November 2, 2026, Intercom's public pricing page listed Fin from $0.99 per outcome and showed separate seat pricing for Intercom plans; it also described a no-seat option when Fin is used with an existing helpdesk. ^[1] Its outcome documentation says an outcome is charged at most once per conversation and that unsuccessful attempts or ordinary escalations are not billed, while certain configured handoffs are billable. ^[2]

Salesforce's Agentforce pricing page listed Conversations at $2 per conversation and Flex Credits at $500 per 100,000 credits. It also explains that actions consume credits and gives illustrative examples where a two-action request uses 40 credits, or $0.20 at that published rate. ^[3] That is a different denominator from a conversation. A support team must count expected actions per case before comparing the credit model with a flat conversation fee.

Zendesk's pricing page listed Suite Team at $55 per agent per month, Suite Professional at $115, and Copilot as a $50 per-agent monthly add-on when billed annually. It describes AI-agent billing through successful automated resolutions and tells buyers to include seats, add-ons, resolutions above allowances, and billing cadence in the estimate. ^[4] Those fixed and usage layers should not be collapsed into a single “AI cost per conversation” number without documenting the allocation.

Treat all public prices as time-stamped observations. Vendor pages can change, currencies can differ, and enterprise contracts can contain minimums or negotiated rates. Record the URL, date, currency, billing cadence, included allowance, and whether the number is a published list price, an estimate, or a vendor quote. Do not present an illustrative rate as a vendor promise.

A practical normalization worksheet

Use this sequence before choosing a billing model:

1. Freeze the population. Choose one month or a representative cohort. Count eligible conversations, not total website visits or bot messages.
2. Define the boundary. Write down what starts and ends a conversation, ticket, session, or interaction. Note the inactivity window and channel rules.
3. Define success. State whether resolution requires explicit confirmation, an answer followed by inactivity, no escalation, a completed workflow, or another condition.
4. Measure the rate. Compute billable resolutions ÷ eligible conversations for the same period. Separate chat, email, voice, and asynchronous tickets if their rules differ.
5. Normalize fixed fees. Include required seats, platform subscriptions, minimum commitments, implementation amortization, premium channels, and add-ons. Keep optional services in a separate scenario.
6. Model the tail. Add a low, base, and high resolution-rate case. Include traffic growth and an overage case instead of relying on one average.
7. Reconcile the bill. Match usage exports to invoice rows. Check duplicates, retries, reopened conversations, cross-period outcomes, refunds, free allowances, and currency conversion.

For a broader monthly model, use the AI Agent Cost Calculator to combine usage with fixed operating costs. If the decision is sensitive to spikes, connect the scenario to the AI agent budget guardrail and P95 calculator so the chosen rate does not hide a high-cost tail. After launch, the AI API invoice reconciliation calculator can help turn a vendor export into an auditable ledger.

What to put in the contract or vendor scorecard

A useful scorecard has one row per billable event. Capture the event name, trigger, excluded cases, time of recognition, price, minimum, maximum, and evidence available to the buyer. Ask for a sample invoice and a sample usage export before signing.

The most important questions are:

• Is the unit a ticket, session, conversation, reply, action, resolution, or outcome?
• Can one customer issue produce multiple billable units after reopening or channel transfer?
• What happens if the customer asks for a human, the AI gives an incomplete answer, or a workflow fails?
• Is a resolution recognized immediately or after a quiet period? Can a later re-open reverse the charge?
• Are successful handoffs billable even when a human still completes the case?
• What free allowance, minimum commitment, tier threshold, and overage rate applies?
• Are voice, email, messaging, and asynchronous channels metered in the same way?
• Can the vendor expose the conversation IDs behind each billed unit?

These questions protect the denominator. They also prevent a finance team from comparing a vendor's “cost per outcome” with another vendor's “cost per attempt” as though the labels described the same economic event.

When each model can fit

Per-conversation billing can fit a team that values a simple volume-linked ceiling, has high and stable resolution rates, or is still testing whether the AI should be allowed to resolve cases. It is easier to forecast when the conversation boundary is clear. Its weakness is that failed attempts still consume paid units.

Per-resolution billing can fit a team that wants usage to follow successful outcomes and has enough instrumentation to audit the definition. It can have a lower effective cost per conversation when the resolution rate is below the calculated break-even threshold. Its weakness is that spend rises as more conversations qualify, and ambiguous success rules can undermine the apparent value alignment.

Action or credit billing can fit workflows whose complexity varies widely. A short answer and a multi-step case need not consume the same number of actions, but that flexibility makes the workload profile essential. Salesforce's published examples illustrate why counting actions per use case is necessary before translating credits into a support cost. ^[3]

The right choice is therefore not the model with the smallest unit price. It is the model whose unit is observable, whose fixed fees are included, and whose break-even remains acceptable across plausible traffic and resolution-rate scenarios.

FAQ

What is the fastest way to calculate AI support cost per conversation?

Start with total monthly usage cost plus allocated fixed fees, then divide by eligible conversations: (usage charges + fixed fees) ÷ eligible conversations. For per-conversation billing, usage is usually conversation count × price. For per-resolution billing, usage is conversation count × resolution rate × price per resolution. Keep the two counts separate until the final normalization so a resolution is not accidentally treated as a conversation.

Is per-resolution pricing always cheaper than per-conversation pricing?

No. It is cheaper only under the stated rates, fixed fees, and resolution definition. With equal fixed fees, compare the observed resolution rate with price per conversation ÷ price per resolution. If the rate is higher than that threshold, the resolution offer bills enough outcomes to exceed the conversation offer. Minimums, platform fees, free allowances, overages, and channel-specific rules can move the threshold.

What should count as a resolution in the calculation?

Use the vendor's contractual definition, not a generic industry assumption. Record whether a resolution needs customer confirmation, treats inactivity after an answer as success, includes a configured handoff, or excludes an escalation. Intercom's current documentation provides a concrete example of why this matters: it distinguishes confirmed or assumed resolutions from unsuccessful attempts, while Procedure handoffs can be billable outcomes. ^[2] If you cannot obtain conversation-level evidence for the billed events, mark the resolution rate as an estimate and run a sensitivity range.

How do fixed platform and seat fees change the break-even?

They can materially change it, especially at lower volumes. Use r = (C × p_c + F_c − F_r) ÷ (C × p_r) rather than the simplified ratio. A resolution model with a higher platform fee may lose even when its usage rate looks attractive. Conversely, a conversation model that requires a separate helpdesk or paid seats may be more expensive than its usage price suggests.

Should retries, reopened tickets, or handoffs be included?

Include them whenever they create a billable event under the contract. Do not automatically multiply the conversation count by message count or assume a handoff is free. Build a ledger with conversation IDs, channel, start and end timestamps, event type, outcome status, and invoice line. Then test reopened cases, cross-channel transfers, and failed workflows separately. The purpose is to reconcile the vendor's definition to the cost denominator used in your business case.

How often should the comparison be refreshed?

Refresh it whenever price cards, plan allowances, billing definitions, or channel rules change, and at least once per billing cycle during a pilot. Record the checked date beside every public price. Vendor pages may show annual versus monthly rates, local currency conversions, or negotiated terms. A dated worksheet makes it clear which inputs are observed vendor prices and which are your own workload assumptions.