Modeling a Sales Pipeline as Data, Not Code

A doctor directory is only as useful as the doctors actually listed on it. Getting a doctor from "never heard of us" to "fully listed with a published video profile" isn't a form submission — it's a cold call, a WhatsApp conversation to collect their data, an in-person video shoot, and a sales follow-up. Left alone, that process naturally ends up spread across a spreadsheet, a phone, and someone's memory of who to call back today.

One document per lead, not one system per step

The acquisition funnel behind BD Doctors Directory is modeled as a single document per lead, moving in strict order through defined stages: new, no_answer, follow_up, whatsapp_group, listed, video_scheduled, video_review, video_published, a revenue stage, and finally advocacy. The call team's notes, the WhatsApp data collection, the video shoot schedule, and the sales cadence all write to that same record — not to four different systems that someone has to manually reconcile.

Terminal states — rejected, invalid — are deliberately excluded from that ordered progression. Nothing is "further along" than an exit from the funnel, so the data model doesn't pretend otherwise.

The part that isn't hardcoded

The obvious way to build a follow-up cadence is in code: "if no answer, retry in 24 hours; if still no answer, retry in 72 hours," and so on. That works until the marketing team learns something about what actually gets doctors to respond, and the answer requires an engineer and a deploy.

Instead, how many hours after a missed call to try again, and on which channel, lives in a separate playbook document per stage — editable without touching code. That playbook can express either a specific sequence of follow-up offsets or a steady repeat interval, whichever fits the stage.

Why the distinction matters

Modeling the process as data instead of code doesn't just save engineering time. It changes who's allowed to improve the process. The team running acquisition can tighten a follow-up window, add a channel, or change the cadence for a stage that's underperforming, based on what they're actually seeing — without waiting on an engineer's availability or a deploy pipeline. The system keeps up with what the team learns, instead of lagging behind it by a sprint.

When this pattern applies

Not every business process deserves this treatment — most workflows are stable enough that hardcoding them is simply less work. The signal to watch for is a process that a non-engineering team owns and is actively still learning how to run well. If the people closest to the process are the ones who'll want to change it, and they don't write code, the process belongs in a document they can edit, with a schema that keeps it structured — not in an if statement that only you can touch.