I’ve had some conversations with customers that has me reconsidering Teams Phone System adoption. The TL:DR version? You’re doing it wrong. And it’s my fault, because the way I told you is wrong.
Teams Phone System Defined
Let’s start with a refresher before we dive into Teams Phone System adoption. What is this Teams Phone System? You can read the answer here if you have four minutes. In a nutshell, Teams Phone System is what you use to turn Teams into your everyday phone system (hence the catchy name!) You can use Teams out of the box (where’d I put that SaaS box anyway? LOL) to conduct calling between people inside your organization. No additional technical pieces are needed. You need Teams Phone System if you want to call out to the Public Switched Telephone Network (PSTN). As I like to say, you can use Teams from Day One to call your Boss. But you need Teams Phone System if you want to call the caterer and order lunch for your meeting.
The Time-Tested Method for Running a Technology Pilot
Here’s how we’ve all been trained to roll out a new technology.
- Set up a pilot test.
- Recruit a few users—technical people, opinion leaders or a mix of the two—to participate in the project.
- Set up a test environment where the pilot users can try out the new service/application. Make sure the test environment doesn’t interfere with the production environment.
- Run the pilot for a while and document what we learned. Fix anything that broke along the way and document that as well.
- Expand the pilot with more participants, if you see additional technical risk or you need to generate more organizational buy-in.
- Repeat the find-fix-document process.
- Set up the service/application on your production network. Add all the users.
- Provide some training, send out an announcement, buy cupcakes for the team.
If you just want to do some testing during the Teams Phone System pilot, this approach works great. You set up a new phone number, use it to make some calls out the PSTN (hello, caterer!), and have some folks call you on your new number.
However, the point of a Teams Phone System pilot is to get people comfortable with the new system. You recognize that Teams Phone System adoption is about more than rolling out some technology; you must get people comfortable with it as well. And here is where things fall apart. (Random Chinua Achebe reference here.)
The Problem Handling Teams Phone System Adoption Like Other Rollouts
Here’s the problem with using this method to manage Teams Phone System adoption: new phone numbers. You want to run the Teams Phone System pilot in parallel with your “production” phone system. In order to do that, you must assign new phone numbers to the pilot participants. This way, people continue to use their current phone numbers and have a new phone number that they use just for the pilot.
But no one will want to use their new-but-temporary pilot phone number. The pilot dies a slow death from lack of use, and you put the phone system decision on the shelf for the next budget year.
Can you imagine sending out this message?
Hi, this is Dan. We’re testing out a new phone system, so for the next six weeks don’t call me on my regular number (although it will still work). Instead, call me on this other number. Be sure to update my information in the six places where my contact is stored in your organization! Oh, and after six weeks make sure you update my information again with my new (but actually old) phone number.
No one wants to do this. It’s the same as when your organization started using Office 365 and you hadn’t added your organization’s email domain to the service. So, you had to use an email address like email@example.com. Truth be told, the pain of even considering that made you get your @yourorganization.com email domain verified as quickly as possible.
Ditch the Pilot and Go for a Controlled Introduction
We know that people have a great attachment to their phone numbers. How do we facilitate Teams Phone System adoption in this case? Let’s skip the pilot process and go for a controlled introduction of Teams Phone System. How would that work?
- Again, start with a couple of users.
- Set up Teams Phone System (see my post here about that)
- Port the phone numbers for those users to Teams. There’s some time involved (this is the phone company we’re talking about) and you must fill out the form correctly. But mostly, you just wait for the number portability wheels to turn.
- Make sure the pilot users’ phones will work with Teams Phone System (see my rant in the link above). You may need to update phone firmware, or worst case buy a new phone.
- Update some of the current phone system’s features so they still work with the users who are now on Teams Phone System. For instance, if you have an auto attendant set up, you may need to modify the number that’s entered to call a user, when the caller selects a user to call.
- Run through the test-fix-document process.
- Add more users.
- Train as needed.
Why a Controlled Introduction Will Work
Why does this Teams Phone System adoption approach work? Because users get to just do their work. They aren’t being asked to play in some pilot “sandbox” that’s safe but irrelevant to their daily lives.
This Teams Phone System adoption approach also works because people experience Teams Phone System firsthand. There’s no handwringing about whether features will work and how they’ll work and if people will like the way they work. You’ll have to address these questions as part of bringing a user onto Teams Phone System. But the context will be different: “how do we make this work?” vs. “should we try to make this work?”
Eventually, you add the last users to Teams Phone System. At this point, Teams Phone System adoption is complete.
Except for the cupcakes. Be sure to buy those!
I’m the VP of Global Services at CGNET. I manage our Cybersecurity and Cloud Services businesses. I also provide consulting and handle a lot of project management. I wear a lot of hats. Professionally, I’m a builder of businesses. Outside of work, I’m a hobby farmer, chef, skier, dog walker, jokester, woodworker, structuralist, husband and father.