Structuring a CRM for Partnerships

A CRM will happily hold a partner. It will not, out of the box, hold a partnership— because a CRM's entire object model is built around something a partnership isn't: a deal. Deals have a close date. They're binary — won or lost. They move through stages that end. None of that describes what actually happens between you and a partner over eighteen months, and every partner team that's tried to track partnerships as deals has felt the seams: stages that don't map to anything real, a close date nobody believes, and nowhere at all to write down what this partner could become versus what they are today.

So teams improvise. A custom pipeline gets bent out of the deal object. A “Partner?” checkbox gets added to Company. A free-text field holds whatever the last person typed. It mostly works, in the sense that the data exists somewhere — but it isn't a data model. It's a pile of fields nobody agreed on, which is a large part of why partnerships struggles to get taken as seriously internally as sales or marketing: those functions can report a number and have everyone trust it came from somewhere real. Partnerships usually can't, because there is no shared structure underneath the number to trust.

This isn't a HubSpot problem specifically — Salesforce and Pipedrive have the identical gap, for the identical reason: none of them were built with partnerships in mind. HubSpot is the worked example throughout, with real property names, because a model is more convincing with evidence than with a diagram.

Open a fresh HubSpot portal and look for the fields a partner program actually runs on. They aren't there:

None of this is a knock on HubSpot. It's a knock on the assumption that “put it in the CRM” is a complete answer. It's the right container. It needs a model poured into it.

The instinct is to add a single-line text field and let people type “Reseller” or “reseller” or “VAR” — and within a quarter you have four spellings of the same category and a report that can't group by any of them. A real partner-type field is a closed enum, because the whole point is being able to ask “how are our ISV partners performing against our resellers” and get a real answer.

A reasonably complete set, for reference — this is the exact taxonomy RevRadius seeds when it creates the field, but the categories themselves apply regardless of what creates them: ISV / Tech Partner, Cloud Provider / Hyperscaler, GSI (Global Systems Integrator), Regional / Boutique SI, Reseller / VAR, Distributor, MSP (Managed Service Provider), Agency (Marketing / Creative), Referral / Affiliate, Marketplace, Government Reseller / GSA Holder, OEM Partner, Community / Influencer / Analyst.

This is the fix for the seam every improvised setup eventually hits. A partnership needs its own stage field, separate from any deal, because the questions it answers are different questions: not “will this close,” but “where is this relationship right now.”

Notice what this buys you that Deal Stage never could: a partner can sit at Identified for months with nothing wrong — that's not a stalled deal, it's an accurate description of a relationship that hasn't started yet. And Ended is a real, first-class stage, not a lost deal getting archived out of sight. Partnerships that end are still worth being able to find later.

This is the field most setups skip entirely, and it's the one that quietly breaks reporting the fastest, because two partnerships that look identical on paper can be structurally opposite.

The test that actually separates these, when it's not obvious: does title to the product pass through the partner at any point? If yes, it's upstream or downstream depending on which direction it flows. If no — if you just happen to serve the same customers — it's lateral. That single distinction changes what “success” even means for the relationship: an upstream partner's value shows up in what you're able to build; a downstream partner's value shows up in revenue they generate; a lateral partner's value shows up in reach you wouldn't otherwise have.

Custom fields are useful and they should stay flexible — but flexible is the opposite of comparable. If revenue attribution to a partner lives in a field one company invented for their own workflow, it can't be compared to anything, including their own past numbers if the field ever changes shape.

Partner-sourced and partner-influenced revenue don't have that problem. They mean the same thing everywhere: sourced is business the partner directly brought in; influenced is business they touched without originating it. Both are countable the same way regardless of what industry you're in or how your team likes to work — which is exactly the property a number needs to be worth reporting on.

That's a real design line worth drawing explicitly, not just for RevRadius but for any system touching this data: a custom field should never be the kind of thing that moves a score or a report, because a score that shifts based on a field only one customer thought to create isn't comparable to anything. Partner-sourced and partner-influenced revenue earn standard-field status precisely because they're the rare partnership metric that's comparable across every company's CRM, not just one team's private workflow.

