Data Inaccuracy Blocks Voice Deployments with Microsoft Teams

Data Inaccuracy Blocks Voice Deployments with Microsoft Teams

Time and time again I come across the same old issue when customers want to use Skype for Business or Microsoft Teams for voice and they want to retire their old PBXs. That is data quality issues!

The same can be said for customers who are green and want to “light up” calling in Teams from their existing Office 365 data.

What data am I talking about? Well, the most important piece of data is the telephone number. This should be simple, but often it is not. You’d be surprised that although the end user of that phone number knows it, the majority of the systems and administration staff (IT, HR etc.) don’t.

Typically, there will be several directories used as the data source, we have AD, HR databases, PBX phonebooks, Printed Cards, or books on walls, people’s personal contacts, post-it notes. The list goes on. Yet when you look at all these data points you’ll realise that the number for Mary Smith is different across these data sources.

You see, in the PBX and VoIP world, the phone number is not personal to the user assigned it. The number is personal to the device the user is using. Think of it as a tenant and landlord situation. The mortgage company (in this case the PBX) deals with the landlord to make sure that they keep on paying their bill (the phone), while the tenant (the end user) lives in the house. Tenants change, as do people using the phone, but the landlord doesn’t tell the mortgage company because they don’t care, its information they do not need to keep the system running as designed.

What usually happens in organistions is that when a user moves, the next person just takes on the phone and number on the desk. There probably won’t even be a IT ticket for it, just the Manager saying, ah yes, use that phone.

As time goes by, change by change the data that was once accurate drifts more into irrelevance. Fundamentally, the system works, but when you come to the point of moving away from it, then you realise how much of a pickle you have found yourself in.

If you are moving to another VoIP system, then of course, it’s easier, but still trash in, trash out if you do not address the data issue. However, with a Unified Communications platform that ties a user to several communication identities e.g. E-Mail, SIP Address, Phone Number in one platform, it is absolutely necessary that you know that each of these identities is accurate for that user.

Take a situation I found myself in many times. The customer supplies the data file from their HR database of users to migrate. They affirm to me that this is the most up to date, most accurate data source to base a migration off. We analyse the VoIP system to find the relationships between the stations, set up hunt groups, shared Line appearances, team call groups etc all ready to go, and then we enable the users we believe are the owners of that number for Teams / Skype. Job done, lets all go back to the hotel for some Pizza!

The following day feeling all positive and enthusiastic because the night before went so well, we get to site. 9:45am, there is a service ticket, I am not receiving calls. 9:50am Why am I getting John’s calls, I am Matt? 09:51am Why are some phones randomly ringing together in the office?

All of a sudden we are hauled into a crisis meeting and hastily roll back the migration. The customer labels the migration a failure and offloads on to us.

The reality is quite different, the migration was a success, the process and steps worked end to end. The problem of course was the data that was supplied into the process at the beginning.

Experience has taught me that pre-project / migration data cleansing is absolutely necessary. A lot of companies will not factor that in to their migration project and when asked will be very resistant to remediation. But if it is not done, then moving to Teams will be a very poor experience.

To fix the problem, you must first understand how it has been created in the first place. Here are some of the most common factors that I have come across

  • User leaves and service ticket as part of the off-boarding process is not assigned to telecoms for decomissioning of the station assigned to the user
  • User moves within same department and number change happens without IT involvement
  • Issue with the execution of the off-boarding process where the telecoms admin does not update the station profile
  • There is no relation to users in the PBX configuration for a station by design because admins don’t want the problem of maintaining relationships to names
  • AD admins when disabling the account for (x time to infinity) do not remove the number from the telephone attributes in the object

Moving to Unified Communications enforces change to these processes and they must be enforced otherwise the business will grind to a halt. With Teams et al you cannot simply get around a miss assignment of a number, because the system will route the call straight back to the person who has been assigned that in the UC platform, regardless of any external factor that disagrees with it.

How do you fix these as a project?

Well, you have three choices that you can make with your customer

  1. The best solution is to remediate the problems at source and give you a good start of migration success. This will involve surveying the users and asking them to confirm their phone number to you. Once confirmed, you’ll need to update the source systems, but AD will be the most important one as that is what Teams will use moving forward
  2. Fix forward and move with a dataset that you collectively agree based on business analysis is the most accurate knowing that their will be problems and having a process in place to resolve those
  3. Implement green field and give as many users as the business can sustain new phone numbers and manage through change and awareness.

All options require you to keep at least AD up to date. Giving new phone numbers to users is not as taboo as people make it out to be. It can be managed if it is known ahead of migration. Some may have to keep their number, but if 80% of users could function with new numbers with no business operation impact, your migration complexity has just reduced to 20%. This means that the customer can start taking advantage of Teams for voice quicker whilst the complex scenarios are worked on.

I have run successful migrations in the past where number change has been managed through advanced communications and instructions with a clear date where the old number will cease to operate. One technique is to get the user to record a voicemail greeting to say on this date my number will change to.. as well as email footer updates etc. Its not that hard and it is more convenient to the user than IT trying to ensure quality through compromised data and getting it wrong.

Once decided on the model, ensure that operationally you fix the processes to ensure that AD is updated with MACD changes. Teams / Skype contact cards will use phone numbers (including mobile) that are extracted from the telephone attributes on the user’s object. These are synced to AzureAD and any inaccuracies will also be present there.

My closing statement here is that enabling Teams voice is really easy as long as you embrace and face the problem of data quality head on before you plan migrations. If you ignore it or dismiss it’s importance, then believe me you will feel pain at a level you have never experienced before. Untangling spaghetti is hard enough, it’s even harder when it is boiling hot!

 

One thought on “Data Inaccuracy Blocks Voice Deployments with Microsoft Teams

  1. very well said! accurate and hits the nail on the head! that’s why automated migration tools are critical… Check Univonix.com solves all the problems Mark referred to…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: