Building the One Place Partnership Work Went to Be True

The starting condition

Partner work at Dokitami crossed pharmacies, supermarkets, gyms, salons, residential estates, and workplaces, and each of those environments had its own rhythm, contact type, and activation logic. That variety was a strength for distribution and a liability for information. One person knew an account had been called. Someone else knew a contact had shown interest. Field activity — the part where a partnership actually became visible to a customer — often sat entirely outside whatever system was supposed to be tracking the pipeline.

This isn't a story about disorganisation in the pejorative sense. It's what happens by default whenever commercial work spans several channels run by several people, and nobody has yet built the layer that reconciles what each of them knows. The problem compounds with success — the more the team achieves, the harder it becomes to see clearly, ironically, because more activity means more fragmentation unless something is actively holding it together.

The question that mattered

The failure mode wasn't a lack of data. There was plenty of data, scattered across call logs, memory, and individual habits. The failure mode was that no pipeline number could be trusted, because nobody could say with confidence what it was made of. A count of "120 active partnerships" might contain raw prospects who'd taken one call, duplicate entries for the same account logged twice by two different team members, unqualified interest that would never convert, and a handful of genuinely active partners generating real activity — all counted the same way.

The question that actually mattered was: what does a record mean, precisely enough that two people looking at it would agree? Without a shared answer, the team couldn't distinguish a channel that was active from one that was stalled from one that had never really been tested, and any report built on top of that ambiguity was decoration, not information.

What was tried, and what it showed

Before the master system existed, category teams tracked their own accounts in whatever way was locally convenient — different sheets, different shorthand, different definitions of what counted as "qualified." This worked at small scale, in the sense that any individual person could usually answer questions about their own accounts. It broke down the moment anyone needed a view across categories, because comparing a pharmacy pipeline built one way to a gym pipeline built another way meant translating both into some third format before anything useful could be said. That translation step is exactly the kind of friction that quietly ensures nobody does the cross-category analysis at all, and the organisation runs on category-level anecdotes instead of a channel-level picture.

The operating system built

The response was a master partnership CRM with explicit, shared definitions rather than another spreadsheet with more columns. Account and partner-category records were consolidated so that contact history, status, and ownership could be reviewed together regardless of which category a partner belonged to. The funnel itself used one taxonomy across every category — outreach, conversation, interest, qualification, onboarding, activation — so a record's stage meant the same thing whether the partner was a pharmacy chain or a workplace HR contact.

Next-action discipline was built into the schema, not left to habit. A record only counted as properly maintained if it carried an owner and a next step specific enough that a different team member could pick it up cold and know what to do. This is a small structural choice with an outsized effect: it converts the CRM from a record of the past into a tool for the next action, which is the difference between a system people check and a system people update because they're told to.

Field activity — recruitment, onboarding, and activation — was joined to the pipeline as evidence attached to a partner's progression, rather than logged separately as its own disconnected activity stream. That mattered because the previous default, where field notes lived apart from the CRM, meant the two systems could quietly disagree: the CRM might show a partner as "qualified" while the field team knew the relationship had gone cold weeks earlier. Joining them closed that gap.

Reporting was structured by category and by stage simultaneously, which let the team see two things at once that are easy to conflate: whether a category looked promising in aggregate, and whether that promise was actually supported by accounts moving through the funnel rather than sitting at "interested" indefinitely. SOP references were attached directly to the relevant stages and categories, so the process expectation for a given record was never more than a click away from the record itself.

A stalled-record view sat alongside the standard funnel report, and it did more day-to-day work than almost anything else in the system. Rather than asking the team to remember to check on accounts that hadn't moved, the CRM surfaced any record that had sat in the same stage past a defined threshold — a proxy for the plainest possible question: is anyone actually still working this account, or has it just been forgotten. A funnel report tells you the shape of the pipeline. A stalled-record view tells you where it's silently rotting, which is the half of the picture a standard funnel view leaves out entirely.

The schema also had to survive being used by people who weren't the ones who designed it. That's a different bar than building something that works for its author. Field names needed to be self-explanatory enough that a new hire could enter an accurate record on their first week without a training session, and status definitions needed to be resistant to reinterpretation — "qualified" had to mean the same specific thing to someone who joined the team a year after the schema was written as it did to whoever entered the first record. Definitions that only work in the head of the person who invented them aren't really shared definitions at all.

What it changed, honestly stated

What this built is decision visibility, and I want to be precise about what that does and doesn't mean. It doesn't mean a quantified before-and-after in data quality, and it doesn't mean a revenue outcome directly attributable to the CRM's existence. The underlying work doesn't support either claim, so I'm not making it. What it does mean is that the team gained the ability to ask a specific, answerable question — is this a reach problem, a response problem, a qualification problem, an onboarding problem, or an activation problem — instead of a vague one, "why isn't this channel working," that nobody could actually resolve.

That distinction is not a small consolation prize. A commercial team that can localise its own bottleneck is a fundamentally different organisation from one that can only observe that something, somewhere, isn't going well.

What I would do differently, and what this generalises to

If I rebuilt this today, I'd version the stage definitions from day one, with a changelog, because definitions inevitably need to evolve as the business learns more about each category, and an unversioned system makes it hard to know whether a shift in the numbers reflects real change in the business or just a redefinition of what "qualified" means.

The general principle applies to any organisation running commercial activity across more than one channel type with more than one person touching the pipeline: the CRM is not an administrative afterthought bolted onto the strategy. It is the strategy's operating memory. A team can have excellent instincts, hard-working people, and a genuinely good product, and still be unable to tell you where its own bottleneck is, because nobody built the layer that makes the channel legible to itself. That layer has to be designed with the same seriousness as the outreach it's meant to support, or the outreach eventually outgrows the ability to understand it.

I'd also push back on a common assumption in how these systems get scoped: that the CRM's job is to record the past. Its more valuable job, done right, is to make the next action obvious. Every design decision here was tested against that standard — does this field, this view, this definition, make it easier for someone to know what to do next, or does it just make the record more complete for its own sake. Completeness for its own sake is how CRMs turn into places data goes to be filed and never looked at again. The ones that actually get used are the ones that keep answering, cleanly and quickly, the only question that matters on a Tuesday morning: what should I do right now, and for whom.