Every business we've worked alongside has a folder called something like "Processes" or "SOPs," and inside it a handful of documents written with real care, usually during a rare slow week, by someone who meant every word. Open that folder six months later and ask who last followed page three. The document isn't wrong. It's just not a process. It's a description of one.
The orphan step
There's a plain name for the gap, and it's worth saying out loud in your own Monday meeting: the orphan step. It's a line in a written procedure that describes what should happen but names no one who has to do it, attaches to no trigger that starts it, and leaves no record of whether it happened. "Send the welcome packet after deposit." "Check in with the client at week two." "Confirm the renewal date before it lapses." All true, all sensible, all orphaned the moment the document gets saved and closed.
An orphan step survives exactly as long as the one person who wrote it remembers to do it themselves. The day that person is on holiday, or hands the client off to someone else, or just has a bad week, the step doesn't happen and nothing notices. Not the team, not a dashboard, not the client, until the client notices first.
Where "write a better SOP" runs out
The standard advice, repeated in every list of tips for growing businesses, is to write clearer procedures: more detail, numbered steps, maybe a screenshot. That advice isn't wrong, it's just solving a problem you probably don't have. Most teams we've seen don't fail because the writing was vague. They fail because a well-written step still has to compete for someone's attention against the pipeline, the proposal that's due, and the login nobody can quite remember for the system where the document actually lives.
A procedure only becomes a process once it stops being prose and becomes a task: owned by a named person, attached to a trigger that starts it automatically, carrying a date, and visible to someone other than the person doing it. Four things, not one. Write it down covers exactly one of the four, which is why "we have a process for that" and "that actually happens" are such different sentences in most businesses.
The agency that kept re-teaching onboarding
A marketing agency we'll describe without naming kept hearing the same complaint from new clients: things go quiet for a couple of weeks right after they sign and pay their deposit. The owner's read on it was that the team was slow, maybe overloaded, maybe needed reminding. There was, in fact, a written onboarding checklist. It lived in a shared folder and covered exactly the right steps: welcome email, asset request, kickoff call booked, project folder created.
The real issue wasn't the checklist. It was that nothing in the business actually fired when a deposit landed. The invoice got paid, the bookkeeper recorded it, and that was the end of the chain. Whoever handled the account was supposed to remember to go open the onboarding document and start working through it, on top of everything else landing in their inbox that day. Some weeks they did. Some weeks a new proposal came in at the same moment and onboarding slipped a few days, then became the client's problem before it became anyone else's.
What changed wasn't the wording of the checklist. It was that "deposit received" became the actual trigger: the step got assigned to a named account manager the moment the payment cleared, with a due date attached, and it showed up as an open task that the owner could see sitting unresolved on the team's board rather than buried in a document nobody was prompted to open. The quiet-after-signing complaint, which had been a recurring line in client feedback, stopped being recurring. Not because the team got faster. Because the handoff from sales to delivery stopped depending on someone's memory.
What actually has to attach to a step
If you want to know whether a line in your process document is a real process or an orphan, ask it four questions.
- Who is it assigned to, by name, not by role or by "whoever's free"?
- What triggers it, a date, a deposit, a signed proposal, a form submission, something that fires on its own rather than requiring someone to remember to go looking?
- Does it have a deadline that's visible somewhere other than inside the document itself?
- Can someone other than the person doing it tell, at a glance, whether it got done?
A step that fails all four isn't a weak process. It's a sentence. The scorecard you review on Monday is only as honest as the number of steps feeding it that actually meet this bar; a scorecard built on top of orphan steps just reports on whoever happened to remember that week.
The handoff is where orphans breed
Almost every orphan step we've found lives at a handoff: sales to delivery, delivery to invoicing, invoicing to renewal. Inside one person's own work, steps tend to get done because the person feels the discomfort of leaving something unfinished. Across a handoff, that discomfort disappears, because the next person doesn't know the step exists until it's already late. Any procedure document worth keeping should be read specifically for its handoffs first, since that's where the written version and the lived version diverge fastest.
Where this isn't the answer
None of this means every step needs a formal owner, a trigger, and a tracked deadline. If you're a business of one or two people and the step is something you personally do every single time without fail, the overhead of formally assigning it to yourself is wasted motion. Write it down so a future hire can learn it, then move on. The orphan step problem shows up specifically at the point where a business has grown past the stage where one person's memory can carry the whole operation, and not before.
It's also worth saying where consolidating onto a single system is the wrong move entirely. If the actual problem is that nobody agrees what the step should be, moving an unclear procedure into a project management tool just gives you an unclear procedure with a due date on it. A trigger and an assignment can't fix a step that was never thought through. In that case the fix is a conversation, probably in the next Monday meeting, about what should actually happen at that point in the pipeline, before anyone touches a tool at all. Assigning confusion just makes confusion arrive on schedule.
The order matters: get the step right first, in plain language everyone in the room agrees on. Only then does it earn an owner, a trigger, and a place on something the whole team can see. Skip the first part and you've just automated the wrong thing faster.