Sold through someone else
A B2B2B software company sells to a partner, and the partner then has to sell to its own business customers. That puts 2 sales cycles, an onboarding project and a revenue share between the product and the revenue. The model can reach further than a direct team ever could, but a plan that counts signed partners as if they were selling will overstate it.
Consider a plan built on 40 signed partners, each with thousands of business customers of its own, and a penetration rate applied to the total. The arithmetic is simple and the number is large.
What the plan cannot show is how many of those partners have sold anything yet. In a B2B2B model, where the company sells to a bank, a telco, a distributor or a platform that resells to its own business customers, a signed partner is the start of the work, not the end of it.
Why the channel is worth the trouble
The reach is real. Canalys estimated that partner-delivered IT would account for 70% of worldwide IT spending in 2025, out of a total it put at 5.44 trillion dollars. Most business technology is already bought through someone other than its maker, and a partner that owns the customer relationship, the invoice and the trust can put a product in front of accounts a direct team would take years to reach.
Cloud marketplaces are the newest version of the same argument. Canalys forecast that software sold through the AWS, Microsoft and Google Cloud marketplaces would grow from 16 billion dollars in 2023 to 85 billion dollars by 2028, and expects more than half of marketplace sales to flow through channel partners by 2027. Those are forecasts rather than results, but the direction is not in dispute.
Where the model slows down
Two sales cycles, in series. The company first sells the partnership, which at a bank or a telco means procurement, a security review, legal and a commercial sponsor inside the partner. Then the partner has to sell to its own customers, and no recurring revenue appears until it does. The gap between a partner’s signature and its first paying customer is measured in quarters, and it is rarely in the plan.
Readiness, on both sides. The partner needs sellers who are trained, a product they can explain without calling the vendor, and a reason to bring it up ahead of everything else in the catalog. Those sellers are paid on what they already know how to sell. The vendor needs its own readiness too: onboarding material, partner managers, a demo environment, a certification path. A company that signs partners faster than it can onboard them is building a backlog, not a channel.
The operational questions nobody settled. Who answers the end customer’s support ticket, and who owns the escalation when the partner cannot. Who bills, in which currency, and how the revenue share is calculated, reconciled and paid. Who trains the partner’s new sellers when the first group moves on. Whose system records usage, and whether the vendor can see its own end customers at all. Each of these is a contract clause, and each one left open surfaces later as a slower cycle or a thinner margin.
Concentration. Partner revenue tends to sit with a few partners while the rest of the list stays signed and quiet. That is normal. It becomes a risk when one partner carries the plan, because a change in that partner’s priorities, ownership or catalog moves the vendor’s revenue without the vendor doing anything.
One listing among many. AWS describes its own marketplace as carrying thousands of software listings, and a large partner’s catalog works the same way. Being listed is not being sold. The product competes for attention with every other vendor the partner carries, and the partner has no reason to prefer it unless the economics or end-customer demand gives it one. A vendor that depends on a platform it does not control can also find the fee, the terms or the placement changed without its agreement.
What to establish
Revenue by partner, by quarter since signing, so that the time from signature to first revenue is visible rather than assumed. The split of the partner list into signed, onboarded, selling and renewing, because a single partner count hides all 4.
The partner economics, line by line: the revenue share, who carries support and billing, and what the vendor keeps after both.
Whether end customers renew through the partner, and whether the vendor could reach them if the partner left.
And the view from the partners themselves. A conversation with a partner’s sales lead answers what no dashboard does: whether their sellers bring the product up unprompted, and what would make them do it.
Why this is 100-day work
Because a channel that is signed but not selling is fixable, and the fixes are operational. An onboarding sequence. Clear ownership of support, billing and reconciliation. Enablement concentrated on the partners closest to selling, and a decision about which partners to stop investing in. None of it completes in a quarter, and all of it drifts without a plan agreed at close and someone reviewing it against partner revenue rather than partner count.
More insights
The tender was written for someone
In B2B software the best product does not always win the deal. Most buyers have a favorite before they speak to any vendor, requirement documents tend to describe the product the authors already know, and in many markets relationships and local presence count as much as features. For a buyer of a SaaS company, that changes how a pipeline and a win rate should be read.
Nobody can state the ROI, so nobody can defend the price
A company that cannot express what its product is worth in the customer's own numbers will discount under pressure, lose renewals it should win, and never raise prices. This is one of the most tractable problems in the first 100 days after an acquisition.
Last updated