The partner agreement is signed on a Thursday. There is a kick-off call the following week, a shared folder of decks, a login to the partner portal, and genuine enthusiasm on both sides. The partner has three people on the call and all of them ask good questions.
Then nothing happens. Not a refusal, not a complaint — just a quarter in which no opportunity is registered, no demo is requested, and the shared folder is opened twice. At the quarterly review someone reports that the channel now has forty signed partners, and somebody else asks how many of them have sold anything. The answer is six.
That gap is not a recruitment problem and it is rarely a commission problem. It is an onboarding problem, and it has a specific shape: a partner is not a customer, not an employee, and not a lead, so the three onboarding programmes you already run all fail on them in different ways. This guide covers what partner onboarding actually is, the three partner types and the different finish line each one has, why signed partners go quiet, the two very different people you are onboarding inside every partner organisation, a ninety-day activation ladder with the four places partners predictably stall, what belongs in the portal versus in the product, and the four numbers that tell you whether your channel is productive or merely populated.
Key Takeaways
- Signing is the start of a countdown, not a result. Partner attention is highest in the two weeks after signature and decays quickly after that.
- Each partner type has a different finish line. Referral ends at an introduction, reseller at a closed deal, implementation at a live customer.
- You are onboarding two people, not one company. The principal needs a business case; the practitioner needs to not look foolish in front of a customer.
- Confidence beats commission. Partners sell the product they are sure they can demo, not the one with the best margin.
- Measure activated partners, not recruited partners. A channel of forty signed and six selling is a channel of six.
What Partner Onboarding Is, and What It Is Not
Partner onboarding, in one paragraph
Partner onboarding is the process of taking a company that has just signed a partner agreement and getting it to the point where it can position, sell and often implement your product without you in the room. The output is not a trained person; it is a first independent outcome — an introduction, a deal or a live customer, depending on the partner type. Everything before that first outcome is cost.
It is worth being precise about how this differs from the onboarding programmes you already have, because each of them contributes something and each of them, used alone, fails.
It is not customer onboarding. A customer learns your product in order to get value from it themselves. A partner learns it in order to earn from it, which means they need a layer that no customer needs: positioning against the alternatives, a demo path they can run unaccompanied, the four objections they will hear, and a clear boundary for what they escalate to you. They also need everything a customer gets, because they will work inside the product, but that is the floor rather than the programme.
It is not employee onboarding. You have no authority over a partner’s calendar and no ability to make anything mandatory. Deadlines that work internally — complete this by Friday — simply produce silence. The lever you have is usefulness at the moment of need, not compliance.
It is not supplier onboarding either, although the two are often run by the same operations team and confused in job descriptions. Bringing a vendor into your procurement process is a compliance and data exercise, described in our guide to supplier onboarding. Partner onboarding is a revenue exercise: the partner is on the selling side of your business, not the buying side, and the risk is not bad data but a quarter of silence.
Three Partner Types, Three Different Finish Lines
Most partner programmes run one onboarding track because the agreement is one document. But the first independent outcome you are aiming at is different for each type, and so is almost everything that leads to it.
| Partner type | What they actually do | First independent outcome | What onboarding must deliver |
|---|---|---|---|
| Referral / affiliate | Spots the problem in a conversation and introduces you | One qualified introduction | The trigger phrases to listen for, a two-sentence description, a frictionless handover |
| Reseller | Sells, prices and invoices your product alongside others | A deal closed without your team on the call | Positioning, a demo they can run alone, objection handling, deal registration |
| Implementation / service partner | Configures, migrates and trains inside the customer’s account | A customer live and genuinely using the product | The setup sequence, the edge cases, quality standards, escalation limits |
| Embedded / OEM | Ships your capability inside their own product or service | Their release that includes you | Integration scope, support boundaries, what their users are told |
The practical consequence is that a single sixty-slide induction deck serves none of them. A referral partner sat through forty slides about configuration they will never perform; the implementation partner got twelve minutes on the setup that is their entire job. Splitting the track by type is the cheapest improvement available to most programmes, and it usually shortens the material rather than multiplying it.
A quick test. Ask what a newly signed partner of each type should be able to do alone after thirty days. If the answer is the same sentence for all of them, you have one track where you need three.
The Attention Problem: Why Signed Partners Go Quiet
Partners do not go quiet because they changed their mind. They go quiet because your product is one of several things they carry, and nothing in their week depends on yours specifically. A partner signs a handful of vendor agreements a year. Each one arrives with a portal, a deck and an enthusiastic contact. Their attention is finite and it is spent on whatever is currently in front of a customer.
This produces a failure mode that is easy to misread. At the moment an opportunity appears — a customer says something that your product answers — the partner has perhaps forty seconds to decide whether to raise it. They will raise the product they are sure of: the one whose story they can tell in two sentences and whose demo they can run without booking a call with the vendor first. If yours is not that product, it is not mentioned, and you never learn that the opportunity existed.
So the real currency of partner onboarding is confidence at the moment of opportunity, not knowledge in general. That reframes the work considerably. It means a partner who can demo competently after two weeks is worth more than one who completed six hours of training and would still rather not open the product in front of a customer. It also means that decay matters: a partner who was confident in March and has not opened the product since is not a trained partner any more.
You Are Onboarding Two People, Not One Company
Inside almost every partner there are two audiences with different motivations, and a programme that addresses only one of them stalls in a predictable way.
Both failure modes look like an inactive partner from the outside, and they need opposite fixes.
The principal — owner, practice lead, sales director — signed because they believe there is demand. What they need from onboarding is evidence that the bet is paying off: early pipeline, a clear margin picture, and something to point at when they decide which vendor gets a slot in next quarter’s plan. Silence here does not read as neutral. It reads as a bet going cold.
The practitioner — the consultant, the account manager, the engineer — did not choose your product and is measured on their own utilisation. Their fear is narrow and entirely rational: being asked a question in front of a customer and having no answer. Everything that reduces that risk gets used. Everything that does not is skipped, whatever the portal says.
The two failures look identical from your side, which is why they are so often treated with the same remedy. A partner who is quiet because the principal never allocated anyone needs a commercial conversation and evidence of demand. A partner who is quiet because the practitioner is not confident needs a shorter demo path and a place to look things up mid-call. Sending more training material to the first, or a business review to the second, wastes the only attention you have.
The Ninety-Day Partner Activation Ladder
Partner onboarding is easier to run when it is expressed as a ladder of observable states rather than a curriculum. Each rung is something you can verify without asking, and each gap between rungs is a place partners predictably stall.
- Signed — agreement executed, contacts known.
- Equipped — accounts created, portal access used at least once, named people identified.
- Fluent — can describe what you do and who it is for, unaided.
- Demo-ready — has run your demo end to end without your team present.
- Sourcing — has registered a real opportunity.
- Productive — has closed a deal or delivered a live implementation.
1. From signed to equipped: the first two weeks are the whole budget
Attention peaks immediately after signature and falls away fast. Everything that requires effort from you — provisioning accounts, sandbox access, naming the people who will be trained — should happen inside that window, because it will not happen later. If account creation takes you eleven days, you have spent most of the enthusiasm on administration. A practical rule: nothing in the first two weeks should be blocked on a scheduling link.
2. From equipped to fluent: two sentences, not sixty slides
Fluency is the ability to say what you do, who it is for, and when you are the wrong answer. That last part is what makes a partner trust the story enough to use it. Test fluency by asking the practitioner to describe your product to you in their own words, and treat that as the exit criterion instead of a completed course. Where partners will also be teaching your product onwards, the principles in our guide to customer education apply directly to the material you hand them.
3. From fluent to demo-ready: the rung where most programmes stop
This is the single highest-value transition and the most commonly skipped. A partner who has watched you demo has not learned to demo. They need to drive it themselves, at least once, in a populated environment, with someone watching who can tell them it was fine. Give them a demo account that already contains realistic data, a fixed path of five or six steps, and in-product guidance for the path so they can re-run it alone a month later when the memory has faded.
4. From demo-ready to sourcing: give them a first conversation, do not wait for one
The gap between being able to sell and actually selling is opportunity flow, and waiting for it wastes the confidence you just built. Joint activity in this window — a webinar for their client base, a review of their existing accounts for fit, one co-sold conversation — converts capability into a first registered deal. It also gives the principal the early evidence they need to keep allocating people.
5. From sourcing to productive: protect the first delivery
The first deal a partner closes, or the first implementation they lead, sets their belief about whether this is worth repeating. Over-invest there. Sit in on the first implementation, review the configuration before the customer sees it, and make the escalation path obvious. A first delivery that went badly does not produce feedback; it produces a partner who quietly stops offering your product, and you will read that as churn rather than as a delivery you could have saved.
Re-check the ladder quarterly. Rungs are not permanent. A partner who was demo-ready in March and has not opened the product since is not demo-ready now, and the fix is a fifteen-minute refresher rather than a re-recruitment conversation.
What Belongs in the Portal, and What Belongs in the Product
Nearly every programme answers the enablement question by building a portal, and nearly every portal becomes a warehouse. The material is not wrong; it is simply in the wrong relationship to the moment of need. A practitioner preparing for a customer call at 8:40 for a 9:00 meeting does not search a document library. They open the product, and whatever is not visible there does not exist.
A useful division is by when the partner needs the answer.
| Question the partner has | When it arises | Where the answer belongs |
|---|---|---|
| What is our margin, how do I register a deal? | Planning, once a quarter | Portal, one page, dated |
| How do I describe this to a prospect? | Before a call | Portal, plus a one-screen reminder in the demo account |
| What is the demo path again? | Minutes before the call, or mid-call | In the product, as guidance on the demo environment |
| What is the correct setup order for this customer? | During implementation | In the product, as a checklist in the account being configured |
| What changed in the last release? | Whenever they next log in | In the product, as a short announcement on entry |
An in-product checklist gives an implementation partner the setup order where the work actually happens, instead of in a portal document.
The pattern is consistent: anything needed while working belongs in the interface where the work happens, and anything needed while planning belongs in the portal. Vendors who move the first category out of documents and into the product typically see partner questions drop without adding any new material — the same effect described in our guide to contextual help, applied to a different audience.
Portals themselves also benefit from being introduced rather than presented. A partner portal is a website your partner visits perhaps four times a year, which is exactly the profile where a short website walkthrough on first visit pays for itself.
When the Partner Onboards Your Customer
For implementation and reseller partners, an uncomfortable fact sits underneath the whole programme: at some point your partner becomes the onboarding experience for an end customer you have never met. Their sequencing decisions, their training quality and their patience become your product’s first impression, and the customer does not distinguish between you.
This is where partner programmes quietly lose renewals. The partner configured the account competently, trained three people in a two-hour session, and left. Six months later the account has low usage, the three trained people have become one, and nobody at your company saw it happen because the relationship ran through the partner.
Two things reduce the risk, and neither requires taking work back from the partner. The first is a definition of done that is expressed in customer outcomes rather than delivery tasks: not configuration complete but five users active in the second week. The second is in-product guidance that ships with the account regardless of who implements it — a welcome flow, a setup onboarding checklist, contextual help on the screens that matter. That layer is the floor beneath partner quality: however good or thin the training session was, every user who arrives afterwards still gets guided. It is also what protects the account when the one trained champion leaves, which is the single most common way partner-delivered implementations decay.
If your partners implement for larger accounts, the account-and-seats structure described in the enterprise onboarding guide is the right model to hand them, rather than leaving each partner to invent their own.
The Four Numbers That Matter
Channel reporting tends to over-index on recruitment, because recruitment is the part that produces visible activity. These four are harder to move and considerably more honest.
1. Activation rate
The share of signed partners that reached productive — a closed deal or a delivered implementation — within ninety days. This is the number that tells you whether you have a channel or a list. Forty partners with a fifteen per cent activation rate is a six-partner channel with thirty-four relationships to maintain.
2. Time to first partner outcome
Days from signature to the first independent outcome for that partner type. It is the channel equivalent of time to value, and it behaves the same way: the longer it stretches, the lower the eventual probability, because attention decays while you wait.
3. Ladder distribution
How many partners currently sit on each rung. A cohort piled at equipped is a provisioning and fluency problem; a pile at demo-ready with nothing at sourcing is an opportunity-flow problem and needs joint activity, not more training. One chart replaces most of the guessing.
4. End-customer health by implementer
Activation and retention for accounts implemented by each partner, compared with accounts you implemented yourself. This is the only early warning you get about delivery quality, and it is usually the missing number in programmes that discover a problem at renewal. The behavioural measures in our guide to user onboarding metrics work unchanged here; the only difference is the grouping.
Partner Onboarding: Do vs. Don’t
✅ Do
- Split the track by partner type before writing any material
- Spend the first two weeks of attention on access, not on theory
- Make the practitioner run the demo themselves, at least once
- Put in-work answers inside the product, planning answers in the portal
- Create the first opportunity jointly rather than waiting for one
- Define delivery as a customer outcome, not a completed configuration
- Re-check ladder position quarterly and refresh, not re-recruit
- Report activated partners next to recruited partners, every time
❌ Don’t
- Run one induction deck for referral, reseller and implementation partners
- Treat a completed training course as evidence of readiness
- Answer low engagement by sending more material
- Let the demo environment sit empty of realistic data
- Leave the escalation boundary vague and hope it works out
- Assume a partner-implemented account is being guided
- Measure the channel by number of signed agreements
- Let the first implementation happen entirely unobserved
Running Partner Onboarding With Kompassify
Most of what a partner needs is guidance attached to a moment: the demo path in the demo account, the setup order in the account being configured, what changed since they last logged in. Building that as product features means engineering time for an audience of forty companies, which is why it usually does not get built at all.
With Kompassify you add that layer without code, on the surfaces you already have. Put a guided demo path on the partner demo environment so a practitioner can re-run it alone before a call. Give implementation partners a setup checklist that lives in the customer account they are configuring, with progress that survives across sessions. Show a short announcement to partner users when positioning or a key feature changes, so refreshers reach them where they work rather than in an email. Walk a new partner through the portal on first visit. And because flows are segment-targeted, partner-facing guidance stays invisible to your direct customers, and vice versa.
The same layer protects partner-delivered accounts: every end user who arrives after the training session still gets a welcome flow and contextual help, whoever ran the implementation — which is how you keep a partner channel from quietly diluting the onboarding you designed. If your programme is growing faster than your team, the staged approach in our guide to scaling user onboarding applies to partners as well as to customers.
Give partners the confidence to demo without you
Build guided demo paths, partner setup checklists and in-product announcements without code, and keep every partner-delivered account guided to the same standard as your own. Free up to 100 monthly active users, plans from $129/month, GDPR-compliant and EU-hosted.
Start for free →The One-Paragraph Version
A signed partner agreement starts a countdown rather than finishing a process, because partner attention peaks in the fortnight after signature and decays from there. Split the programme by partner type, since a referral partner finishes at an introduction, a reseller at a deal closed without you, and an implementation partner at a customer who is genuinely live. Remember that you are onboarding two people: a principal who needs evidence the bet is paying off, and a practitioner whose only real fear is being asked something in front of a customer. Run them up a ladder of observable states — equipped, fluent, demo-ready, sourcing, productive — and treat each gap as a different problem rather than as a need for more training. Put planning answers in the portal and in-work answers inside the product, create the first opportunity jointly instead of waiting for it, and protect the first delivery closely. Then report activation rate, time to first outcome, ladder distribution and end-customer health by implementer, because a channel of forty signed partners and six selling ones is a channel of six.
Frequently Asked Questions
What is partner onboarding?
Partner onboarding is the work of taking a company that has just signed a partner agreement and getting it to the point where it can find, sell and in many cases implement your product without you in the room. It is different from customer onboarding because the partner is not the end user of the value: they are learning your product in order to earn from it, which means they need commercial fluency, demo skill and implementation competence, not just the ability to use the software. It is also different from employee onboarding, because you have no authority over their time and your product is one of several they carry.
How long should partner onboarding take?
Set the target in terms of a first outcome rather than a number of training hours. A workable default is thirty days to a partner who can demo your product unaccompanied, sixty days to a first partner-sourced opportunity, and ninety days to a first deal or first implementation delivered by the partner. If a partner has passed ninety days with no opportunity, treat that as a signal to re-engage or retire the relationship rather than as a partner who simply needs more time, because attention decays fast after the initial enthusiasm of signing.
Why do most channel partners never sell anything?
Because nothing in their week depends on it. A partner signs several vendor agreements a year, and the one that gets sold is the one whose product they can position confidently in front of a customer who is already in the room. Partners do not fail for lack of a commission structure; they fail because at the moment of opportunity they could not remember how your product differs from the alternative, could not demo it without asking you, and chose the product they were sure of instead. Partner onboarding is the work of removing that uncertainty before the moment arrives, not after.
What is the difference between partner onboarding and partner enablement?
Onboarding is the finite programme that takes a newly signed partner to their first outcome; enablement is the continuing supply of material, training and updates that keeps an already-productive partner current. The distinction matters operationally because the two have different owners and different failure signals: onboarding fails as silence in the first ninety days, while enablement fails much later as a partner who sells an outdated version of your story. Programmes that treat the two as one thing usually have a rich library and no activation process.
Who should own partner onboarding?
Whoever owns partner revenue should own partner onboarding, with product and customer success supplying the content. The common failure is splitting it so that channel sales owns recruitment and nobody owns what happens afterwards, which produces a growing list of signed partners and a flat line of partner-sourced deals. Whichever team holds it, one person should be able to say how many partners signed this quarter, how many can demo unaccompanied, and how many have produced an opportunity.
Should partners get the same onboarding as customers?
No, and giving them the same flow is one of the more expensive shortcuts in channel programmes. A customer needs to reach value in their own account; a partner needs to explain value to someone else, configure it in an account that is not theirs, and answer objections without escalating to you. Partners do need everything a customer gets, because they will work inside the product, but they need a second layer on top of it: positioning, the demo path, the common objections, the implementation sequence, and a clear boundary for what they escalate.
What should a partner portal actually contain?
Enough for a partner to prepare for a customer conversation without emailing you: current positioning, a demo environment or script, the implementation checklist, pricing and deal registration, and a short, current statement of what is new. The most common mistake is a portal that is a document warehouse, where a partner searching for one answer finds four versions of it with no indication of which is current. A smaller portal with in-product guidance sitting on top of it outperforms a large one nobody can navigate.