The request is usually for the report
The first process a client names in a strategy session is nearly always the one that reaches the owner's desk. The weekly campaign figures, or a pipeline number for the Monday meeting. Somebody spends a morning pulling numbers out of two ad platforms and the CRM and pasting them into a sheet, and the owner reads the result at lunchtime. Both of them would like the morning back. The request is reasonable and it is the one we hear most often.
It gets asked for first because it is the part of the week the person paying for the work can see. The owner does not watch an enquiry sit unanswered on a Saturday, and no screen of theirs shows the review request that never went out. They see the report, because it lands in their inbox, and they see the person who assembled it looking tired on a Monday. Visibility sets the order of complaint.
The trouble is that the report is the last step, and nearly every step before it is manual. Every figure on it was typed by somebody. The source on each enquiry, the stage on each deal, the completion date on each job and the invoice that followed it all came from a person remembering to update a record. That record lives in another tool. Automating the report first gives the team a faster way of finding out that nobody updated the pipeline this week.
A report reads records it never made
A campaign report is a query. It reads a source field on each contact and a stage on each deal, and it adds them up by week. The report writes neither. The source gets set when the enquiry arrives, by whatever handles the form or the shared inbox, which is a lead capture job. The stage moves when a quote is viewed or accepted, which is a sales pipeline job.
The same applies to the review request a customer experience build sends after each job. It reads a completion event, and a completion event only exists if the job record changed state somewhere, which in practice means an invoice went out on acceptance or a technician marked the job done on a phone. Where neither of those is automated, the request fires on a date a person typed, on the day they remembered to type it. The automation inherits every gap in the typing.
So the visible pillar is usually the one with the most dependencies. Dependency runs in one direction. Lead capture writes the source and follow-up writes the reply and the booking, the pipeline moves the stage, and the completion date gets written by whichever rule sends the invoice. The report reads all of them and writes nothing that any other process needs, so a build that starts with the report starts with the one process every other process has to feed.
What each process reads and writes
We put every nominated task on the table with two things written next to it: what it reads and what it writes. A follow-up sequence reads an enquiry with a time on it and writes a reply and, when the contact answers, a note on the record. An invoice rule reads an accepted quote and writes an invoice and a completion date. The exercise takes under an hour. It is done in the words of the person who does the task today.
Then we look at where each input comes from, and if a task reads a field that a person types, we ask what could write that field for them. The answer is usually another task already on the table, under a different pillar and a different name. The win-back sequence the owner wanted reads a last-purchase date that the invoicing rule was going to set. Once every input has been traced back to the task that writes it, the order sets itself, because a process can't run on a record that doesn't exist yet.
One rule falls out of it. The process that writes a record goes live before the process that reads it. That is why follow-up usually goes first. It reads almost nothing, since an enquiry with a time on it is all it needs. It writes the source, the reply time, the booking and the first note on the record as a side effect, and that is most of what the report was going to read.
The visible request is not lost. It goes on the plan with a date, as the thing the earlier builds exist to make possible, and the client can see on one page why their report sits near the bottom. Clients we have sat with accept the order once it is drawn, because the chain is their own process with arrows on it. When there is an argument it is about which arrow is wrong, and that one is worth having.
The build the client did not ask for
There is a cost to this order and it lands in the second meeting. The client asked for a report and is being told that the first thing we'll build is a rule that puts every web form enquiry into the CRM with a source and a time on it. It looks like a change of subject. The rule is what fills the source column on the report they asked for, and we show that by listing the report's columns with, against each one, the process that will fill it and the week it is due.
We also need the first build to show on its own, whatever the dependencies say, because a client who has seen nothing for a month stops believing the plan. That is the second reason follow-up goes first. It sits at the top of the chain and it can be watched in the same week. The first acknowledgement goes out the evening the rule is switched on, and the client can time the reply to a test enquiry without us in the room. An invoicing rule depends on as little and shows nobody anything until month end. Where the two are otherwise equal, the one the team can watch goes first.
A thin early version of the report, built to keep the client happy, is the one shortcut we do not take. A report on empty fields teaches the team that the automation lies. That lesson outlasts the fields being filled. Where the client does not believe the records are thin, we run the report's query by hand in the session, and the blank cells make the argument better than we could.
