Resource Center

Whitepaper 5: Moving to Microsoft Teams telephony

How to run a successful proof of concept

LoopUp whitepaper 5 overview image

Contents

Moving to Teams telephony is the right approach for many businesses, but some may hesitate to deploy it because they have questions about how it can meet their specific requirements or concerns over perceived obstacles that stand in the way. They need answers before they commit, and running a proof of concept as a “try-and-test” experience could be one – but not the only – way to get them.

Introduction

Teams telephony is taking off – more than 650 million calls were made using Microsoft Teams in just one month towards the end of 2020. Many organizations, especially those who were already using Teams for chat, document sharing and video calling, are thinking the same thing: it could be an ideal enterprise telephony solution for our business, putting all our communications in one place. However, as with any move to a new system, no matter how good, there can be unknowns and uncertainties.

Businesses might be wondering how they can be sure that Teams telephony will meet their needs and whether specific benefits can be delivered. They may want to “try before they buy” by running a proof of concept (POC) to assess suitability and test audio quality and the reliability of the phone service for users across the network. But a POC may or may not be the answer.

This paper explains why organizations should consider running a Teams telephony POC and how to ensure the POC is successful, as well as exploring other options to validate that Teams telephony is right for your business.

What is a proof of concept?

Running a POC is like taking a car for a test drive. Customers who are considering replacing their enterprise telephony solution with Teams can try it out for a defined period to validate that it meets their business needs. They can try out the functionality, and also check the service reliability and audio quality for users in different geographic locations with a range of telephony needs. A POC typically lasts for around one month, but it should last as long as necessary for the organization to confirm that Teams telephony will meet their needs. A POC provides fully-operational Teams telephony for a group of test users. If an organization already uses Teams, then telephony can be provided to existing user accounts. If not, then a new instance of Teams with new user accounts can be created specifically for the purpose of the POC. The existing enterprise telephony solution is retained for the rest of the organization.

The aim of a POC is to provide assurance that whatever aspect of Teams telephony you want to test will work, and that any perceived “blockers” can be resolved prior to deployment.

POCs can also flag up new issues to address prior to the roll out of Teams telephony. This can be helpful in itself, to ensure that unforeseen impediments are removed well in advance of a larger deployment.

What other validation options are there?

A POC is a great way to validate whether Teams telephony will work in the way you want it to and that it is the right solution for your business, but there are alternatives that may be worth considering:

A demo: Your questions may be answered and any reservations addressed simply by having a product demonstration and speaking with a specialist.

They can spend a few hours running you through key aspects of Teams telephony, showing you how it works and focusing on specific areas of interest or concern. Often businesses find that what they consider to be challenges unique to them, are actually common issues that are easily overcome just by speaking to an expert adviser with experience in the field.

A pilot: If you are ready to go ahead with implementing Teams telephony, you may decide to do a pilot, which is essentially the first stage of a full roll out. Whereas a POC is a temporary configuration for Teams telephony to be tested and tried, a pilot is the start of a full deployment where a select group will start using it for before the rest of the business, so that any issues can be identified and addressed early on.

Three different validation options

Demo

  • Having Teams telephony demonstrated to you
  • Initial fact-finding, no commitment
  • Time required: 1-2 hours

Proof of concept

  • Trying Teams telephony for yourself
  • Temporary, disposable environment
  • Deeper-dive fact-finding, no commitment
  • Time required: typically 4-6 weeks

Pilot

  • First phase of live rollout
  • Test period to modify approach for delivering a permanent solution
  • Committed to deploying Teams telephony
  • Time required: typically 4-8 weeks

Where does a proof of concept sit within the decision-making process?

Step 1: Consider if Teams telephony is a potential solution

In order to decide in which direction the organization should go in terms of new telephony technologies, it is necessary to conduct some basic information gathering. For example, ask a managed service provider for a demo or send them a Request for Information (RFI). An RFI is a less formal process than a Request for Proposal (RFP) – it’s typically a series of questions that allows a potential buyer to learn more about the solutions provided by a service provider, and to structure an RFP properly if the potential buyer decides to go down that route.

Step 2: Identify and test perceived blockers to Teams telephony

