Building a Partnerships Department That Did Not Yet Exist

The starting condition

Dokitami needed partnerships to work as a growth channel before there was a department capable of running one. There was no CRM built for the purpose, no funnel definitions, no shared vocabulary for what counted as a lead versus a conversation versus a partner. What existed was an expectation: pharmacies, supermarkets, gyms, salons, estates, and workplaces were all plausible distribution points for a telehealth product, and someone needed to turn that plausibility into contact.

This is a more common starting point than it sounds, and a more dangerous one. A company can go a long way on individual hustle before anyone notices that hustle isn't a system. People make calls, get meetings, log nothing anywhere consistent, and the pipeline lives in someone's head and their WhatsApp thread history. It looks like activity. It behaves like fog.

The question that mattered

The obvious framing — find more partners — was the wrong one to start with, because it assumes the constraint is discovery. It wasn't. Lagos has no shortage of pharmacies, gyms, and workplaces to call. The actual question was narrower and less flattering: once someone picks up the phone and says yes, what happens next, and does the organisation know?

A partner can be called, express interest, receive information, and still generate nothing, if nobody owns the next step. That failure mode doesn't show up in a spreadsheet of "partners contacted." It only shows up when you ask what happened to each one individually, and in an ungoverned pipeline nobody can answer that question at scale.

What was tried, and what it showed

Early outreach, unsurprisingly, produced conversations. Conversations are cheap to produce and easy to mistake for progress. What they didn't reliably produce, without structure behind them, was a next action that survived the day it was created. An interested pharmacy manager today is an untouched contact in three weeks if the person who spoke to them has moved on to the next call and nothing recorded that a follow-up was owed.

The diagnosis that mattered here wasn't about outreach volume. It was that "partnership" had no operational definition. A signed partner, a partner who'd taken a call once, and a partner mid-onboarding were all describable, informally, as "a partnership." Collapsing those into one bucket makes the channel unmanageable, because you can't tell whether the function is healthy or just busy.

The operating system built

The response was to treat the whole partner relationship as a sequence with named stages, not a contact list with a status field bolted on. The funnel ran: target account, contacted, conversation, interested, qualified, onboarding, activated, reporting. Each stage had a definition precise enough that two people working the same account would agree on where it sat.

Category logic sat underneath that funnel, because a gym, a pharmacy, and a residential estate are not the same sale. A gym conversation needs a different opening and a different decision-maker than a supermarket does; a workplace partnership runs through HR, not a shop floor manager. Building category-specific prompts and offer framing meant the funnel could stay uniform in structure while flexing in content — the stage names didn't change, but what qualified as "qualified" for a gym looked different from what qualified for an estate.

Follow-up was made structural rather than personal. Every meaningful interaction needed an owner and a next action attached to it in the CRM, not held in someone's memory. This sounds like a small rule. In practice it's the difference between a pipeline that decays by default and one that has to be actively neglected to fail — the system now had to be ignored for a lead to go cold, rather than remembered for it to survive.

The last piece connected acquisition to activation. Recruiting a partner was never treated as the finish line, because a partner who has agreed in principle and a partner whose staff actually know what to do are different things. Onboarding and the first measurable activation step were built into the workflow as required stages, not optional extras that happened if someone got around to it.

Reporting split cleanly into four layers: activity (calls, conversations, visits), funnel movement (interested, qualified, onboarded, activated), channel quality (does this partner have an actual route to expose the service, or just a friendly conversation), and execution health (are follow-ups being completed, are records owned, is anything stalling silently). Keeping those four layers separate mattered more than any single metric inside them, because it stopped the team from reading "high activity" as "healthy channel" when the truth might be the opposite.

Onboarding and field-activation each got their own SOP rather than sharing one generic checklist, because the actions involved genuinely differ. Onboarding a pharmacy chain meant confirming a point of contact at each branch, agreeing where in-store material could sit, and setting a date for staff briefing. Onboarding a workplace meant a different sequence entirely — HR sign-off, an internal communication the employer would send, and a defined window for uptake. Writing these down as SOPs, rather than leaving them as tribal knowledge held by whoever ran the first few onboardings, meant a new team member could execute a category's activation correctly without having shadowed someone first.

A weekly reporting cadence sat on top of all of this, reviewing the funnel by category rather than in aggregate. An aggregate number can hide a category that's quietly stalled behind a category that's moving well; reviewing by category forced the conversation to be specific — which channel needs a different offer, which needs more follow-up capacity, which is working and should get more resource, not less.

What it changed

What this built was legibility. Before it, the honest answer to "how is partnerships doing" was a set of anecdotes. After it, the same question had a structural answer: how many accounts are at each stage, which categories are moving and which are stalling, and where the team's attention is actually needed this week rather than where it feels needed.

I'm not going to attach a revenue number to this specific case, because the function-build itself didn't produce one directly — it produced the conditions under which a revenue-producing channel could be run and audited. What I can say, because it's a matter of public record rather than an inference from this case, is that this same department is the one that later signed partnerships across more than two thousand physical locations, ran a field team of over fifty people across Lagos, and grew the channel to more than fifty million naira a month in partner-attributed revenue. None of that happened because of a CRM. It happened because the CRM, the funnel, and the ownership rules meant that when volume increased, the system didn't buckle under its own success.

What I would do differently, and what generalises

If I were rebuilding this again, I'd write the stage definitions before the first outreach call rather than a few weeks into it. We got there, but the early weeks generated exactly the kind of undifferentiated contact list the system was eventually built to prevent, and some of that had to be cleaned up retroactively.

The broader principle travels well beyond partnerships. Any function that depends on many small human handoffs — sales, recruiting, customer success — fails the same way before it fails any other way: not from lack of effort, but from the absence of a shared definition of what "progress" means at each step. Activity without stage definitions produces the feeling of momentum and the reality of drift. The fix isn't more hustle. It's naming the stages, assigning ownership at each one, and building the reporting to notice when a record stops moving before it's too late to matter.

There's a temptation, building a function like this from zero, to treat structure as something you add once things get big enough to need it. I'd argue the opposite: structure is cheapest exactly when there's nothing yet to migrate. Retrofitting stage definitions onto a pipeline that already has months of undifferentiated contacts in it is real, unglamorous work, and someone has to do it while the business keeps moving. Building the definitions first costs a few days of moving more slowly at the very start, in exchange for never having to do that cleanup later. That trade is worth making every time.