Finished means somebody else can change it
The first messages go out on the day an automation goes live, and for a few weeks that looks like the end of the job. It is not. Its wording describes an offer that will change. The form it listens to will be edited by whoever owns the website, and the person who asked for the build will at some point leave. Each of those lands on the client's team, who either open the automation and deal with it or call us.
So we define finished differently. A build is finished when someone in the client's team who did not build it has opened it and changed a line, using nothing but a document we left behind. Until then the automation is still ours in every way that matters, and the client is paying a retainer they didn't agree to, one call at a time. Nobody prices that at the proposal stage.
That is why the note is written during the build. Written afterwards it becomes paperwork, done from memory by whoever has an afternoon free, and it describes the build the way we remember it. Written alongside the build it records each decision as it is made, including the ones nobody would think worth mentioning a month later. It adds time to every step. A new hire in the client's team will read nothing else we produced.
The trigger goes first
The note opens with the trigger, because the trigger is the part most likely to break and the least likely to be noticed when it does. It is usually a submission on one named form or a deal reaching one named stage in the CRM. The note says which, in the name the tool gives it, and where a person goes to watch it fire. The check is a test enquiry through the form and a look at whether the record arrived in the CRM, and it is what we ask the owner to do after any change to the website.
The reason it goes first is that a trigger fails silently. When somebody renames a field on the website form the automation doesn't error. Nothing arrives. The first sign is a quiet month that gets blamed on the market, and a person with the note can open the form and check the field names against the ones we wrote down before the month is out. Without it the same fault takes a call to us and a morning of our time.
We also write down what the trigger is not. If the sequence listens to the contact form and not the quote request form, the note says so, because the question after any website change is which forms are connected to what. A short list of what was left out on purpose stops the client wiring a second automation on top of the first.
Every step in the tool it runs in
After the trigger the note walks through each step, inside the tool where it runs. If the second step is a workflow in the CRM, the note gives the workflow's name as the CRM lists it and says what it reads and writes. If the third is a scheduled send from the email tool, the note names the template, the sending address, the delay before it goes and the rule that stops it. A step in a connecting service between two tools gets the same treatment, down to the account it runs under, because that is the account that lapses when a card expires.
The note is written in the tool's own words because the person reading it will have the tool open beside it. A line that says the enquiry is qualified and routed gives them nothing to click on. A line that says the record enters the new enquiry workflow and is assigned to whoever owns its source tells them where to look when a lead reaches the wrong person. Screenshots go out of date the month a vendor moves a menu. We use names, and we say what to search for.
Every message is in the note in full, with the step it belongs to and the place the text has to change when the offer changes. Messages go stale first and get edited most often, so the note says where the words live. The stop rules sit in the same section: what ends the sequence, which is a reply, a booking or an unsubscribe, and where each rule is set. A rule the owner cannot find gets argued about the first time a customer complains that the messages have not stopped.
Anything we cannot describe this way gets looked at again. A step we can't name in the client's tools is a step we have built somewhere the client cannot see, a script on our side or an account they do not own. It either moves into a tool they hold the login for, or it gets written up in enough detail that a developer they hire could rebuild it without us. The note is a check on our own build. It catches things testing does not.
The test before we leave
The note gets tested the same way the automation does. Before the engagement closes, the person named as the owner sits down with it and makes one real change without us in the room. In most cases it is a line of wording in the first reply or the number of days before an open quote is chased, because those are the changes a team reaches for once we've gone. We see only the result. It is either a changed message in a test inbox or a call asking where something is.
If the call comes, the note is wrong, and we fix the note before anyone touches the automation. That sounds like a small distinction and it changes what gets written. A note that says the delay is set in the sequence settings produces a call. One that says the delay is the number in the wait step between the first message and the second, and names the sequence that step sits in, does not.
The owner was named before the build started, because an automation nobody is responsible for keeps running exactly as it did on the day we left, long after that stops being right. What the note adds is a line on which changes that person makes without asking anyone and which ones come back to us. Most of them are theirs. The point is to keep our share short, so that a change to the offer never waits on our diary.
