What a Workflow Spec actually contains

The spec that was really a wish list

Most owners have seen one. A thick document arrives after a few meetings in the conference room. It lists screens, fields, reports and user roles. Everybody signs it. Six months later the software works exactly as written and the crew does not use it.

Nothing in that document was false. It was just written about the wrong thing. It described the software someone imagined, not the work the crew actually does. Nobody stood in the yard at six in the morning when the trucks load. Nobody sat with the dispatcher at the moment three calls came in at once. Nobody counted how long a job ticket spent in a truck door pocket before it reached the office.

A Workflow Spec exists to fix that. Here is what goes in ours, and why each piece is there.

Observation before interviews

We watch the work before we ask about it. People describe their jobs the way they are supposed to go. Watching shows how they actually go.

Observation happens where the workflow breaks. That might be the shop floor, a job site, the cab of a truck or the desk where paperwork piles up. We note the conditions that decide whether any tool will survive: gloves, weather, noise, no signal, a customer standing there, a supervisor on the phone. A screen that works fine at a desk can be useless in a wet parking lot.

Then come the interviews, up to twelve of them. We talk to the people who do the work, the people who receive it and the person who pays for it. The crew lead tells us what they skip and why. The office tells us what they retype and fix. The owner tells us what the problem costs from where they sit. The gaps between those three stories are usually where the real workflow lives.

We also follow at least one real job from start to finish. Not a summary of a typical job. An actual one, with its actual customer, its actual delays and whatever went sideways that day. A typical job is an average, and nobody works an average. One real job shows the handoffs, the waiting and the workarounds in the order they happen, which is the order the tool will have to live with.

A baseline, measured before anything changes

This is the piece most specs leave out, and it is the one that matters most later.

Before we design anything, we measure how the workflow performs today. How long does a job ticket take to reach the office? How many jobs close with complete information? How many get touched twice? How many are waiting right now, and how old is the oldest one? We take these counts from the company's own records wherever the records exist, and by direct observation where they do not.

Without a baseline, nobody can say later whether the tool helped. Every conversation after launch turns into opinion. The office says it feels better. The crew says nothing changed. The owner cannot tell who is right. A baseline turns that argument into a comparison.

The baseline also sets up the usage number we will sign later. You cannot agree on what counts as an eligible job after launch if you never counted eligible jobs before it.

The map, the case and the adoption design

With observation, interviews and a baseline in hand, we write the core of the Spec.

The workflow map shows every step and every handoff, who does it, what they use, and where information gets copied, waits or goes missing. We name the failure patterns we find, such as the handoff gap or the exception swamp, because a named problem is easier to fix than a vague one.

The business case says what the broken workflow costs now and what a working one would be worth, in the company's own terms. Sometimes that is office hours. Sometimes it is days between finishing work and sending the invoice. Sometimes it is jobs that need a second trip. We state it plainly and we do not promise it.

The adoption design is the piece that separates a Spec from a requirements list. It answers the question every failed rollout skipped: why would the crew use this? It names the primary user group. It says what the tool will ask of them, and what it will stop asking. It describes how the tool fits into the moment the work already happens, rather than adding a new moment. It names who on the company side sponsors the rollout, who trains, and who the crew goes to when something is wrong. And it proposes the behavior we will count to prove use, for example the share of eligible jobs completed in the tool before the end of the shift.

The build specification, the proposal and the right to say no

Only now do we write down what the tool does. By this point the build specification is short, because most of the hard decisions have already been made. It covers the screens the crew sees, the integrations with the systems the company already runs, the exceptions the tool must handle and the ones it will hand to a person, the data it stores and where, and the instrumentation that will count use.

It also says what the tool will not do. A tight scope is what makes a fixed price honest.

The specification also names what the Build needs from the company. The four roles on the client side that must be named before the clock starts, beginning with the sponsor. The system access the integrations depend on. The data the tool will read on day one. The training time the rollout plan assumes. Writing these down in the Spec means nobody discovers them in week three of the Build, and it means the clock can be fair to both sides.

Then the Spec ends with a fixed Build proposal. Our Production Build starts from $60,000, and the Spec is where we fix the actual number, the six-week schedule from the access gate, and the usage threshold that decides the final 20 percent of the fee. There is also an approval brief, a short document your sponsor can forward to whoever signs off on spending, written in plain language without our sales copy in it.

A Spec can end in go, no-go or recommend-against. We mean that. Sometimes the workflow is broken because of a staffing decision, not a software gap. Sometimes the data the tool would need does not exist yet. Sometimes an off-the-shelf product already fits and the right move is to buy it. Sometimes the best fix is a change to who approves what, and no software at all.

A Spec that finds one of those answers has saved the company from building the wrong thing. That is why ours is paid at $15,000, fixed, and not credited against the Build. It is priced to be worth its fee when the answer is no, so we have no reason to talk anyone into a yes.

What to do next

If you have a spec from a past project, pull it out and check it against this note. Does it describe how the work happened, or only what the software should do? Does it record a baseline? Does it say how use would be counted? If the answers are no, that explains a lot about how the project went.

If you are still working out which workflow to look at first, the guide on crews not using a new system is a good place to start. When you are ready to see how the Spec leads into a Build, How we work lays out the whole ladder.