Six weeks after a new automation goes live, the numbers usually look worse, not better, than they did the week before the switch. Cases take longer to close, reports land later than they used to, and someone quietly reopens the old spreadsheet "just to be safe." None of that necessarily means the rollout failed. In most cases it means the rollout is exactly on schedule, because a real dip is a known, well-documented part of how a new process gets adopted, not a warning sign by itself.
What the Evidence Shows
The pattern shows up both in published research and across automation engagements. According to McKinsey's 2018 Global Survey on digital transformations, only 16% of respondents said their organization's transformation had both improved performance and sustained that improvement over time, with another 7% improving without sustaining it. The gap between those two figures is close to the dip described here: a result that looks fine right after launch, then fades once the adjustment period ends and old habits creep back in.
Economists Erik Brynjolfsson, Daniel Rock, and Chad Syverson gave this pattern a name in their research on general-purpose technologies, published as NBER Working Paper 25148 and later in the American Economic Journal: Macroeconomics. They call it the productivity J-curve. Their argument is that a new technology, whether a CRM, a BI platform, or an automated workflow, requires a set of intangible investments before it pays off: redesigned processes, retrained habits, and cleaned-up data. Those investments show up as a cost immediately and as a benefit only later, which is why measured output can dip below its starting point before it climbs past it.
Across automation engagements built for growing businesses, the shape repeats with little variation: a short window of confusion and slower output right after go-live, a stretch of steady improvement once the team stops running the old process in parallel, and a plateau above the original baseline once the new workflow is the only one anyone actually uses. What varies isn't whether the dip happens, it's how long it lasts and whether anyone recognizes it for what it is while it's happening.
The scope of what's being automated changes the shape of the curve without changing its existence. A single workflow, one alert rule, one data sync between two existing tools, typically settles within a few weeks, because only a handful of people need to adjust their habits. A rollout that touches how an entire department reports numbers, or reassigns who owns which decision, tends to take longer to settle, not because the software is more complicated, but because more people individually have to cross the same gap between trusting the old process and trusting the new one. Sizing the expected dip to the scope of the rollout, rather than using one fixed number for every project, is the difference between a realistic plan and a guess.
Why the Dip Isn't a Failure Signal on Its Own
The most direct cause is the simplest one: for a period of time, most teams are running two processes at once instead of one. Whoever owns the new automation still checks the old method to confirm the new one produced the right answer, which means the team carries the full cost of the manual process and the learning cost of the new one at the same time. That overlap is deliberate and necessary, skipping it to move faster is exactly how a genuinely broken automation goes unnoticed until it has already caused damage, but it also means the weeks right after launch are, briefly, more expensive than doing nothing at all.
The second cause sits underneath the first: automation exposes data problems a manual process had been quietly absorbing without anyone noticing. A person filling in a form by hand corrects an obvious typo without thinking about it. A workflow built to run on that same field either rejects the typo outright or, worse, processes it exactly as entered. The first weeks after go-live are frequently spent not on the automation itself but on the data hygiene the business needed all along, work that was always there, just invisible until something started reading the data literally.
The third cause is behavioral rather than technical: a new workflow changes who is responsible for a decision, and that handoff settles more slowly than the software configuration does. When an alert used to depend on someone remembering to check an inbox and now fires automatically, someone still has to build the habit of trusting it and acting the same day, instead of filing it for later the way they filed the old manual report. Software changes in a single deployment. Habits change over several weeks of repetition, and the dip tends to last exactly as long as that habit takes to form.
A fourth cause is coordination rather than adoption: when the automation crosses team boundaries, a lead generated by marketing now needs to be acted on by sales without the informal check that used to happen over a chat message. Removing that manual touchpoint is often the whole point of the automation, but it also removes a place where a mistake used to get caught by a person before it caused damage. Rebuilding that safety net inside the new process, an exception queue, a daily digest, a simple audit log, takes its own time, and until it exists, the team is right to be a little more cautious than the dashboard alone would suggest.
What Turns a Normal Dip Into a Failed Project
A dip becomes a real problem, not an expected phase, when one of two things happens. The first is scope creep during rollout: a pilot that solved one clearly defined problem gets expanded mid-implementation to also cover two or three adjacent problems nobody scoped for, and the added complexity pushes the adjustment period well past whatever anyone originally planned or budgeted for. The second is a decision made too early: leadership looks at week three's numbers, concludes the project isn't working, and either quietly reverts to the old process or starts a second project to fix the first one. Both responses reset the adjustment clock back to zero without ever reaching the recovery the first project was already most of the way through.
There's also a third pattern, simpler than either of the other two: nobody is assigned to watch the dip at all, so by the time someone notices output is down, weeks have already passed without any of the three responses covered below, a planned window, leading indicators, a checkpoint date, ever being put in place.
None of these three failure modes is really about the automation itself. All of them come down to measuring the wrong thing at the wrong time, or not measuring at all, treating week three's output as a verdict on the whole project instead of one data point partway through an expected curve.
Three Ways to Manage the Dip Instead of Reacting to It
None of the three options below prevents the dip. What they change is whether it gets managed on purpose or discovered by accident partway through.
- Set the expected length of the dip before launch, not after. Based on how many people and processes the change touches, agree in advance on a rough window, commonly somewhere between two and eight weeks for a single workflow, during which output is expected to run below baseline. A number written down before launch is a plan. The same number produced after week three, to explain why things look bad, is a rationalization, and it lands very differently with the people who have to sit through it. For a rollout that reassigns responsibility across more than one team, the upper end of that window is the safer planning assumption, not the lower one.
- Track a small number of leading indicators instead of full output. Full output takes weeks to recover and tells you almost nothing in the first days. Whether people are actually using the new process instead of quietly running the old one alongside it, and how many exceptions the automation is flagging versus processing cleanly, are visible from day one and say far more about whether the rollout is on track. A simple weekly count of how many records are still being double-checked against the old system is often the single most honest number in the whole rollout.
- Put a fixed checkpoint date on the calendar, not an open-ended "wait and see." Deciding in advance when the dip will be reviewed, and what it would actually take to call the project off at that point, keeps the decision from being made emotionally in week three, when the numbers look worst and patience is thinnest. That date deserves the same seriousness as the go-live date itself, not a vague plan to "revisit it later" once things calm down.
What's Worth Doing First
Of the three, setting the expected window before launch matters most, because it changes what week three's numbers mean before anyone has to interpret them under pressure. A dip that was planned for reads as progress. The same dip, discovered without warning, reads as a crisis, even when the underlying numbers are identical. The leading indicators and the fixed checkpoint both depend on that first step existing, since neither means much without a baseline expectation to measure against.
The realistic expectation isn't that the dip disappears with better planning, it's that it stops being mistaken for failure while it's happening. A rollout that was expected to take six weeks to settle and takes six weeks to settle isn't a project in trouble. It's a project going exactly the way the evidence says these projects go.
None of this removes the discomfort of watching the numbers drop in real time. It only changes what that discomfort means, and what to do about it, which is worth remembering before deciding a project is a mistake.
If you're planning an automation rollout and want the adjustment period built into the plan rather than discovered halfway through, you can read more about implementing automation for small businesses. The idea that the underlying process needs to be simple before it's automated, not after, is covered in the piece on why most automation projects fail.