If Your Process Lives in One Person's Head, You Don't Have a Process

Three clients, three different businesses, and the same failure in each one.

Each one had something that worked well, owned entirely by a single person. And each one eventually hit the moment when that person wasn't around: they had left, or were overwhelmed, or just weren't available when the process needed to run.

The thing stopped working.

The influencer program at a client

One of the brands in the client's portfolio ran an influencer program. It had been live for a while, putting out content and bringing in some sales. Then it stopped. The influencers had not disappeared and the strategy had not failed. It stopped because the person who ran it wasn't running it anymore, and nobody had written down how it worked.

When the engagement picked it up, the program existed in name only. There was no roster of active influencers, no documented outreach process, no content submission workflow, and no clear rules on what got approved and what didn't. Payment ran through Refersion at a $100 threshold, but that lived in Refersion's system, not in any document the team could reference.

Rebuilding the program meant building it from scratch in Asana: outreach steps, approval criteria, content submission requirements, payment triggers. The goal was to have a new campaign running by October 1st. Whether that deadline was hit or not, the rebuild took weeks of work that should not have been necessary. The program had existed before. The knowledge had walked out with the person who ran it.

The fix is straightforward. At a minimum, an influencer program needs a roster with contact info and last activity date, an outreach template library, documented approval criteria, a content submission and review workflow, and payment processing rules. Put those five things in writing and the program survives someone leaving. Keep them in one person's head and it stops the day they do.

The supplier relationships at a former client

A former client's supply chain runs through a date farm in Mexico and a separate supplier for nut butters. Those supplier relationships ran deep: established contacts, agreed payment structures, quality standards, and a track record of how problems got sorted out when they came up.

That context lived mostly with the founder. When the operations team, including the consultants on the engagement, had to deal with suppliers directly, none of it was written down. Someone had to hunt down the supplier contact details. Payment terms got confirmed on the fly instead of pulled from a source of record. And when a production delay or a quality issue came up, the team had no documented escalation path. They had to go ask the founder.

The founder was sometimes available, sometimes not. When he wasn't, things stalled.

The specific risk this creates: an undocumented supplier relationship breaks down the moment the person who owns it is sick, on vacation, or leaves the company. The supplier doesn't know to call anyone else. The operations team doesn't know who to call on the supplier side, or what got agreed in earlier conversations.

Minimum viable documentation for a supplier relationship: primary contact and backup contact, payment terms per PO structure, quality acceptance criteria, lead time ranges including historical variance, and a record of any standing agreements or accommodations that exist outside the standard contract.

The forecasting model at a client brand

At a client brand, the master forecasting sheet was built by the consultant. It covered stock coverage calculations, PO tracking, NSPA container management, and dual-mode forecast switching between top-down and operational views. It was designed to reduce the time spent on the monthly rolling forecast from over 5 hours to something manageable.

The problem was that only the consultant fully understood it.

The owner could use the inputs and outputs. He could enter payment confirmations and read the coverage numbers. But the logic underneath, the formula structure, the forecast mode switching, the reorder date calculations, the reason each column existed, none of it was documented. The model worked because the consultant kept it working. If the consultant became unavailable, it would decay slowly as small errors piled up and nobody knew how to trace them.

This is a specific version of the single-person dependency problem, and it shows up in consulting engagements constantly. The consultant builds something useful, the client uses it, and the knowledge of how it actually works stays with the consultant. The client ends up owning the output without ever owning the capability behind it.

Making the client brand model transferable required writing explicit documentation for each section: what the formula is calculating, what inputs feed it, what to check when a number looks wrong, and how to update the model when new SKUs or suppliers are added. Color-coded status indicators on the process flow charts helped, but they supplemented documentation rather than replacing it.

What makes a process real

A process is real when a person who has never run it before can pick up the documentation and execute it without asking anyone for help.

That's the standard. It's a high bar, and most operational processes don't clear it, but it's the right bar. Anything short of it is a dependency risk that eventually turns into an operational crisis.

The minimum viable SOP for any repeatable process has five elements: the trigger (what starts it), the steps in order, the decision criteria for anything that branches, the output (what done looks like), and the escalation path (who to call when something breaks that isn't covered by the steps).

One page is often enough. Processes that need 20 pages of documentation usually haven't been simplified enough to actually run. You don't need to cover every edge case. You need enough structure that the process keeps running when the person who designed it isn't there.

The test is simple: hand the SOP to someone who has never done the task and watch what happens. If they can complete it without asking questions, the SOP is real. If they get stuck, you found the gap. Fix the documentation, not the person.