Why we don't price PartnerSignals per seat

Per-seat pricing answers a question nobody in revenue is actually asking.

A seat license asks, "how many people will log in?" But nobody buys partner-revenue intelligence to give their team another tab to open. They buy it to make a number they're accountable for — partner-influenced pipeline — forecastable enough to defend. The unit that matters isn't a login. It's the outcome.

So the pricing question we care about isn't "how many seats." It's "what is this worth when it works." Those produce very different numbers, and they come out of very different budgets.

Two budgets, an order of magnitude apart

Software gets bought out of the software budget. It's a real budget, and it's a small one — tooling line items, per-seat licenses, the stuff that gets cut first in a tight quarter.

The work those tools are meant to replace gets paid for out of a much larger budget: labor. When an enterprise quantifies the shift from selling tool access to selling completed work, the gap is roughly an order of magnitude — PitchBook frames the move from per-seat licensing (on the order of a thousand-odd dollars per seat per year) to per-outcome pricing (on the order of ten thousand per automated workflow) as an 8× revenue shift, precisely because outcome pricing lets a software purchase draw against the payroll budget instead of the tooling budget.

That's the structural reason the whole category is moving. It isn't a billing gimmick. It's a recognition that the value of completed work is anchored to the cost of the labor it replaces, not the cost of the software that does it. Pricing per seat permanently caps the conversation at the smaller of the two budgets.

This is what people mean by Service-as-Software: you're not renting access to a tool and hoping your team extracts value from it. You're buying a delivered outcome, priced like the work it stands in for.

Per seat is the wrong question for this category

There's a more specific reason per-seat is wrong for partner-revenue intelligence in particular.

The signal/revenue-intelligence tools a CRO already owns are almost uniformly seat-priced — and almost none of them tie price to whether the forecast actually got more accurate. You pay for access whether or not the number improved. That's the model partner-influenced revenue does not need another instance of. The point of converging partner-ecosystem signal into the CRM is forecast accuracy. If that's the value, then the price should follow the value — not the headcount with a login.

Per-seat also creates exactly the wrong incentive. A seat vendor wins by adding seats. A category that wins by making your forecast defensible should be paid when the forecast gets defensible — not when your user count goes up.

The trap on the other side

Here's where most "outcome pricing" pieces stop, having sold you pure usage-based billing as the obvious answer. It isn't, and the honest version of this argument has to say why.

Pure outcome pricing has a well-documented failure mode. When a vendor charges per discrete outcome and the volume climbs, the bill can climb past what seat-based pricing would ever have cost — the vendor's success becomes the buyer's budget crisis. The most-cited case is a customer-service vendor that launched per-resolution pricing and, at volume, ran roughly 5× the equivalent seat model. Worse, buyers couldn't independently verify the resolutions they were being charged for. Cost shock plus a trust gap is how outcome pricing earns a bad name.

That second part — verification — is the real lesson. An outcome you can't audit isn't a fair price; it's an invoice you have to take on faith. Any serious move to outcome pricing has to solve "can the buyer see, and trust, what they're paying for" before it solves anything else. The market has mostly concluded the same thing: the center of gravity is shifting to hybrid models — a predictable base plus a performance component tied to proven results — rather than pure pay-per-outcome, precisely to avoid the cost-inversion shock while still aligning price with value.

What a credible model has to satisfy

So we don't price per seat, and we don't price on unverifiable outcomes either. The design constraints we hold ourselves to are simpler to state than to build:

• Anchor to value, not headcount — the price should track partner-influenced revenue made forecastable, not the number of people with a login.
• No cost-inversion surprise — success shouldn't produce a punitive bill; predictability has to be part of the structure, not an afterthought.
• A glass box, not a black box — you should be able to see and verify what you're being charged against. An outcome you can't audit is not an outcome you should pay for.

The specific mechanics — how the base and the performance components are structured, what the unit of proven outcome is, how it's metered — are the part we're being deliberate about, and they're not what this post is for. (We're finalizing them, and we'd rather get them right than publish a number we'd have to retract.) The model, though, we're clear on: priced to value, predictable, and verifiable.

The question to sit with

If you're evaluating anything in the partner-revenue or signal-intelligence space, it's worth asking the vendor a direct question: what changes about my bill if this works — and can I verify it?

A per-seat answer means the price never connected to the value in the first place. A pure pay-per-outcome answer with no verification story means you're being asked to trust the meter. The model worth paying for is the one that can answer both — priced to the outcome, and built so you can see it.

That's the standard we're holding ourselves to. We don't price per seat because partner revenue made forecastable isn't a seat. It's the outcome.

PartnerSignals brings partner-ecosystem signal into your CRM to increase forecast accuracy. Our five-minute diagnostic maps where your partner-influenced forecast is least defensible today: scorecard.partnersignals.ai/diagnostic.