There are significant operational and financial benefits from deploying a UC service delivery and management platform that overarches the full lifecycle of a UC Platform. By way of example, a typical UC design, deployment and administration set of processes that many companies are operating under today would follow the experience similar to that described below:

  • A company wishing to deploy UC will typically engage a Systems Integrator to design and then deploy their IP telephony and UC infrastructure. This will be a discrete project, with a clear set of deliverables – a design, head-end build, testing, documentation, training, etc. The phone and service rollout will then be a defined project with 3rd party technicians to deploy sites and phones, taking several weeks, months, or years, depending on the size of the project and various tools may be used by the SI team.
  • The design of the platform will have been created from scratch, and may or may not have been implemented correctly. It depends on whether the SI’s engineers followed the design or introduced human error or some individual preference.
  • Data collection is laborious and it’s difficult to avoid data slippage due to the delay between data collection and site transformation
  • Once complete, the whole platform will then be handed over to the Day-2 team (internal or external) and the SI moves on to their next job and plays no role in the ongoing operation of the platform.
  • Regardless of the amount of training, the Day-2 team has little direct experience with the platform and has to come up a steep learning curve. During this initial learning period, staffing levels have to accommodate a high rate of service tickets from end-users who are also coming to terms with the new system.
  • Service levels are low at precisely the time when users are creating their first impressions of the new platform.
  • Once time passes, a service upgrade may be required or a new company merger requires a new Day-1 implementation. In this instance, the SI is invited back to perform the upgrade, but this team is rarely the same people who deployed the initial platform and they need to completely re-learn the design and configuration.

Now let’s look at the same process, but from the UC lifecycle management perspective, where a lifecycle management platform is utilized:

  • Pre-tested, integrated design templates will have been used by the SI, so the platform design will not be completely new. Also, the design will have been implemented correctly, because there is far less human involvement in the physical configuration due to Day-1 automation.
  • Rather than waiting until the end of the project, Day-2 teams can get involved in site transformation accessing the real-time Day-1 data, so the whole Day-1 to Day-2 transition is much smoother.
  • The Day-2 transfer of information requirements are less and the learning curve is greatly reduced. Service tickets from end-users who are coming to terms with the new system are also reduced due to self-care capabilities.
  • Day-2 service levels are high at precisely the time when users are creating their first impressions of the new platform.
  • SI teams who perform future service upgrade do not need to completely re-learn the design and configuration of the platform, as they can access the real-time (i.e. 100% accurate) service configuration centrally.

By having a single tool that manages every stage of the UC platform lifecycle, the deployment process is easier, service levels are significantly higher and the change of error is far less. All of which leads to a much lower total lower cost of ownership.