The 100-Partner Problem

Almost nobody builds a partner program from nothing. You inherit one. A list in the CRM somebody started two years ago, a pile of signed NDAs, three portal logins nobody has the password to, and a partner everyone describes as strategically important with no activity attached to it.

Then the opinions arrive. The CEO met someone impressive at a conference. Sales wants the partner who owns one specific account. Professional services is worried about giving away work. Marketing wants a co-marketing partner with an audience. Each of them is right about something, and none of them is looking at the whole board.

The problem is not that you lack information. It is that you have no consistent way to compare a regional reseller against a marketplace listing against a global systems integrator, so the loudest argument wins by default. That is what makes partnerships feel soft to a finance team: not the absence of revenue, but the absence of a method.

The obvious move is to sort by revenue the partner has sourced. It is defensible, it is already in the CRM, and it is wrong in a specific way.

Sourced revenue is a lagging indicator. Ranking by it guarantees you keep funding what already worked and systematically underfund what is about to. It cannot distinguish a partner that has peaked from one that has barely started, because both look identical from behind.

There is a pattern that shows up repeatedly. A company had never counted which of its integrations were actually live in the customer base. When somebody finally pulled the numbers, one partner had several hundred active integrations, far ahead of everyone else, and it was not the partner leadership had been championing for the previous six months. The evidence had been sitting in the product data the whole time. Nobody had thought to read it as a partnership metric.

Scoring is how you find that before somebody stumbles on it.

Score every partner on six things. The dimensions are universal. The instruments you measure them with are specific to the partner type, which is why each one below lists both.

N/A is an answer, not a zero. A pure referral or affiliate partner has no Implementation. They are not in the implementation business. A marketplace has no Discovery; it is a demand signal, not a relationship with someone who knows your accounts. Scoring those as zero penalises a partner for being the type it is, and quietly ranks entire categories last for no reason. Mark them N/A and exclude them from the average.

Scores are absolute, not relative. A 3 on Reach means the same thing regardless of which partners happen to be in the set. This is what lets you compare across cohorts and, more importantly, across time. A relative ranking tells you the order today. An absolute score tells you whether anything actually improved since last quarter.

This is the step most scorecards skip, and it is the one that turns a report into a plan.

Score each dimension twice. Once for what is demonstrated today. Once for the realistic ceiling if the relationship were properly worked, based on what the partner structurally already has: their field organisation, their delivery capability, their accounts.

For established partnerships, weight demonstrated history more heavily. For new ones, structural potential is your primary signal. A partner with 500 trained field reps embedded in your target vertical is not a 1 on Discovery because you have not run a joint call yet. They are a 4 or 5 on structural potential. Score it and note the basis.

The distance between the two scores is the useful number. It tells you which partners are underperforming their own ceiling, which is a completely different problem from being a bad partner. One needs activation. The other needs removing from the list.

Read the four shapes on the activation gap for what each combination is telling you to do.

The one that looks impressive. Some opportunities offer value beyond what a 1 to 5 scale captures: a platform-level integration reaching millions, an endorsement that moves a market. These are real, and they are also the fastest way to consume your engineering and executive attention for a year with nothing to show. Score the partner at its realistic activation potential and record the upside separately, with the resource cost and the time to first validation written next to it. Your job is not only to see the big opportunity. It is to hold the frame when everyone internally wants to chase it.

The one actively costing you. A 1 means the partner contributes nothing. Some partners are worse than nothing: implementing badly so the customer blames your product, introducing you with a caveat, holding market standing that is negative, running integrations that are live but broken and generating support burden you own. The scale floors at 1, so flag these separately. Absence of value and active harm are different problems and they need different responses: remediate, contain, or exit.

The first pass is simple to describe. Take your list. For each partner, score six dimensions twice, on a 1 to 5 scale, marking N/A where a dimension genuinely does not apply. Write one line of reasoning per score. That is 12 numbers and six sentences per partner, and it goes faster than it sounds once the criteria are fixed, because most of the argument happens once rather than per partner.

Two things to do before you start. Define what each dimension means for your business, because Reach for a self-serve product is not Reach for an enterprise sales cycle. And be honest about what you are measuring against: you cannot score a partner's fit with your ICP without having written the ICP down somewhere your CRO would agree with.

Consistency beats precision on the first pass. A rough score applied evenly across the whole ecosystem is far more useful than a careful score applied to the six partners somebody happened to think about.

Where this breaks down is the second pass, and the tenth. A ranking built from memory goes stale the moment a partner's integration count changes or a champion moves jobs, and nobody re-scores 80 partners by hand on a schedule. The method needs to run on live data to stay honest: real usage pulled from your own systems instead of a guess, and candidate partners surfaced from actual market overlap instead of whoever came up in a meeting. That is a search problem too, not just a scoring one; an AI pass that reasons over your real profile can put named, verifiable companies in front of you that nobody on the team would have thought to check, and it will say so plainly when a candidate does not clear the bar for a real, known company rather than invent one to fill the list.

Three things, in order of how much they change your week.

A ranked list you can defend, where the answer to why a partner sits where it does is the same criteria applied to every other partner rather than a story.

A set of partners whose potential sits far above their current contribution. That is your activation work, and it is usually where the fastest return is hiding, because the capability already exists and simply is not switched on.

An audit of what you do not measure. The first time you try to score Utilization and realise you have no way to tell which integrations are actually used, that is the finding. Most companies can say how many partners they have. Very few can say how many of their top expansion accounts a given partner is already deployed in. The data usually exists. Nobody organised it into a view that answers a partnership question.

This guide covers scoring the ecosystem that carries your product to your buyers. The same six dimensions work when the question runs the other way, when you are a reseller, MSP, or agency deciding which vendors and platforms to bet the business on. The letters stay. The questions rotate. That guide is next.

RevRadius implements this method, including the parts that are tedious by hand: scoring at consistent criteria across a large roster, tracking how scores move over time, and pulling real usage data in rather than estimating it. The RADIUS framework page has the detail, and integrations covers where the data comes from.