The first week counts the old process
An automation goes live on a Tuesday. By the following Monday somebody in the client's team has opened the CRM report and found that reply time is longer than it was and the pipeline is worth less. The natural reading is that the build has made things worse, and that is the question we get asked in the first review meeting. Those numbers are almost always a reading of the old process, taken properly for the first time. That gets said before the build.
Before the build, most of what went wrong inside a process was recorded nowhere. An enquiry that arrived on a Friday evening and got no reply until Monday never appeared in any report as a slow reply, because the clock in the CRM starts when a person opens the record. Nobody opened it until Monday. A quote that expired without a chase stayed in the pipeline as an open deal, at full value, for as long as nobody marked it lost. The process was producing those results every week and the reports were built in a way that couldn't see them.
So the first thing an automation does is make the process visible, and visibility is what the first week's figures are showing. Every enquiry becomes a record the moment it arrives. Each open quote gets a chase, and some of the answers that come back are no. The team is looking at the same process it always had, measured for the first time from the moment things happened and not from the moment somebody noticed them.
We put the dip in the proposal, number by number, with the reason each one will move. It takes half a page. A client who has read it treats the first week as evidence the build is running. Without it the same figures get read as evidence that it failed, and that conclusion is hard to move once somebody has said it out loud in a meeting.
The numbers that get worse first
First response time is the number people expect to improve at once, and the headline figure does, because an acknowledgement now goes out the moment an enquiry lands. The figure underneath it is the one that looks worse. Before the build the CRM started its clock when somebody opened the record, and it only counted the enquiries that got a reply at all. Now it starts when the enquiry arrived, and it counts every enquiry, including the one that came in at eleven on a Saturday night and waited for Monday. That is a different number, and it was always the true one.
Bounces and unsubscribes appear in the first week because the list has never been written to before. A database that was only ever used to look up a phone number has addresses in it that stopped working two years ago. Nobody found out, because nothing was sent. The first sequence finds every one of them in a single send, and a bounce rate that was zero because nothing went out becomes a bounce rate that is real. Unsubscribes come from the same place. Some of the contacts never wanted to hear from the company, and the first message they receive is the first chance they've had to say so.
The pipeline usually loses value in the first week, and that is the number a managing director notices. A chase sequence goes out to every open quote and some come back with a no, which turns a deal that was sitting at full value into a lost deal with a reason on it. Those deals were already lost. The pipeline was carrying them because losing a deal requires somebody to mark it lost, and nobody had. A pipeline that is worth less on Friday than it was on Monday has stopped carrying deals that were never going to close.
Duplicates show up the same way. Two records for the same person means two sequences to the same inbox, and the contact replies to the second one asking why they've been written to twice. That reply lands in the first week, in front of the person whose name is on the message. It was always two records. The first send is what made it cost something.
The hours go up before they come down
Manual hours are the number the team feels, and in the first week they rise. Somebody has to read the replies the chase sequence produces, and it produces more of them in seven days than the manual chase managed in a month. The duplicates and the empty first-name fields need fixing as they surface, and the person fixing them was supposed to be getting a morning back. Somebody also watches the automation itself, because nobody trusts it yet. That is the right instinct in week one.
We plan for it. The handover note names the person who reads the replies in the first fortnight and says how much of their week it should take, and the estimate is deliberately generous. A team that was told it would get hours back on day one, and then spends the first week answering a backlog it didn't know it had, will conclude the build failed. That conclusion is hard to move afterwards.
The backlog is the point. Open quotes get an answer and dormant contacts get sorted into people who replied and people who didn't, and the work of doing that was always owed. It was being carried as an open pipeline and an untouched list, which cost nothing anybody could see. Once it has been paid down, the week starts to look like the week the proposal described, and it does not look like that before. More than 10,000 hours of manual marketing work were automated across our engagements in the past year. Very few of those hours came back in the first seven days.
What we read in the first week
In week one the figures worth reading are the ones that say whether the machine ran, and none of them says anything about the business yet. We check that every enquiry became a record carrying its source and the time it arrived. The stop rules get tested next, because a sequence that keeps sending after a contact has replied does damage at a steady rate. We reply to a test message ourselves and watch the chain halt. Then a sample of what actually went out gets read, with the person whose name is at the bottom of it. Nothing else gets read yet.
Everything else we write down and leave alone. Reply time, bounce count, pipeline value and manual hours all get recorded in week one, next to the baseline that was taken before the build, and the comparison waits until day thirty. A week is long enough to find out whether the chain fires. It isn't long enough for a reactivation sequence to produce a meeting, and it is exactly long enough for the backlog to make every number look worse than it did.
The baseline taken before the build is what makes the first week readable at all. Without one the dip gets read as a change in the business, because there is nothing else to read it against, and the people asking in that meeting are rarely the ones who described the process. A baseline lets us show, figure by figure, that what changed was the measurement. The conversation then moves on to day thirty.
