Partner lead sharing that does not leak or stall
What to share with a technology partner, how to handle consent, how to route leads, how to keep speed-to-lead real, and how to close the feedback loop so the partner keeps sending.
A partner says they will send you leads. You say you will send them leads. Both of you mean it. Then a spreadsheet arrives with 40 names, no context, and at least two people who never agreed to be contacted. Your team works half of them, slowly. Nobody reports back. The partner concludes you dropped the ball. You conclude their leads are junk. Lead sharing dies of that pattern more often than it dies of a bad commercial model.
Lead sharing is a process, not a gesture: what data moves, on what legal basis, to whom, how fast, and what the sender hears afterward. This post covers those five. It is the inbound twin of co-sell attribution, and it sits next to sourcing technology partners and partner ICP. If the partner does not see the same buyer you do, no routing trick will save the leads.
The 60-second version
If you only read one section, read this one:
- Share fewer, better leads. A named account, a person, a reason, and permission beats a CSV of logos.
- Consent is not optional. If you cannot say why this person can be contacted, do not pass the record.
- Route to a person, not an alias. Named AE or partner owner, in the CRM, the same day.
- Speed-to-lead is the product. First human touch in one business day, or the partner will stop sending.
- Close the loop every time. Accepted, rejected, meeting set, closed-won, closed-lost. Silence is how sharing ends.
- Use the same fields both ways. If you cannot take a lead in a format, do not send one in that format.
- Write what you will never share. Customer usage data, open opps on contested accounts, and anything not needed to make the first call.
What to share (and what to keep)
The unit of a useful partner lead is a person at an account, a reason they are relevant, and enough context for a first conversation that is not cold. Anything less is a list. Lists feel like volume and convert like spam.
Minimum payload:
- Account (legal name, domain)
- Contact (name, role, email or phone)
- Source partner and their owner
- Trigger (what happened: they asked, they use both products, they raised a gap)
- Consent note (how you are allowed to pass this)
- Suggested motion (referral they sourced, co-sell assist, or inbound they asked to meet you)
That is enough. Extra fields (employee count, tech stack, contract dates) help when they are accurate and hurt when they are guessed. Do not require them on the first pass.
What you should not share by default:
- Full customer lists "so they can map accounts." Account mapping is a joint exercise on agreed named accounts, not a dump. See the co-sell side of the co-selling engine.
- Product usage, ticket history, or billing status on a customer, unless the customer is in an active joint deal and both contracts allow it.
- Open opportunities on accounts the other side might compete on. That is how you leak your pipeline into a conflict.
- Contacts who never agreed to a referral. A name in your CRM is not a lead you are free to pass.
Harvard Business Review's B2B elements of value is a useful filter here: the receiving seller needs reduced effort and reduced risk, not more data. A short, permitted, contextual lead is more valuable than a wide file.
| Payload | Share? | Why |
|---|---|---|
| Named contact + trigger + consent | Yes | This is a workable lead |
| Account only, no contact | Rarely | It is a hint, not a lead |
| Customer usage or tickets | No, unless a live joint deal allows it | Leak and contract risk |
| Full CRM export "for mapping" | No | That is a data dump, not sharing |
| Open opp on a contested account | No | You just handed over your pipeline |
| Contact who asked to meet the partner | Yes | This is the cleanest lead you will get |
If you run a channel partner or reseller motion, the partner may need more once they own the customer (provisioning data, support contacts). That is customer-of-the-partner data, under their contract, not a lead-sharing problem. Do not confuse the two.
Consent, then routing
Passing a person's details to another company is a data event. Treat it like one. You do not need a legal essay in this post, and this is not legal advice, but you do need a working rule: if you cannot explain the basis on which this contact can hear from the receiving company, do not send the record.
Practical patterns that stay clean:
- The contact asked. "Can you introduce me to them?" is the gold standard. Write it down.
- The contact is already a customer of both, and both contracts allow a joint outreach on the shared workflow. Still tell them you are connecting the two teams.
- The partner is the one making the intro, in their own name, to their own customer, and you join on request. You never received a cold list.
Patterns that leak:
- Buying or swapping lists between partner CRMs.
- "They downloaded a whitepaper on our site, you can call them." That consent was not for you.
- Adding the partner to a thread the customer did not expect, with a full history attached.
Put a one-line consent field on the lead object. "Customer requested intro, 12 May, email attached" is enough. Empty consent field means the lead does not route.
Routing is next, and it should be boring. One owner, in the CRM, based on territory or named account, not based on who is free in Slack.
- Inbound from partner, you sell: route to the AE who owns the account, or to a partner-sourced queue if you have one. Create the lead or contact, tag
Partner source, and fire the same SLA you use for other inbound. - Outbound to partner, they sell: send to their named partner owner, not to "partnerships@." Ask them to confirm receipt.
- Joint co-sell: create the opportunity, tag both owners, and schedule the first joint step. This is a deal, not a lead; treat it under co-sell attribution so credit is tagged before anyone argues.
A strategic alliance announcement with no named routers is how leads land in a shared inbox and die. Name the humans in partner onboarding, and keep those names current.
Speed-to-lead, then the feedback loop
Partners stop sending when their last three leads went into a hole. Speed is how you prove the hole does not exist.
Publish a speed-to-lead SLA and keep it:
- Acknowledge receipt the same business day.
- First human touch (email, call, or meeting booked) within one business day of an accepted lead.
- Disposition in the CRM within five business days: working, meeting set, disqualified, or passed back.
One business day is the number most partner sellers will believe. Longer, and they will send the next name to a vendor who answers. Faster is better on hot, customer-requested intros; those should be same-day.
The feedback loop is the second half of the product. Every shared lead should return one of a small set of statuses to the sending partner:
| Status back to partner | What it means | When to send it |
|---|---|---|
| Accepted, owner named | We will work it | Same day |
| Rejected, reason | Duplicate, no consent, out of ICP | Same day |
| Meeting set | First conversation booked | When it is booked |
| Working | In conversation, not yet opp | At five days if still true |
| Closed-won | Paid, thank you | At close, with the tag they need to get paid |
| Closed-lost / disqualified | Why, in one line | When you know, not a quarter later |
Do this in the CRM if you can (a partner community, a shared report, a weekly export). Do it in a Friday email if you cannot. The channel matters less than the habit. A partner who sees "12 sent, 9 accepted, 4 meetings, 1 won" will send the 13th. A partner who sees nothing will not.
This loop is also how you improve quality without a fight. If 8 of 12 were out of ICP, that is a partner ICP conversation, held with numbers, at the partner QBR. If 8 of 12 were accepted and then went cold on your side, that is your speed problem, and you should say so first.
Track three numbers on partnership metrics: leads received, time to first touch, and conversion to opportunity. Volume without the other two is a vanity count.
Operating rules that keep sharing alive
Write a one-page lead-sharing addendum and use it in both directions: ICP recap (one paragraph each), payload and consent field, named routers with a backup, SLAs, feedback cadence, prohibited data (usage, tickets, full lists, contested open opps), and what happens on a bad lead (reject with a reason; do not ghost).
Run the same page for leads you send them. If you demand a contact, a trigger, consent, and a one-day first touch, send that and hit one day. When the partnership is new, start with customer-requested intros only for 60 days. Open the pipe to partner-sourced names once the SLA holds. Opening wide on day one is how both sides drown and blame the other.
Common mistakes, and the fix
Swapping CSVs and calling it a program. The fix: named contacts, triggers, consent, and a router. A list is not a lead.
Skipping consent because "they're a partner." The fix: a partner relationship does not grant you the right to pass a person's details. Empty consent field, no route.
Routing to a shared alias. The fix: a named owner in the CRM the same day. Aliases are where leads stall.
No status back for weeks. The fix: six statuses, same-day or five-day clocks, even if the status is "still working." Silence ends the pipe.
Sharing open pipeline on accounts you might both sell. The fix: joint deals go through deal registration. Everything else stays in your CRM.
FAQ
Is a lead the same as a registered deal? No. A lead is a name plus context you can work. A registered deal is an opportunity accepted as sourced or influenced, with protection. Promote a lead when there is a real opportunity, not when the email arrives.
Who owns GDPR or similar questions? You both do, for the data you each hold. This article is not legal advice. Get counsel to write the basis you will actually use, put a consent field on the object, and do not pass records you cannot explain.
Should we score partner leads? Only after you have volume. At the start, accept or reject against ICP and consent. A score nobody trusts is extra process.
What if their leads are consistently out of ICP? Show the numbers at the QBR, rewrite the ICP paragraph, and pause the pipe until a sample meets the bar. Do not keep working junk to be polite.
Can marketing automation pass leads between us? Yes, if consent, fields, and routing match the manual process. Automation without those three just leaks faster.
How do we handle a lead that both of us already had? Tag it influenced if the partner is joining a live deal. Do not pay sourced economics on a name that was already in both CRMs.
What is a reasonable first-touch SLA? One business day for accepted leads, same day for customer-requested intros. Publish it. A private SLA is not an SLA.
Do we need a partner portal to share leads? No. CRM fields, a named router, and a weekly status mail will carry you until volume hurts.
Further reading
- Channel partners: why lead flow is a designed process in any indirect channel, not a favor.
- The B2B elements of value: share what reduces the receiving seller's effort and risk, not a wider file.
- Strategic alliance: useful context when the "alliance" press release has no named humans to receive a lead.
The short version
Share fewer leads, with a person, a reason, and permission. Route each one to a named owner the same day. Touch it within a business day. Send a status back every time. Never pass usage data, full lists, or contested open pipeline as if they were leads.
Consent is the gate. Speed is the product. Feedback is why the partner sends the next one. Write those three on one page and use the page in both directions.
If you want help designing lead sharing next to deal registration and the rest of the motion, that is exactly what a Partner Audit is for.