Getting the Most Out of Your Collaboration Professional Services Engagement
Collaboration engagements have some unique elements that can cause issues if not handled correctly. Provider relationships, statements of work, and internal responsibilities are all areas of potential problems or confusion. Handling these matters incorrectly can lead to frustration, additional costs, and a less than optimal experience. Today, my goal is to clarify some details surround collaboration engagement so that your next collaboration project goes as smoothly as possible.
The relationship of the customer with the provider and everything that goes along with that is one of the key elements for a successful collaboration deployment. Typically, the professional services vendor has a relationship with the customer and not the telecommunications provider that gives the customer access to the public phone network. This means that the customer has to be involved with any level of coordination involving the provider. This can be a huge roadblock for scheduling. It may only take the vendor a week to install and configure all the new phones and settings for a site, but moving the numbers to new circuits could take weeks to schedule with the telecommunications provider. The best strategy when planning is to back into the date needed. The provider should be able to work back from the date you provide to let you know when various things need to be ordered to meet the date you need. It’s best to start thinking about this as soon as possible to avoid delays. Another key thing the provider should be able to provide is a listing of any numbers associated with the circuit or location. This is especially important if you don’t have that information, or are unsure of its completeness. The vendor can only setup the system for the numbers that you provide. If that list is incomplete, the correct numbers may not be configured, which can cause additional issues and delays.
We all know that statements of work (SOW) are important with any professional services agreement. However, with collaboration they become even more significant. A SOW for a switch implementation might be to simply rack the switch and configure the layer 2 switch. That would probably be enough information to make sure that the vendor and the customer were on the same page in terms of the work being done. With collaboration, it is often not so straight forward. A SOW that said something along the lines of ‘install and configure 20 phones and configure site’ could lead to a lot of misunderstandings. First off, ‘configure phones’ could entail multiple tasks that could take a lot of time. For instance, the phones could be configured with the basic information of a directory number and a user, and the phones could take calls. One the other hand, the phones could require custom speed dial buttons and user directories. This could significantly change the amount of time needed per phone. Beyond that, ‘configure the site’ is also not straight forward. This could mean, configure a site so that the phones can take inbound calls and make outbound calls. It could also mean configure a site with an automated attendant that will route callers to various groups within the site. The second configuration is much more time consuming. The key here is to make sure the SOW covers anything you need the vendor to implement. A SOW doesn’t need to spell out every step of the automated attendant confirmation, but it does need to show that an automated attendant will be installed and include basic information on how it will operate.
The final consideration for a successful deployment is how much internal IT time will be needed. You, as the end customer, control information about your existing systems. Depending on the complexity of the deployment, the collaboration solution may need to integrate with many of those systems. Email, SQL databases, VMWare environment and Active Directory are all examples of added complexity. If these integrations are needed, you’ll have to partner with the vendor to coordinate the details. If internal IT staff are unavailable due to other duties, the project could be delayed. As the client, you are also the source of information on how your current system works. Even with a detailed SOW, there will be questions only the end customer can answer. What group does the automated attendant hit when you press option 1? What specific buttons need to be on the CEO’s phone? How long should a call sit in the contact center queue before the caller is given the option to leave a voice message. These are all examples of low level design yet the specific nuts and bolts of what will be configured. These elements flow from the SOW, but will require customer input to build a low level design. This low level design is what engineers use to configure the systems.
Collaboration deployments aren’t difficult, but they can be complex. Making sure you have the provider engaged in the planning, getting the right amount of detail in the SOW, and planning time for your internal team’s involvement will all help the process move smoothly.
Curtis brings over 25 years of collaboration experience to ABS. As the Collaboration Team Manager, Curtis works to ensure that ABS is consistently providing the latest collaboration technology and support to ABS clients.