4 Steps to Mitigating Risk in your Teams Contact Centre Migration
With Teams adoption fast outpacing all other UC and collaboration platforms, more and more businesses are looking seriously at its feasibility for their own needs. If you’re one of them, DON’T leave your contact centre behind! A Teams environment adds huge benefits to the contact centre, arguably even more than the rest of your business, so this is worth exploring.
- This Whitepaper by Metrigy (formerly Nemertes) looks at the benefits of providing collaboration for your contact centre team: Team Collaboration in the Contact Centre
If you’re already thinking about migrating your contact centre to Teams, and seeking guidance on keeping down your risk, read on!
1. Define the Project Deliverables – And Deliverers
In other words, your first step is to identify what exactly has to be done, and who is going to do it.
This considers things like some of the following:
Platform and Solution differences
An important piece of defining the deliverables in the project is identifying the operational and feature differences between the current and new platforms and solutions. Basically, you need to understand anything that could trip people up (perhaps because an essential operation will need to be performed differently or an essential outcome is changed), as well as anything new that could add value to the users or the organisation, if activated. It also ensures that expectations are uncovered so they can be met or – if necessary – reset.
The best way to approach this is to talk to these key players:
- Your contact centre team – discover the most critical features and daily activities, along with the most critical business outcomes
- Your Teams provider – establish whether any of the items you’ve discovered in #1 above will be impacted in any way with the new platform
- Your contact centre provider – make sure that all the items mentioned in #1 are achievable with the solution that is being deployed with Teams. Keep in mind that the Teams contact centre solution could be a new solution entirely to the organisation, or perhaps simply a later version than the one previously in place; it is highly likely that — even if it’s the same solution that was used before the migration — some aspects will work a little differently with Teams. Your contact centre provider should be able to guide you on the differences you can expect.
ALSO, talking to the same group:
- Uncover what new features the contact centre are most looking forward to with the migration.
- Confirm with your Teams provider and/or contact centre provider that these are in fact going to be available in the new deployment. If not, then all parties need to look into this more closely and either reset expectations or change plans to accommodate necessary items. It is not ideal, but still a lot better to find out and correct course before the migration.
- Also ask the two providers about any new features NOT mentioned that will be available, that they think could be of interest and value to the contact centre and the business and should be discussed.
Programming the SBC (Session Border Controller)
For many deployments (depending on the contact centre solution) the SBC will need to be programmed to allow Teams to work with the contact centre solution. This needs to be performed by whoever manages the SBC, either the organisation who is migrating, or their Microsoft Integrator (most likely this will be the new Teams provider also). This is an area that has the potential to fly under the radar.
Teams programming
Like the above, programming of the Teams platform is something that can fall between players: the deploying organisation may execute all day-to-day Teams programming but assume the Integrator or contact centre solution provider will take care of the tasks for this specific project. Even if your PBX vendor previously did your “adds, moves, changes” on your old phone system, they may not automatically take over your Teams setup for calling queues (hunt groups) or non-contact centre related programming unless it’s stated specifically in your migration project order. You will need to itemise and assign owners to each of the tasks required to ensure there are no oversights, for example: creating the users in Teams, setting them up with direct dial numbers, setting up any call routing for Teams call queues (these replace legacy PBX hunt groups or response groups) and so on.
- Check out the first of the Microsoft Teams Tech Clinic webinar series on demand from Enghouse: How does an Enghouse contact centre work with Microsoft Teams?
Equipment
Another area to look at is whether there any functions where equipment must be upgraded, or new equipment purchased. For example, organisations moving from a legacy PBX environment will usually be looking at new Teams-capable headsets, while a new contact centre solution may offer a dashboard suitable to display centrally on a large screen in the contact centre — and so on.
Training
We will touch more on training later in this blog, but at this point it’s important to identify the training tasks that are required, and who will perform these – whether they will be offered by the provider, designed as ‘train the trainer’, or be self-driven by users. Even if the last, they will need to be assigned an owner to ensure they are carried out.
2. Prepare
Preparing for this project means setting out a comprehensive migration plan, with tasks and responsibilities
Be aware that the contact centre migration needs to be a separate plan to the Teams migration, which is why it’s important to separately list the SBC and Teams programming again as new items in the contact centre plan, otherwise this work will be assumed to be taken care of already. Make sure you receive this separate plan from your contact centre provider.
The other reason it needs to be separate is so that the stages are entirely separated, which we will cover in our next important step below.
Review the plan with your provider and your contact centre management to ensure there are no surprises on either side. As mentioned above, the contact centre provider needs to fully understand the organisation’s expectations so that it can deliver these, or reset them ahead of the migration. Equally importantly, the organisation itself needs to understand the possibilities of the new platform and solution, so that it has the opportunity to develop and expand its capabilities as a CX provider.
3. Establish the Platform Separately, FIRST
While this is step is equally critical to the others, it’s one that is far too often dismissed as either less important or simply not feasible.
Please do not dismiss this item… with all the experience that Enghouse has in this area; trust us when we say that this is the most common area of risk for any migration!
Consider a new lock that operates with a latch or a key. You would always check that the simple latch mechanism works first before testing the key. Even though each can fail, the key cannot possibly work unless the lock itself is operational, so that needs to be the first test. Your Teams platform is the lock that needs to function efficiently and independently before you add the next layer.
Working with customers on thousands of contact centre deployments around the world, we understand the pain points of any new system. Anything that can’t immediately be fixed is clearly more painful than something that can quickly be diagnosed and resolved. Therefore, one of the biggest frustrations if something goes wrong is when it cannot easily be diagnosed, because this naturally delays the resolution.
This is the risk whenever you deploy integrated solutions and strike an issue: where does the problem actually lie? Is it on the platform or is it the next layer of application? For example in a Teams deployment, issues that manifest with network latency or with the SBC could equally appear to be problems with call delivery or call recording. If the first two have been already demonstrated to be trouble free before the contact centre solution gets added, then we are already confident the platform is performing correctly, and know we have to look at the next layer.
On the other hand, without this surety, the complexity of the issue is instantly magnified, and the delay before resolution increased. Part of the complexity is that you will have two providers (the Teams integrator and the contact centre provider) each needing to prove their piece is working correctly. Whereas both providers will certainly cooperate in the customer’s best interest, it’s fair to say that each will naturally believe it is the other, and a lot of time can be wasted trouble-shooting the wrong software, ultimately delaying fault resolution. It’s simply much quicker and easier when you know exactly where the problem lies.
So, to eliminate this challenge, just deploy the software separately. Install the bottom layer, in this case the Teams platform, for a pilot group of users first, and ensure it is working properly with call control the essential function. Your contact centre provider will be able to give you a set of use cases to check. These are essential functions of the platform once it ultimately operates with the contact centre solution, that can be tested separately ahead of the installation. These will help you feel confident that it will perform correctly once the next layer is added.
4. Have your Contact Centre Users Test before Go-Live
Once the contact centre solution is installed, the ONLY people who can really ensure that the functions are operating as expected are the actual contact centre users. This is called UAT or User Acceptance Testing and is a key part of any new system project.
If you’re an IT expert it can be easy to overlook your contact centre staff as less technical — but remember it’s not actually technical expertise that’s needed for this. What you need is for your test users to go through and methodically try to perform all the actions they use each day as part of their customer interaction handling.
Obtain a functional test set from your contact centre provider. Examples might be:
- Do all methods of call hand-off work as expected, from start to finish?
- Can agents pause a call the way they’re used to?
- Can they conference, consult, get assistance, intrude, and more?
- Is there more than one way of handling a call, and are they all covered?
First, make sure your users are familiar and reasonably comfortable with their new tools so that even if the operation is different, they understand the steps that should be used to achieve what they need. The outcome is a double benefit as it allows you to familiarise key staff with the system ahead of go-live. If you choose the right staff to perform the UAT and communicate the task appropriately, then you’ll have users who are already invested and can assist others once the rest start to come onboard.
Another important point is that the business needs to invest in the UAT. This means managers should be allowing the appointed UA testers the time required to do the testing, without putting pressure on them to do their usual job as well if that is not feasible.
Finally, underlying all four steps outlined above is one key requirement: Communication. Do not underestimate either the value of good communication or the fallout of bad communication in the organisation!
For a clear summary of this content, check out our eBook: Checklist: 4 Steps to Mitigating Risk in your Microsoft Teams Contact Centre Migration
You can also watch the webinar on demand: Things to consider when migrating your contact centre to Microsoft Teams
Contact us to find out more about enabling your contact centre at helloAPAC@enghouse.com
MORE QUESTIONS?
