First 90 Days After Go-Live: An Ops Manager's Guide

Your new system went live last Monday. By Wednesday, three people had asked if you could “just go back to the old way.” By Friday, someone had built a spreadsheet that duplicates what the system is supposed to do. This is what the first 90 days after go-live looks like for most operations teams.

The gap between “system is live” and “system is actually working for us” takes longer to close than anyone expects, and it feels worse along the way. According to Deloitte, 75% of executives say measuring the impact of digital transformation remains their primary challenge. For ops managers, that challenge plays out in real time on the floor.

Here is what to expect, what to watch for, and how to get your team through it.

Why Every Go-Live Has a Productivity Dip

Every system change brings a temporary productivity drop. It is not a sign of failure. It happens because your team is doing the same work they did before, but through unfamiliar workflows.

Think about what changes on day one. People who could process a task in three clicks now need seven. Muscle memory built over years is suddenly useless. The shortcuts and informal knowledge (“just ask Maria, she knows where that file goes”) no longer apply.

The dip happens because competence resets. Your team did not get worse at their jobs. They lost the efficiency that came from years of practice on the old system. Research from Prosci on ERP adoption consistently shows that organizations underestimate this gap between current-state and future-state processes, and that the support needed to close it often falls short.

Managed well, the dip is temporary. Left alone, temporary workarounds become permanent fixtures.

What the First 30 Days Actually Look Like

The first month is survival mode. Your team is learning a new interface while still being responsible for the same output. Expect to see:

Processing times double or triple. Tasks that took 5 minutes now take 15. This is normal.
Error rates spike. People enter data in wrong fields, skip steps, or misunderstand new workflows.
Questions flood in. Your inbox fills with “how do I…” and “where did… go?” messages.
Frustration peaks around week two. The initial patience wears off and the reality of daily friction sets in.

The biggest mistake ops managers make in this phase is trying to fix everything at once. You cannot. Instead, focus on three things:

Keep a running issue log. Not a complaint board. A structured log that captures what is broken, what is just unfamiliar, and what is a genuine system gap. This distinction matters later.
Protect your power users. Identify the 2-3 people on each team who are adapting fastest. Shield them from being everyone’s help desk. They need time to build their own competence before they can help others.
Set expectations with leadership. If you did not do this before go-live, do it now. Share specific numbers: “Processing volume is down 30% this week. We expect it to recover to 80% by week four.” Vague reassurances invite micromanagement.

Days 31 to 60: When Workarounds Take Root

The second month is the most dangerous. The acute pain of the first month fades, but something subtler happens. Your team starts finding “creative solutions” to the parts of the system that feel slow or awkward.

Someone builds a tracking spreadsheet. Someone else starts emailing approvals instead of using the system workflow. A supervisor keeps a paper notebook of exceptions because “the system does not handle those well.” According to data compiled by ElectroIQ, 80% of employees use unapproved applications without IT permission. In the post-go-live context, this is not malicious. It is your team solving problems the fastest way they know how.

Each workaround is telling you something specific:

A spreadsheet tracking shipments means the system’s visibility features are not meeting the team’s needs, or the team has not been trained on them.
Manual email approvals mean the workflow engine is either misconfigured or too rigid for real-world exceptions.
Paper notebooks mean the system does not handle edge cases that happen daily.

Do not ban workarounds. Map them. Each one points to a training gap, a configuration issue, or a genuine feature limitation. The fix is different for each, and treating them all the same way wastes time and trust.

How Do You Know If It’s Growing Pains or a Real Problem?

This is the question every ops manager faces around month two. The team is still slower. Workarounds exist. Leadership is asking when things will “normalize.” How do you tell the difference between a system that needs more time and a system that is genuinely not working?

Signs it is growing pains (temporary):

Processing speed is improving week over week, even if slowly
The same questions stop coming up, replaced by new, more advanced ones
Workarounds are shrinking in scope (from full spreadsheet replacements to small gap-fillers)
Your power users are starting to prefer the new system for certain tasks

Signs it is a real problem (structural):

A core workflow requires more steps than the old system, with no benefit to offset it
The same error keeps happening because the interface leads people to the wrong action
Data from the system does not match reality, and no one trusts the numbers
Workarounds are growing, not shrinking, and new ones keep appearing
Your best people (not just the resistant ones) are frustrated

If you are seeing structural signs, escalate with specifics. “The shipment status workflow requires 11 clicks where the old system needed 4, and we have found no way to reduce it” is actionable. “The team does not like the new system” is not.

What to Measure in the First 90 Days

Most organizations track the wrong things after go-live. They measure system uptime, login counts, and training completion rates. These tell you whether people can access the system, not whether the system is working for your operations.

Measure these instead:

Task completion time. Pick 5 core processes and time them weekly. You want to see a downward trend, even if the absolute numbers are still above the old baseline.
Error and rework rate. Track how many transactions need correction. This should peak in weeks 2-3 and decline steadily after.
Workaround count. Literally count the parallel systems, side spreadsheets, and manual processes your team is maintaining. This number should shrink by month three.
Questions per week by topic. If the same questions keep coming up, your training materials need updating. If new questions emerge, your team is progressing to more advanced usage.
Time to exception resolution. When something goes wrong (and it will), how long does it take to fix? This tells you whether your support channels are working.