Consult a provider about any perceived obstacles you think might stand in the way of a successful deployment of Teams telephony. Common examples of perceived blockers are outlined later in this guide. The provider should be able to tell you how significant these issues are, whether they are common or specific to you and suggest potential solutions. They can advise on whether running a POC is the best way to address them, or whether a more in-depth, extended demo might be enough to allay your concerns.

Step 3: Select a suitable vendor for managed services

Issue a Request for Proposal (RFP) to set out the scope of requirements and enable vendors who provide managed services to advise on how they would meet those requirements. As part of the RFP process, you will need to select a well-rounded internal team to inform the project and define goals, invite vendors to bid, develop scoring criteria to evaluate tenders, and review supplier contracts before awarding the work. A POC may already have provided helpful insight towards the RFP process, for instance by highlighting specific requirements that you as a customer will need from a service provider, or by helping to prioritize service elements in a scoring matrix.

Step 4: Plan deployment, with pilot if required

An initial pilot may be advisable, potentially as part of a phased roll out, to address any remaining issues prior to a full deployment. For example, there may be further actions required to optimize internal networks, or user communication and training may need to be refined. The pilot might also be the time to determine device requirements, such as whether user endpoints like headsets and handsets require upgrading. It may make sense to run a pilot in a certain location or with a particular user group that has complex requirements to ensure that these can be met. A pilot can also be used to kickstart internal engagement with a select group who can then be ambassadors or champions for the change.

Common reasons to do a proof of concept

The reasons for running a Teams telephony POC typically fall into two broad areas. The first is to check that Teams telephony offers the features and functionality you need: that it is versatile, comprehensive in terms of its capabilities and designed with the needs of businesses and their end-users in mind. The second is to verify that it delivers on call quality, with clear, uninterrupted audio that is consistent and reliable for all users globally.

1. Features and functionality:

Integration with existing business processes

Businesses who have used a traditional fixed-line PBX (private branch exchange) phone system or are transitioning from Skype for Business may want to confirm that a particular feature that they require for an existing business process is also available in Teams.

For example, they may want to forward support desk calls to mobile devices out of hours. They may want to understand the options for handling calls to the main number when there are more incoming calls than people to answer them. They may want to experience how the Teams mobile app interacts with Teams on desktop, because calls will be coming through to two places at once. Or they may want to understand how to set up “hunt” groups on Teams, so that users can answer calls for their colleagues if they are unavailable.

The priority here is to validate that Teams telephony meets the business requirement, rather than replicates the exact functionality. Because Teams is cloud-based, it can do things that on-premises PBX solutions are unable to do – such as detect which devices a user has access to, or check their calendar to see if they are available.

For this reason, the adoption of Teams telephony may mean that organizations choose to redesign business processes, rather than simply to replicate the same processes with the new telephony solution. The POC is an opportunity for organizations to test this.

Integration with existing solutions and systems

A POC does not generally require changes to be made to the customer environment, but businesses may want to know that Teams can integrate seamlessly with other solutions and systems they are running. These might include call-logging software, or hardware such as desk phones or meeting room devices.

2. Audio quality and reliability:

Microsoft Phone System

Teams telephony uses Phone System, which is Microsoft’s cloud-based PBX, rather than traditional on-premises infrastructure. Organizations may want to test the quality of cloud-based telephony before they commit to rolling it out. A POC provides a more immersive experience than a demo, allowing users to get a good feel for how well Teams calling performs in real-life situations.

Internal corporate network

With Teams telephony, the first part of the call routing takes place over a business’ own corporate data network, which sends the call to Microsoft’s infrastructure. Therefore, that internal network needs to have the requisite speed and capacity to support high quality audio phone calls. When a voice call is routed over a data network, sound is converted into “packets” of data which must be delivered quickly and consistently so each person can hear the other clearly. A POC can identify any performance issues with the corporate network that need to be addressed before a more comprehensive deployment.

Managed service provider’s infrastructure

Many businesses use a managed service provider to deliver Teams telephony solutions. The service provider manages the final part of the data journey from Microsoft’s infrastructure to the call recipient. Organizations may want to use a POC to test the quality of the provider’s infrastructure, including the carriers that they use to route calls over the PSTN. In particular, organizations may want to test the quality of service provided in locations where users have experienced issues with telephony in the past.

Signposting the route to success

