The CRO of a growth-stage SaaS business tells the board they have a partner programme. He shows the slide. Twelve named partners. Two announced press releases. A signed MOU with a global system integrator. The board nods. Next slide.
What he does not tell them, because he does not yet see it himself, is that he has four different businesses sitting inside one slide.
The reseller is moving the product through their own buying-centre relationships, billing on commission, owned by channel sales, reporting partner-sourced ARR.
The system integrator is owning the implementation layer, billing services, owned by partner success, reporting time-to-value and attach rate.
The ISV is layering adjacent capability (increasingly AI), splitting joint revenue, owned by product and alliances, reporting joint-customer ARR.
The instrument or platform vendor is bundling the SaaS into hardware deals, attaching to the vendor’s own quote, owned by strategic alliances, reporting bundled-deal ACV.
Different economics. Different enablement. Different deal cycles. Different reporting lines. Different KPIs. Different problem when something breaks.
The slide makes them look the same. The comp plan often treats them the same. The enablement deck definitely treats them the same. And the programme reports up to the board as one number.
That is the conflation.
The conflation is what kills partner revenue. It is not the rev share. It is not the deal-registration system. It is not the lack of MDF budget. Those are real but they are downstream. The structural cause of why most partner programmes plateau is that the four archetypes are operated inside one pattern that fits exactly none of them properly.
When a reseller is enabled like a system integrator, you get demo certifications they will never use and methodology training they do not need. When an ISV is enabled like a reseller, you get sales playbooks instead of joint roadmap commitments. When a global instrument vendor is paid like a regional reseller, the strategic alliance withers and the vendor disengages within two quarters.
Building four programmes is hard. Pretending you have one, and operating it badly across four shapes, is harder. It is what most companies actually do.
There is a simpler discipline. Run the four as four. Each archetype gets its own owner inside the SaaS business, its own enablement track, its own economics, and its own headline KPI that proves the motion is working or not. The reporting to the board can be aggregated. The operating model underneath must be distinct.
The second discipline is harder. Pick two, not four. In a growth-stage SaaS business the right answer is almost never all four at once. It is usually the two archetypes most likely to compound for the specific business, built properly, before the other two are added.
Selection criteria are simple. Where is the gating risk to growth? If you cannot reach the buyer, the reseller relieves it. If implementation is the bottleneck, the integrator relieves it. If your platform’s value compounds with adjacent capability (almost always AI now), the ISV relieves it. If the workflow you sit inside is already buying hardware, the instrument vendor relieves it.
Pick the two that match the gating risk. Build them properly. Add the other two when the first two are operating.
Most partner programmes are scaled too wide before they are scaled at all. The fix is not more programme. The fix is fewer programmes, run distinctly, until the operating model can hold a third.
When the board asks the CRO next quarter, the slide should not say “we have a partner programme.” It should say “we are running these two, and here is how they are reporting separately.”
That is the difference between a partner narrative and a partner business.
For a worked example of the four archetypes mapped against an operating model, with the economics, enablement, deal cycle, owner, and KPI per archetype, explore the interactive Partner Architecture Visualiser.