Plot these weekly. Share them with your team and with leadership. A team that is 40% slower in week one but improving 5% per week is on track. A team that is 20% slower in week one and flat is not.

Five Things Ops Managers Can Control After Go-Live

You cannot control the software. You cannot control how fast the vendor responds to your tickets. You cannot control whether leadership gives you more runway. But you can control these five things, and they make a real difference in whether your team gets through.

1. The daily standup (first 30 days only). A 10-minute morning check-in where the team surfaces blockers. Not a status meeting, not a complaints session. “What is stopping you from getting your work done today?” Keep it short. Drop it after month one unless the team asks to keep it.

2. The “one new thing” rule. Each week, teach the team one new capability of the system that makes their life easier. Not a training dump. One thing. “Here is how to set up a saved filter so you do not have to search every time.” Small wins build momentum.

3. The workaround review. Every two weeks, review the active workarounds with your team. For each one, decide: is this a training gap (fix with coaching), a configuration issue (submit a change request), or a genuine limitation (accept or escalate)? Then act on it.

4. The feedback channel to IT. Your team needs a clear, fast way to report issues that is not “email the IT director.” A shared channel, a simple form, anything that gets issues logged and acknowledged within 24 hours. Silence breeds frustration faster than bugs do.

5. The 90-day retrospective. At the end of 90 days, run a structured review. What is better than the old system? What is worse? What workarounds still exist and why? This gives you concrete data for a conversation with leadership about what comes next.

The Mistakes That Turn Growing Pains Into Permanent Problems

Some ops managers unintentionally extend the painful period. Watch for these patterns:

Running the old system “just in case.” Parallel systems feel safe, but they give your team a reason not to commit to the new one. If everyone knows they can fall back, no one fully switches. Set a cutoff date and stick to it.
Waiting for the vendor to fix everything. Your configuration requests will take weeks. Your feature requests might take months. Adjust your processes to work within the system as it is today, then improve incrementally.
Ignoring the quiet resisters. The loud complaints get attention. But the people who silently stopped using the system and went back to their old methods are the bigger risk. Check usage data, not just satisfaction surveys.
Over-communicating the vision, under-communicating the practical. Your team does not need another email about “the long-term benefits of digital transformation.” They need to know how to process a return in the new system without losing 20 minutes.

Frequently Asked Questions

How long does it take to reach full productivity after a system go-live?

Most operations teams reach 80% of pre-go-live productivity within 4 to 6 weeks and full productivity within 3 to 4 months. Complex implementations with multiple integrated modules can take 6 months or longer. The timeline depends heavily on the quality of training, the complexity of workflows, and how actively management supports the transition.

What is a normal productivity drop after implementing new software?

A 20% to 40% productivity dip in the first two weeks is typical. Teams processing transactions, managing workflows, or handling documents will feel this most acutely. The drop should narrow each week. If productivity has not improved measurably by week four, investigate whether the issue is training, configuration, or a fundamental workflow problem.

Should you run old and new systems in parallel after go-live?

Parallel running should be limited to a defined period, typically 2 to 4 weeks, and only for critical processes where data accuracy must be verified. Indefinite parallel running is one of the most common reasons teams fail to adopt the new system. When the old system remains available, resistant users default back to it, and adoption stalls.

When should you escalate post-go-live issues to leadership?

Escalate when you have specific data showing a structural problem rather than a learning curve. “Task X takes three times longer and we have found no configuration fix after two weeks of working with IT” is worth escalating. General frustration is not. Bring the issue log, the trend data, and a specific ask.

What are the biggest risks in the first 90 days after go-live?

The three biggest risks are unmanaged workaround growth (teams building permanent parallel processes), silent disengagement (users who stop using the system without saying anything), and loss of leadership patience (executives who expect immediate ROI and pull support too early). All three are manageable with structured communication and consistent measurement.

How Tier2 Keel and Tier2 Cargo Support the Post-Go-Live Period

The challenges described above are ones we have seen across hundreds of implementations over 11 years of building and deploying business systems. Tier2 products are designed with the post-go-live period in mind.

Both Tier2 Keel and Tier2 Cargo include guided workflows that reduce the “click count” problem. Instead of requiring users to navigate complex menus, the system walks them through each process step by step. This shortens the learning curve for new users and reduces the error rate that drives frustration in the first month.

The built-in dashboards give ops managers the visibility metrics discussed earlier, such as task completion time and exception rates, without requiring custom report builds. When your team can see their own progress improving week over week, the motivation to push through the dip increases.

For teams transitioning from spreadsheet-heavy workflows, Pluto lets users ask questions in plain language, bridging the gap between what they knew how to find in spreadsheets and what the system tracks for them.

Book a walkthrough to see how this works in practice.

What Happens After Day 90

The 90-day mark is not a finish line. It is the point where you should have enough data to make clear-eyed decisions about what is working and what needs to change. The ops managers who navigate this period best treat it as a project with its own milestones, not something that should just “settle down on its own.”

Your team got through the hardest part. The next step is turning what you learned in those 90 days into the improvements that make the investment pay off.