Why We Kept Salesforce's Agentforce Help Agent Out of the Seat-Compression Catalog

Salesforce's Agentforce Help Agent went generally available in July 2026 at $2 per successful resolution. The pricing has a genuinely fair wrinkle: you pay nothing when the customer asks for a human, and nothing when the customer leaves unhappy. You pay only for resolutions the agent actually closes on its own. That sits alongside the rest of the Agentforce meter menu, $2 per conversation and Flex Credits at $0.10 per action, all verified against CIO coverage and Salesforce Ben on July 2.

We looked at it for the catalog and did not add it. Not because it is a bad product, but because it has no seat lever, and forcing a per-resolution meter into a per-seat compression model produces a number that is worse than useless. This post is the reasoning, because the reasoning is the same test a CFO should run before wiring any outcome-priced agent into a spend model built for seats.

The catalog is a seat model, and the Help Agent is not a seat product

SeatCompress compresses seats. The whole engine is built on one arithmetic: seats you pay for, minus seats you actually use or that an agent can absorb, times price, times twelve. Every agent in the catalog carries a compression percentage against a per-seat tool, because that is the unit the model speaks in.

The Agentforce Help Agent does not have a seat. It has a resolution meter. There is nothing to compress, because there is no per-seat license attached to the agent to begin with. It is priced on the outcome it delivers, not on how many humans sit next to it. Adding it to the catalog would mean either inventing a per-seat equivalent it does not have, or attaching a compression percentage to a target it does not cleanly replace. Both would be fabrication, and we hold a hard line against fabricated numbers: a compression figure that cannot be sourced or defended does not go in the catalog, and an outcome meter has no seat figure to defend.

This is the broader shift we wrote about in why enterprise SaaS is moving to outcome-based pricing. The AI-native cohort does not price on headcount because its own cost to serve is not headcount-bound. That is good for buyers in most ways, but it means the seat-compression lens goes dark on these products. You do not compress a meter. You manage its volume.

The category error: modeling a meter against a seat stack

Here is what happens when you try to force it. Take an enterprise running Zendesk for support, 300 agent seats at the catalog rate of $115 per seat per month.

• Zendesk seat stack: 300 times $115 times 12 equals $414,000 a year.

Now ask the seat-compression question the model is built to ask: how many resolutions does the Help Agent's $2 meter buy before it consumes the entire Zendesk seat budget?

• $414,000 divided by $2 equals 207,000 resolutions a year, which is 17,250 resolutions a month.

That is the whole problem in one line. A 300-agent enterprise support org resolves far more than 17,250 tickets a month. If each agent closes roughly 25 tickets a workday across 20 workdays, that is 500 a month per agent, or 150,000 resolutions a month across the team. Run the meter against that real volume:

• 150,000 resolutions a month times $2 times 12 equals $3,600,000 a year if the agent handled every one of them.

The meter, at full deflection, costs 8.7 times the entire Zendesk seat stack. So a spend model that tried to score the Help Agent as a seat-compression lever would report something absurd: spend $3.6M to save at most $414,000. That is not an insight. It is a category error, and it is the exact output you get when you point a per-seat model at a per-resolution product.

What the meter actually competes with

The reason the number comes out insane is that the $2 meter is not priced against the Zendesk software seat. It is priced against the human labor that resolves the ticket. A support seat license is the software cost, a small fraction of what a support organization spends. The salary, benefits, and management of the humans doing the resolving is the large number, and that is the number a $2-per-resolution meter is quietly competing with.

That comparison can be favorable. A resolution that a loaded human handles for more than $2 is a resolution the agent can win on cost. But that is a labor-substitution business case, not a seat-compression one, and it belongs in a workforce model, not a SaaS-spend dashboard. Keeping the two separate is the discipline. The moment you blend them, you either overstate the savings by crediting the agent with labor it did not have to displace, or you understate the cost by hiding the meter inside a seat line.

How a CFO should actually model it

If you are evaluating the Help Agent, model it as a meter, on its own terms, and compare it to the other meters, not to the seats.

First, get a real deflection estimate, not the vendor ceiling. Conservative first-year deployments on support agents land at 35% to 45%, not the 60%-plus in the case studies. The crossover mathematics for per-resolution versus flat-fee agents is worked out in the Sierra, Decagon, and Intercom Fin crossover post, and the same method applies here.

Second, compare meter to meter. The Help Agent bills $2 per successful resolution. Intercom Fin bills $0.99 per resolution, less than half, and Fin at least has a flat-fee option around $1,500 a month for volume predictability. If your goal is autonomous ticket deflection at the lowest per-unit cost, the Help Agent is the premium meter in the room, and the fair no-charge-on-handoff wrinkle has to be worth the premium.

Third, credit the meter against labor, not against the Zendesk or Intercom seat line. Intercom seats run $85 in the catalog, Zendesk $115. Neither of those is the number the meter displaces. The meter displaces the cost of a human resolving the ticket, so the comparison is loaded labor cost per ticket versus $2, over your realistic deflection band. If that math clears, the agent is worth it, and the Zendesk seats you keep are a separate, and much smaller, hygiene question.

Fourth, watch the volume like a usage bill, because that is what it is. An outcome meter has no dormant-seat waste, but it has runaway-volume risk. If deflection climbs and volume climbs, the bill climbs with them, and there is no seat cap to hold it. The renewal lever is not "cut us from 450 seats to 320." It is "here is our resolution volume, here is the band we are committing to, here is the overage rate we will accept."

The honest takeaway

The Agentforce Help Agent is a reasonable product with an unusually fair meter. It is also the clearest recent example of why a seat-compression catalog has to know what it cannot model. There is no seat to compress, so we did not pretend there was one. Salesforce's other Agentforce oddity, the $125-per-user agent it sells to compress its own CRM, is the mirror image of this problem, and we took it apart in the Agentforce self-compression post.

If your support stack is a Zendesk or Intercom seat estate, run the seat hygiene on those seats with a model built for seats. If you are weighing an outcome-priced agent on top, model the meter against labor with a model built for volume. Keep the two conversations apart, and neither one will lie to you.