Field notes. John Arndt, Soxoa. Published .
People ask me what a one-day build day actually consists of, usually because they have sat in a workshop before and left with a poster. The honest answer is that it is a working day with a deliverable, and the deliverable is something that runs on Monday. Here is the shape of it, so you can decide whether you want one.
One condition up front: the day only works if the preparation happened, and most of the preparation is not mine to do.
Before the day: thirty to fifty approved real examples
The person who performs the workflow collects thirty to fifty real examples of it, with an explicit instruction to include the ones that ruin their afternoon. Not a sample set someone cleaned up. The invoices with the handwritten note in the margin, the email with three separate requests in it, the scan that came through upside down.
Approved matters as much as real. Somebody with the authority confirms that these examples may be used with the tool we are going to use, and that anything which should not leave the building has been masked. That decision belongs to the client, and it happens before the day, because arguing about it at ten in the morning costs the build.
The range is not arbitrary. Below about thirty you are tuning to anecdote. Above fifty the day turns into reading.
First hour: the workflow goes on the wall
We draw the workflow as it is performed, not as it is documented. Every step, who does it, how many times a week, and where it waits. No tools in the conversation yet.
This is usually where the first surprise lands, because the person who does the work corrects the person who described it. A step nobody mentioned turns out to eat half a day a week. An approval everybody believed in stopped happening in the spring. That correction is why the map gets drawn in the room instead of arriving as a slide.
Second hour: red-line it into automate, keep a reviewer, leave manual
Then the map gets marked in three ways. Automate means the step runs without a person and we are willing to be judged on it. Keep a reviewer means the system does the work and a named human accepts or rejects the result before it counts. Leave manual means we are deliberately not touching it.
Every manual mark gets a written reason beside it, so a future team can reopen the decision on purpose rather than by accident. The list of things I will not automate is the part of my advice a client can check, which is why I produce it early and in front of everybody. More on that in leave it manual.
By the end of the second hour there is one candidate: a single step, or a short chain of them, carrying real volume and with a mistake that can be caught. That is what we build.
The middle of the day: building on the screen
The build happens on a screen everybody can see, with the people who do the work in the room, and it starts on the ordinary examples to get a baseline. Then we feed it the ugly ones on purpose.
What this produces, apart from a working thing, is argument at the moment argument is cheap. Someone says that is not how we phrase a refusal. Someone else says that field is right but it goes in the other system. Those corrections cost thirty seconds during the build and a fortnight after a handover. We keep a short record of what we tried and dropped, so the team can tell that the obvious idea was considered.
Afternoon: try to break it
The afternoon is spent attacking the build with the hard cases that were set aside in the morning. The message containing three requests. The document with a page missing. The exception somebody in accounting has been handling from memory for six years and has never written down.
Each hard case ends in one of three places: the system handles it, the system routes it to the reviewer, or it is marked out of scope with a reason. All three are acceptable. What is not acceptable is finding out in week three which of the three it was.
So the build leaves the afternoon with a known failure list, and that list is part of the deliverable. A build day that produces no failure list has not tested anything.
The last hour: operating notes and a name
The final hour is writing, and it is written for the person who will run the thing rather than for the person who paid for it. What it does. What it deliberately does not do. How to tell when it is wrong. What to do at that point. What to check weekly, and who to call.
Then somebody accepts the name. A named internal owner, in the room, out loud. If nobody will take it, we stop and say so, because an unowned system is a subscription with extra steps. That question is what the whole day is really testing, and it is why the readiness assessment puts ownership first. The last thing on the whiteboard is a ranked list of what to build next, including the items I have argued against building at all.
Why building it in front of the team changes whether they operate it
The reason to do this in a room rather than deliver a finished box is not enthusiasm. A team that watched the decisions being made knows which parts are load-bearing, so when the work changes they change the system instead of abandoning it. A team handed a finished box has no model of it, and the safe response to a system you cannot reason about is to route around it.
The second effect is calibration. People who saw the build fail at two in the afternoon do not over-trust it at nine the next morning, and they know which cases to look at twice, because they were the ones who broke it.
There is a limit worth stating. One day produces one workflow, tested on a few dozen examples, with the beginnings of an operating routine. It does not produce a portfolio, a policy, or a second workflow. If what you need is several workflows running properly in your environment, that is a build sprint, not a workshop.
Where this fits
A Live Build Workshop is the right rung when the question in the room is whether your own team can do this, and the fastest honest answer is to have them do it once with someone experienced beside them. If you are not sure the question is that one, the AI Readiness Assessment takes about five minutes, runs in your browser, and will tell you if something else should come first. Either way, schedule a strategy call and bring the workflow you think is worst. Scope and price are agreed before work begins.