Go-live day feels like the finish line. The data is migrated, the training happened, the first job runs clean, and everyone is briefly, unnaturally careful. Then week two arrives, and the team is slower than it was on the old way. Estimates take longer. The office manager keeps a browser tab open to the old spreadsheet, just in case. Somebody asks, quietly, whether the new system was a mistake.
That slowdown alone does not prove the system is wrong. It usually means the team is replacing old habits while fixing early workflow gaps. The old way was fast because years of muscle memory made it fast. The new way is slow because it is two weeks old. Productivity often drops before it climbs past the old ceiling; the drop is the cost of replacing muscle memory. Drift, left unmanaged, is what turns the drop into a failure.
How systems die
Nobody announces a rollback.
The death is never dramatic. A spreadsheet reappears, just for now. Dispatch slides back into text threads. A paper ticket rides in a truck again. Each workaround is reasonable on the day it happens, and each one moves a little of the truth out of the system. Within a few weeks the data lives in two homes, nobody fully trusts either one, and managers quietly go back to getting their numbers by asking people. The system is still live, still paid for, and empty. An expensive failure with a ribbon on it.
A system does not die by decision. It dies by drift, one reasonable workaround at a time.
The four weeks
The month after go-live is part of the project.
Treat the first four weeks as a managed adoption period, and run the month like a project, not a hope. By the end of it, usage and workaround trends should show whether the team is adapting or the workflow needs redesign. Each week fails differently.
W1
The small breaks
Logins, permissions, and the one workflow that does not match how the work actually happens. Fix the small stuff the same day: the speed of the first fixes decides how much patience you get for the rest of the month.
W2
The valley
The old way was faster for whoever had mastered it, and the whole team watches how the veteran takes it. Name the dip out loud in the Monday meeting: it is normal and it is temporary. Then retire old access where it is safe to, so persisting is easier than reverting.
W3
The fork
Half the team is in the system, half works around it, and the data splits into two homes nobody fully trusts. The move is absolute: if it is not in the system, it did not happen. And leaders pull every report from the system, visibly.
W4
The habit
Nothing breaks loudly, which is the trap: the leftover gaps stop being noticed and start being permanent. Re-train the outliers role by role, on their real work.
The training bar
Set a role-level training bar.
Attendance is not training. Each role should complete its real weekly tasks in the new system, on live data, without help, before training is called done. Then track three things every Friday: role usage, workflow completion, and returns to spreadsheets, texts, or paper. Aim for complete adoption among the roles that use the system, because one role left behind becomes the leak everyone else routes around. The week the tracking stops is the week the reversion starts.
The full playbook includes the weekly plan, the role checklists, the SOP template, and the Friday tracker, all printable and free. Read the adoption playbook. No email, and it works with whatever system you run.
We build systems for a living, and we will still say it plainly: the four weeks after go-live matter as much as the software you pick. A sound system the team actually uses creates more value than a feature-rich system the operation works around. Go-live ends the build. Adoption is the finish line.
Fair questions
The pushback, answered straight.
How long does the dip last?
Treat the first four weeks as a managed adoption period: named owners, measured usage, same-day fixes in week one. By the end of it, usage and workaround trends should show whether the team is adapting or the workflow needs redesign. Left unmanaged, the dip does not so much end as calcify: the workarounds become the process.
The team says the old way was faster. Are they wrong?
They are right, for now. The old way was faster because they had mastered it; speed follows the habit. What matters in week two is direction, not speed: usage climbing, workarounds shrinking, the veteran visibly on board.
Does this only apply to systems Arkode builds?
No. The playbook is written to work with whatever system you run, including one we did not build. The dip is about people and muscle memory, not about any vendor.
Written by
Rodrigo Yeo
Founder of Arkode. Builds operating systems for service companies in the US and Mexico.