Map the Steps and Owners

This is the chapter people think the whole guide is about, and it is the shortest one that matters. The steps are the easy part. What makes them a specification rather than a list is two columns most people leave off: who owns this step, and how much of it happens without a person.

Owners are roles, and they are whoever gets asked

Every step has an owner, and the owner is a role, not a person's name. This sounds like bureaucratic hygiene until the first time somebody leaves.

More usefully: the owner of a step is whoever gets asked about it when it does not happen. Write that name down against every step and you will immediately find one or two steps where the honest answer is “nobody,” which is a finding. A step nobody owns is a step that will be silently skipped and then discovered eighteen months later.

Autonomy is a property of the step

Here is the observation the next guide is built on, and it belongs here because this is where you first see it. The level of automation is not a property of the workflow. It is a property of each step.

In a real follow-up cadence, some steps fire on their own: the record gets flagged, the task gets created, the reminder appears in a queue. Some steps are drafted by a system and executed by a person: a model writes the email using the record's context, and the owner reviews it and clicks send. Nothing auto-sends. And some steps are entirely human: the call, the note, the judgment about whether this person is worth a second attempt.

One workflow. Three different levels of autonomy, chosen per step, for reasons that are specific to each step. That is normal and correct, and a workflow that is uniformly automatic or uniformly manual almost always got that way by default rather than by decision.

When a step's quality depends on the record

When a step's output depends on how good the underlying record is, say so in the specification, and then say what to do about it. A follow-up drafted from a rich record reads like it was written by someone who was in the room. The same step drafted from a record with no logged touchpoint, no recent activity, and no stated next step produces something generic, because there was nothing specific to anchor on.

Garbage in, garbage out is a true statement and a useless one, unless it comes with the remedy. So the remedy goes next to the step: if the output looks generic, the input was thin, and here is the specific thing to log so the next run is better.