Step 3 - The Solution Design
In our blog series, we pretty much have the prerequisites out of the way, and it is time to start executing for the customer. When it comes to a design, that means taking the project requirements as defined by the customer, performing data collection (using templates) and creating a design document with the results of that data collection.
Find all 9 steps of UCaaS project HERE
When implemented accurately, the design document should reflect those requirements and be something that an engineer can use to build and implement the UCaaS IPBX.
The main components of the solution design
- The LOA is used to identify any DID (Direct Inward Dial) numbers that need to be ported form one carrier to another as part of the project. Identifying if numbers meet this requirement is critical if you don’t want to arrive at the go-live date and find that there are no live DIDs to connect to your shiny new UCaaS system. This requires close coordination with your incumbent carrier and your Partner to get the numbers and timing correct. The caution here is that there can be long lead times based on the quantity of numbers being ported and the capabilities of the carriers.
- The Responsible Org document provides the method by which your toll-free numbers go through the porting process. The guidelines and cautions are similar. The main difference is that a typical company has a lot fewer toll-free numbers than DID’s.
- Network Assessment – This area is frequently missed or taken for granted. Having a network in place that is capable of supporting VOIP is a must. That means performing some type of VOIP readiness test, promoting VOIP network best practices to your customer, and incorporating that information and data into your design to ensure the network can sustain VOIP traffic. Voice VLAN’s and SDWAN are also welcome to the party.
- Configuration Documents – This includes all the site and user data, like phone numbers and extension information, as well as any of the work group, hunt group and other customizations that are intended for the IPBX.
- Announcement and Scripting – This information is used to build the auto-attendant and the IVR announcements that customers interact with initially. These scripts can be simple or quite complex, depending on the customer and how the system routes calls and runs queues. It is important to nail this one, as one of the most typical issues customers define is that a system does not “look, feel, and sound” like the legacy system that preceded it.