Define Completion and SLA

Done is not “all the steps ran.”

Chapter 1 wrote the business outcome: a booked conversation with the right seller, or a recorded reason why not. Completion has to be measured against that, or the workflow reports success at exactly the moments it is failing.

The difference is not academic. A cadence that sends every scheduled message to a person who never opens any of them has completed every step. Under a step-based definition it is a success, and it will appear in the success column of a report, next to the ones that booked meetings. Under an outcome-based definition it completed with a recorded non-result, which is a different thing and counts differently.

The SLA

An SLA is a promise about time, made to somebody specific. Contact every qualified inbound request within one business day is a good one: it is measurable, it is a commitment, and it has an owner who is accountable when it slips. It was a poor answer for the business outcome in Chapter 1 and it is exactly the right answer here.

Two things make an SLA real rather than decorative. It has to start from an event that is recorded, so the clock has an unambiguous origin. And somebody has to be told when it is missed.

The stall state

Now the honest part, and the reason this chapter is not simply about definitions.

Chapter 3 established that autonomy is chosen per step, and that some steps are executed by a person. That is the right design. It also creates a specific failure mode that has to be written down, because it is invisible from every direction unless somebody names it.

A workflow that waits on a human does not fail when the human does not act. It waits. Indefinitely. The record is not completed, not exited, and not errored. It is in limbo, and limbo does not appear in a failure report because nothing failed.

Good documentation for this kind of system says so plainly: the cadence pauses at each manual step until the owner acts, and if the owner ignores their queue, the record sits there and never exits naturally. That is not a bug report. It is a design consequence, written down by the person who designed it, so that the people operating it know where to look. A specification that names its stall state has told you what to monitor. One that does not has left you to find out.

Three things to write

For every step that waits on a person: name the state, because waiting on owner is a real status and not the absence of one. Give it a clock, because without a threshold nothing can tell normal from stuck. And say who hears about it, which is never the person who is stalled, since they are already not looking.