What a partner is worth today and what they could become are different questions, and collapsing them into a single number throws away the answer to the more useful one.

A CRM captures a snapshot — where things stand right now. A partnership has an arc — a distance between where it is and where it's realistically headed, and that distance is often the entire reason a partner is worth investing in. A partner scoring low today but with real, articulable upside (an untapped audience, an integration half-built, a relationship barely six weeks old) is a fundamentally different management problem than a partner scoring low with no upside at all. One is where you send your best account manager next quarter. The other is where you stop spending time.

Structurally, this means: whatever field or system holds a partner's “score,” it needs a second field sitting next to it — call it potential, call it ceiling, call it anything — representing the realistic best case rather than the current state. Two numbers, both real, both trackable over time, with the gap between them telling you something neither number tells you alone. That gap — not either number by itself — is usually the actual answer to “where should we be spending time.”

One honest gap before moving on: none of this says where the numbers themselves come from. The fields are free — a picklist and a number field cost nothing to add. Calibrating what a 3 actually means for Reach at your company, and doing it consistently across a roster instead of remembering your reasoning for each partner separately, is the real work, and it's a different problem than the one this piece covers.

That's the model itself — what fields need to exist and what they mean. The remaining question is who's allowed to fill them in, and how much of the CRM they're allowed to touch while doing it.

Once a system starts writing scores or suggestions back into a CRM instead of just reading from it, a new question shows up that pure reporting never had to answer: which fields does it own, and which does it just borrow? Get that boundary wrong and you either overwrite something a partner manager was actively editing, or you never write anything useful at all out of excess caution.

The honest answer needs three tiers, not one blanket policy.

1. Fields the system creates and fully owns

These live in their own clearly-labeled group, and overwriting them on every update is correct — a stale score is worse than no score, and nobody's manually maintaining a field they never asked for. RevRadius's version: a revradius property group holding revradius_score, revradius_potential_score, revradius_competitive_risk, and revradius_last_scored. Every push overwrites all four.

2. Fields it fills in for you — but only if you don't already have them

Setup asks rather than assumes. It shows you every dropdown property in your portal and asks which one holds partner type, and which holds partnership stage — whatever you happen to call them, “Partner Category”, “Channel Type”. Pick yours and RevRadius reads it and leaves it alone. A second picklist beside the one your team already uses is two vocabularies disagreeing, and the more mature your programme, the likelier that is.

If you genuinely have neither, one click creates partner_type and partner_stage with a real taxonomy already in place — and then keeps them current, because a field it created, filled with its own vocabulary, and never written to again would sit empty forever. That's worse than never creating it. These are unprefixed and yours to edit, grouped under “Partner Attribution” so they're easy to find. And if you'd rather own one outright, you can tell it to read that field from you instead of writing to it.

3. Everything else

Untouched, full stop, unless the customer explicitly maps a specific field and points it outward themselves.

That three-tier split isn't a RevRadius-specific quirk worth copying verbatim — it's the shape any honest write-back integration needs, whatever system is doing the writing. The specifics (which fields, which group) will differ. The principle — full ownership only over what you created, seeded fields kept current but handed back on request, and silence on everything else — is the part worth taking regardless of what tool ends up implementing it.

None of this requires buying anything. A partner-type enum, a real partnership-stage field separate from Deal Stage, a direction field, standard partner-sourced/influenced revenue fields, and a second number for potential next to whatever “score” you're already tracking — all of that is buildable by hand in an afternoon, in HubSpot, Salesforce, or Pipedrive alike. The model is the point, not the tool.

What changes once it exists: a partnership stops being a thing your CRM grudgingly accommodates by way of a bent deal pipeline, and becomes something it was actually built to hold — because now it has the fields a partnership genuinely needs, not the fields a deal happened to already have lying around.

The calibration question — where the actual numbers come from — is what the RADIUS framework answers: consistent instruments per dimension, current and potential scored separately, run across a whole roster rather than remembered per partner. This is a real partner scored in RevRadius, calibrated against exactly the fields this piece describes:

See also: Choosing which vendors and platforms to bet on and The 100-Partner Problem.