It’s important to note that audio quality and reliability on Teams calls is dependent on all three of these elements – Microsoft’s Phone System PBX, an organization’s own corporate network, and the service provider’s infrastructure. If there are problems during a POC, it does not necessarily demonstrate that Teams telephony is unsuitable for an organization: instead, a POC can indicate where any issues might lie, so that they can be addressed prior to deployment. The managed service provider running the POC can help you understand the issues and find ways to mitigate them.

How does a proof of concept work?

The role of a managed service provider

The managed service provider will be instrumental in setting up and overseeing the POC. At LoopUp, we help businesses identify areas for validation, advise on whether a POC is suitable, and configure the right test environment, building in different test scenarios if necessary.

We work with organizations to define success criteria at the outset to ensure that the POC delivers against what it needs to achieve – i.e. proving that Teams telephony meets the requirements of the business. During the process, we monitor progress, gathering data to analyse performance and highlight any problems to fix along the way.

And at the end of the POC period, we provide further statistics and metrics to review the process and measure success. Most importantly, we engage with the IT team and user groups to hear about their experience. We can then discuss next steps to move forward as appropriate.

How a proof of concept typically works

If an organization is using its own Teams tenancy for the telephony proof of concept, then a pre-determined user group are given new phone numbers so that they can start making and receiving calls using Teams. They can use the Teams app on their PC and on their mobile device. They may also be provided with a desk phone running Teams, if that is part of the POC. If the POC is being run on a new Teams tenancy (because the organization doesn’t use Teams, or because they don’t want to run the POC on their existing Teams tenancy), then the user group will receive new Teams user profiles and log-in details as well as phone numbers. We don’t usually port existing DDI numbers to Teams in a POC – these would remain active with the existing provider – although this can be done if required.

Businesses will require a suitable number of users to test the POC and they should be encouraged to actively participate. How many users depends on what you want to validate. With quality issues in particular, the more calls you put through, the clearer a picture you can build up, and we would suggest a minimum of 5 and a maximum of 20 users with different user profiles and in different geographic locations. Without sufficient usage, the POC will be less effective.

Once the POC is completed, the test environment will be removed and any configurations made to an organization’s own tenancy will revert back to the way they were before the POC.

Top tips

  • Identify what specific issues you want to validate and decide if a POC, a demo or a pilot is the best way to prove them
  • Agree success criteria and metrics before you start
  • Make sure the POC will receive sufficient usage – it needs to be put through its paces!
  • Be aware that quality can be harder to test than features and functionality because quality is more subjective to assess, and there are several different factors that could impact it
  • Consider investing in high quality user endpoints such as Microsoft-certified headsets for the POC if you want a realistic measure of user experience
  • Allow around 6 weeks for the POC process, including preparation, a month of user testing, a thorough review of performance, and planning for a full deployment

Summary

Organizations that are considering moving to Teams telephony should consider running a proof of concept as part of the decision-making process. A POC should determine if Teams telephony can meet the requirements of the business – with regard to features and functionality, and also audio quality and reliability.

To ensure that a POC is successful, an organization should consider what the potential blockers to effective deployment are – for example, can Teams telephony be integrated with important business processes, or will it perform in locations where service reliability has been an issue in the past. The POC can then be designed to address those specific questions.

As well as helping an organization determine if Teams telephony is right for them, a POC can also be used to prepare for a successful deployment. A reliable telephony solution is a business-critical tool, and so it needs to work perfectly for all users from day one. By running a POC with a small group of users that still have access to their existing telephony solution, any potential deployment issues can be identified and addressed (e.g., corporate network performance) before the tool is rolled out more widely.

LoopUp has run Teams telephony POCs for a diverse range of organizations around the world. Our specialists can answer any questions you may have, arrange a demo to introduce you to the product, and discuss how a POC can help you determine if Teams telephony is right for your business.

Download whitepaper

Download PDF

Additional titles in this series:

LoopUp Whitepaper
LoopUp Whitepaper
LoopUp Whitepaper
LoopUp Whitepaper
LoopUp Whitepaper
LoopUp Whitepaper
LoopUp Whitepaper
LoopUp Whitepaper

Download the PDF version

Get free RFP guide

Moving your global telephony to the cloud? Our guide can easily be rebranded and used for your next RFP.

LoopUp guide