What happens when the implementation partner leaves and the real work begins. Part 1 of 3 in the Beyond Go-Live series. By Rob Jeninga, COO at Purple ยท 6 min read The project is done. Telephony is migrated and live within Microsoft Teams, the new contact center is running, and everything is performing as expected. The implementation partner has submitted the closing report. IT is back to run rate. The steering committee has moved to the next agenda item. And six months later, the contact center team is essentially working the way they always did. Handle times are unchanged. The advanced features haven't been touched. Supervisors have dashboards they rarely open. Agents are using a handful of features on a platform built to offer far more. I see this enough that it no longer surprises me. It still frustrates me. Because this outcome was almost always avoidable. The go-live illusion Projects are expensive. They take time, organizational energy, and tolerance for disruption. By the time go-live arrives, everyone wants the pain to end. The instinct is to close the chapter, return to business as usual, and move attention to whatever comes next. That instinct is understandable. What it misses is that go-live is not the finish line. It is the starting point for the work that actually matters. Before go-live, the platform is held together by a project team. After go-live, it belongs to the people who use it every day: agents, supervisors, IT teams, CX leaders. That transfer is where transformation either happens or doesn't. And in most organizations, nobody has planned for it. The business case built on a false assumption Every investment in a contact center or cloud telephony platform is justified by expected outcomes: better customer experience, lower cost per interaction, improved agent productivity, reduced infrastructure costs. None of those outcomes are delivered by the technology. They are delivered by people using the technology well. Which means the entire business case depends on adoption. And yet adoption, in most projects, gets a fraction of the budget. Sometimes none at all. It is treated as something that will happen naturally once the platform is live, a side effect of training and a go-live communication plan. In practice, nine out of ten contact center and IT projects treat adoption this way. Almost every IT project is defined by an IT goal: migrate the platform, replace the legacy system, go live on a new solution. But the IT goal is rarely the actual objective. It is a driver for something else entirely: a better customer experience, a more productive team, a stronger operation. The IT milestone gets the budget, the project plan, and the delivery date. The actual ambition rarely gets the same investment. I see this in almost every project. Organizations arrive with genuine intentions and a real sense that something needs to change. What most lack is the strategic clarity to define what success means beyond go-live, and the willingness to invest in reaching it once the platform is live. I've seen organizations with detailed budgets for platform, implementation, migration, and support contract, and nothing allocated for the one thing that was supposed to make all of it work. Three months after go-live, their first-call resolution rate was lower than before the project. The platform was performing exactly as designed. The adoption hadn't happened. Fixing it required six more months of focused work: coaching, feedback loops, ownership conversations, and leadership attention that had been absent since the project closed. All of that could have been planned from the start. I have seen this enough times to say it with confidence: the gap between what organizations invest in and what they actually get from a contact center transformation is almost never a technology problem. It is an adoption problem. And it is almost always one that could have been planned for. Rob Jeninga, COO at Purple What drift looks like in practice The pattern is consistent. In the weeks after go-live, teams get through their day using the platform at a basic level. Then, gradually, old habits reassert themselves. Agents work around features they don't understand. Supervisors manage performance using the same instincts they had before, because nobody has shown them a better way. IT focuses on keeping things running. Nobody asks whether the organization is actually improving, because the project officially ended and the question no longer has a home. What I hear most often from teams post-go-live is some version of the same story: the project team moved to the next engagement, IT went back to run rate, and suddenly the organization was on its own with the platform, figuring it out. Contact center platforms come loaded with capabilities that do not activate without genuine adoption behind them. Advanced routing, real-time transcription, sentiment analysis, omnichannel capabilities, and integrations with other applications: none of these deliver value to a team that hasn't built the platform fluency to use them. The features are there. The investment was made. Adoption is what determines whether organizations ever actually reach them. The challenge compounds further when AI capabilities enter the picture. An organization that has not yet mastered the core functionality of its contact center platform is in no position to effectively leverage AI in customer contact. That requires a level of process control, data quality, and platform maturity that simply does not exist when basic adoption has not happened. You cannot build toward ambitious goals from a foundation you have not yet built. If you do not control and understand your own processes, how can you be expected to hand them to AI? And the technology does not stand still while organizations catch up. New features and capabilities are released continuously. Every release that an unprepared organization cannot yet absorb widens the gap between what the platform can do and what the team actually does. Change is not a journey from one fixed point to another. It is constant. Organizations that treat adoption as a one-time event will always find themselves running behind it. What this costs Organizations measure project success by delivery: on time, on budget, systems working. Those are reasonable measures for a project. They are not sufficient measures for a transformation. The outcomes that justified the investment appear later, if they appear at all. When handle times haven't moved, when customer satisfaction scores are flat, when the expected productivity gains never show up in the data: those are the visible signs of an adoption gap. There is another cost that is harder to put a number on: service quality. When agents work around features they do not understand, when supervisors manage without the data the platform makes available, and when routing and escalation paths remain on defaults no one has revisited, quality erodes. Not in one sudden drop, but steadily. In the texture of customer interactions. In service quality metrics that plateau rather than improve. In agent confidence that never grows beyond the minimum required to get through the day. Quality is where technology and the human side of change connect. The platform was built to improve it. Adoption is the mechanism that makes that possible. When adoption fails, technology sits on one side and the people who should be using it sit on the other. The bridge between them was never built. It is also worth noting that these dynamics are not exclusive to contact center or cloud telephony projects. Any significant IT transformation faces the same adoption gap. The technology changes faster than behaviors do, and the gap between delivery and realized value is almost always a people problem, not a technical one. In contact center environments, the cost is most immediately visible in customer outcomes. But if you recognize this pattern in other projects across your organization, the underlying challenge is the same. Adoption starts at day one The organizations that get this right plan for it from the start. Adoption is not bolted onto the end of a project. It runs alongside it: understanding the people who will use the platform, building readiness before go-live, designing the feedback loops and reinforcement mechanisms that sustain new behaviors after go-live, and establishing ownership that keeps the effort alive when the project officially closes. That requires investment. It requires a named owner beyond the project sponsor, one who is accountable for outcomes rather than delivery. And it requires treating adoption not as a phase with an end date, but as an ongoing practice that scales alongside the platform itself. Go-live delivers the technology. What the organization does from that moment determines whether the actual ambition that drove the investment is ever realized. Part 1 of 3 in the Beyond Go-Live series. Part 2 looks at the behavioral science behind why change sticks in some teams and fails in others. Part 3 covers how to build an adoption program that actually holds. Frequently asked questions What is the adoption gap in a contact center project? The adoption gap is the space between technology delivery and genuine behavioral change. An organization can go live on time and on budget, and still fail to realize the outcomes the investment was supposed to produce, because users continue working the way they did before. The gap appears when adoption is treated as a side effect of training rather than a distinct workstream that requires planning, ownership, and sustained attention. Why do contact center projects fail to deliver ROI after go-live? Contact center project ROI depends on people using the technology well, not just on the technology being live. When adoption is not planned for, users default to old habits, advanced features go unused, and the improvements in CX, productivity, and service quality that justified the budget never materialize. The business case was built on behavioral change. If that change does not happen, the case does not close. How long does it take to see results from a contact center implementation? Technology goes live in weeks or months. Behavioral change takes longer. Organizations that invest properly in adoption typically see early signals within 60 to 100 days. ROI metrics and quality improvements typically move at the three to six month mark, assuming adoption is actively managed. Advanced features and AI capabilities take longer still, as they require platform maturity that only develops once the basics are genuinely adopted. Does this apply to IT projects beyond contact center and cloud telephony? Yes. The adoption gap described here exists in any significant IT transformation. The technology changes faster than behaviors do, and most organizations invest heavily in delivery while underinvesting in the change effort required to realize the value. In contact center environments specifically, the cost of poor adoption is most immediately visible in customer outcomes, making it a particularly high-stakes example of a universal challenge. What should organizations plan for after contact center go-live? After go-live, organizations should have a named adoption owner, defined behavioral success criteria, feedback and reinforcement mechanisms that sustain new behaviors, and a clear plan for the first 100 days. Adoption is not a handover. It is a continuation of the change effort under different ownership, and it does not end when the platform is stable. About the author Rob Jeninga is COO of Purple, where he leads project delivery, customer success, and the adoption practice for cloud telephony and contact center implementations. Over fifteen years of leading global IT programs and projects, he has worked across enterprises and mid-sized organizations, seeing firsthand that the projects actively pursuing adoption are the ones that go from good to great. The human side of change is essential, easily overlooked, and consistently the hardest part. It is also where the magic happens. His goal is always the result beyond the milestone: the kind that carries real weight and impact long after the project has closed.