32% to 80%: what actually happens when you fix a broken partner ecosystem
I inherited a partner program with 5,000 partners and almost no engagement. Here’s what was actually wrong, and what it took to fix it.
A few years ago I took over global revenue operations for a large enterprise software company. The company was in the middle of a major strategic shift - migrating its customer base from on-premises software to SaaS. The channel partner ecosystem was supposed to be the engine that drove that migration.
It wasn’t.
On paper, the partner program looked fine. Thousands of partners across multiple geographies. A portal. Training materials. Certification tracks. Deal registration. The slide deck for the board showed a growing ecosystem. The reality was that partner engagement sat at 32%. Two thirds of the partner base was effectively dormant. They’d signed up, maybe logged in once, and then disappeared.
The company was spending money on a partner program that most partners weren’t using, selling a migration that most partners weren’t equipped to deliver, and reporting on ecosystem growth that wasn’t real.
I had a team of 15 spread across multiple time zones and a mandate to fix it.
The first thing I did was stop looking at the technology
Everyone wanted to talk about the PRM platform. The existing one was clunky, the UX was poor, partners complained about it. The obvious move - the one people kept pushing for - was to rip it out and replace it.
I didn’t start there.
I started by talking to partners. Not surveying them. Talking to them. What I found wasn’t a technology problem. It was a series of connected operational failures that no platform could fix on its own.
Partners didn’t understand the SaaS migration story well enough to sell it. The enablement materials were built for the internal sales team, not for external partners who had different customers, different objections, and different sales motions. Partners were being asked to sell something they’d never been trained to position.
Deal registration was a black hole. Partners would register a deal and hear nothing for weeks. When they did hear back, they’d often discover that a direct sales rep was already working the same account. There was no clear process for resolving conflicts, and no trust that the system would protect the partner’s investment of time.
Attribution was a mess. Marketing was running campaigns that overlapped with partner activity, and nobody could separate the two in the CRM. When a deal closed, the question of whether it was partner-sourced or partner-influenced or purely direct was answered by whoever had the loudest voice in the room, not by data.
The CRM wasn’t aligned to the go-to-market motion. Salesforce had been configured for the old world - on-prem, direct sales, single-touch attribution. The data model didn’t reflect the reality of partner-sourced pipeline. Fields were inconsistent. Objects were misused. Reporting was unreliable because the underlying data architecture was unreliable.
None of these were technology problems. They were people, process, and data problems that had been accumulating for years while successive platform decisions papered over them.
What we actually fixed
We did eventually replace the PRM. But that was step four, not step one.
Step one was the data. We rebuilt the CRM architecture to support partner-sourced and partner-influenced pipeline alongside the direct motion. That meant new objects, new fields, clear definitions of what counted as partner-sourced versus partner-influenced versus direct. We standardised the data model across regions so that a deal registered in EMEA looked the same as one registered in North America. Without this, nothing else would have worked.
Step two was the process. We redesigned deal registration to guarantee response times. We built conflict resolution rules that were documented and enforced, not negotiated deal by deal. We created a single pipeline management process that applied to both direct and partner-sourced opportunities - same stages, same criteria, same reporting. Partners stopped being a separate, lesser pipeline and became part of the revenue operation.
Step three was the people. We rebuilt the enablement program specifically for partners. Not a copy of the internal training. Materials built for how partners actually sell - their customers, their language, their objections. We ran targeted enablement for the SaaS migration story so partners could position it with confidence. We also aligned internal incentives so that direct sales reps weren’t penalised for working with partners on the same account.
Step four was the technology. Once the data model was solid, the processes were defined, and the people were trained and aligned, we implemented a new PRM platform. The platform worked because it was built on a foundation that actually made sense. It wasn’t trying to compensate for broken data or undefined processes. It was accelerating operations that already functioned.
Within two years, partner engagement went from 32% to 80%. We achieved eight consecutive quarters of revenue growth. The ecosystem stopped being a cost centre that produced slide decks and became an operational channel that produced attributable revenue.
What I actually learned
The obvious takeaway is that the fix worked. But the thing I keep coming back to isn’t the result. It’s the pattern.
Every organisation I’ve worked in or consulted for since has had some version of the same problem. The technology gets bought first. The process gets retrofitted to match the tool. The data gets forced into a structure that doesn’t reflect reality. The people are the last thing anyone thinks about. And then everyone wonders why the system doesn’t deliver.
People. Process. Data. Technology. In that order. It’s not complicated. But it is hard, because it means doing the slow, unglamorous work before you get to the exciting platform implementation. It means fixing the CRM data model before you buy the PRM. It means defining deal registration rules before you automate them. It means training partners on how to sell the thing before you measure whether they’re selling it.
Most companies skip to the technology because it feels like progress. It looks good in the quarterly update. A new platform is a deliverable. Fixing your data architecture is invisible until it starts working.
The companies that get ecosystem operations right are the ones willing to do the invisible work first. That’s what this publication is about.
If you’ve read the first two articles - the Start Here and What Is Ecosystem Orchestration - you already know the thesis.
This is what it looks like when you apply it to a real programme in a real company with real constraints.
The numbers are nice. But the lesson is the sequence.