Configure ShoreTel for Redundancy, Resiliency or Business Continuity?

Of late we have seen a growing interest in building “disaster recovery” solutions for both the data and the voice applications so critical for business operation.  First, we need to make sure we understand the difference between redundancy, resiliency and other configuration options to assure business continuity.  Many more installations now include the use of a remote “collocation” facility as an key  component of the installation plan.  What is the best way to configure a ShoreTel HQ server, for example to provide for continued operation under a wide variety of options.

The subject of redundancy is almost amusing at times.  How much redundancy is reasonable and appropriate?  You can have all the redundancy your budget can fund, but at the end of the day are you able to continue the business operation in the event of a catastrophic event.    Clearly, two power supplies are better than one.  If they are both plugged into the same commercial power outlet, however, it really will not matter how many power supplies you have if you lose commercial power!  Again, we need to focus on what are we trying to protect?

Redundant servers?   Some HQ servers have been configured with “double take” enabling a hot standby server to take over in the event of a primary server failure.    Candidly, we do not see the benefit of hot standby server swaps in the ShoreTel architecture and it is a nightmare to administer, backup and restore.  The cost of the solution outweighs the benefits and there are other configurations that are more cost effective and work just as well.

For example, there is no law that says you can not install a ShoreTel Distributed Voice Mail server at the same level as the ShoreTel HQ server.   Actually, this works just fine!   Install the servers at the same physical location, or put the HQ server in the remote “collocation” facility.  If they are installed at the same “logical” level (i.e. appear on the same level in the Shoreware Director, either server can handle the load.   Generally, you would put all of the users and switches for that site under the DVM and use the HQ as your “fail up” and proxy solution.   Nothing wrong with this configuration, it is cost-effective and easy to administer.  From time to time you might hear ShoreTel say “ please wait while I connect you to the correct server” but even that can be managed.

ShoreTel HQ has three services that are not distributed: Route Points; Account Codes and Workgroups.  If you lose the HQ server, you will lose these services, but generally, that is a small price to pay for this level of resiliency!   ShoreTel Version 10 promises to distribute these services, so there is no reason not to configure this way and achieve full survivability given the building is still standing.

You don’t have to think very long about a Katrina or Haiti, especially if you live in California!  It is only prudent to not only plan for some level of “redundancy”, but also to plan for how the business would operation if we could not get into our building!  If we put the HQ server at the “collocation” facility and we provide for Trunk Lines and “dial tone”, we can balance this possibility.   The issue is, that if the building housing the people becomes unavailable, users can still log in and route their phones to cell phones or make use of RDP to access their Call Managers.

The “collocation” option often requires a trade-off between bandwidth and trunk lines.   You can put all your trunk lines at the colo, in which case every call made from the sites, will traverse a WAN.  So moving the trunk lines to the colo increases resiliency but also drives up your WAN cost.  At the end of the day, it is most likely some combination of bandwidth and trunk lines spread between the facilities.  In either case, you will work with your carrier to enable lines to be repointed in the event of an outage.  This is a bit more challenging if you are in New York and your collocation facility is in Phoenix, but it can be done.

We are experimenting with the use of SIP trunk facilities at the Collocation site.  Generally, this can be more cost effective especially if you can get an agreement for a burstable SIP pipe.  You may not want to pay for T1’s at the collocation if you are only planning to use them for a disaster situation!  SIP also enables you to be generally independent of your physical location.

It is a sign of the times that we spend so much time planning for “what if” scenarios, but being prepared is not only prudent but appropriate.   Have a comment on this blog?


Why move the Auto Attendant into the Contact Center?

Many Call Center applications have an Automated Attendant front end call tree.  Typically, you  might have an Automated Attendant that plays the familiar On-Hours recoding: “Thank you for calling our company, press 1 for technical support and 2 for sales support”.  The question asked in today’s blog is: should the Automated Attendant be located in the PBX or in the Call Center? There are very interesting ramifications for each of these options.

Generally, with out thinking this question through, the easy answer is to have the PBX do the front end Automated Attendant.  In the ShoreTel world, the On-Hours/Off-Hours scheduling of the changes to the call tree and messages played is so “brilliantly simple” that everyone will select this implementation strategy.   In our simple example above, selecting either option will direct the caller via a route-point/IRN marriage into the Contact Center to be processed by the appropriate Service, Group and Agent.

If you implement that Automated Attendant in the PBX, however simple it is, you potentially rob management of very urgent call detail information. Typically, the Off-Hours location is a general delivery mailbox in the PBX anyway, so why not just keep it all in the PBX?   If the Automated Attendant shuttles calls to the Off-Hour location, that call may never become known to the Contact Center and therefore would  not be captured in the Contact Center Historical Reports.   Call Center Management might be very interested in knowing how many calls came into the Center before or after On-Hours!  To obtain the information the Call Center, not the PBX needs to host the Automated Attendant!

What is the result of implementing the Automated Attendant in the Call Center?  If you look at the above Automated Attendant script, you can see immediately that we need to add the famous “If you know the extension number of the person you want to speak with, dial it at any time during this recording”.   Given that you have already concluded that this is an option you want to offer clients, something a Call Center manager might not recommend, how do you implement this feature using the ShoreTel Contact Center?

There are several ways to do this on the ShoreTel ECC, but all options require the creation of a “Call Profile” value.   We have put together a quick video tutorial on how to implement a multi-digit transfer in the ShoreTel Contact Center using the Graphical Scripting Tools.   Minimally, after you create the Call Profile value you will need to have a “Get Digits” and the “Transfer” Icon.    In our example, we have created a Call Profile value named “ExtensionNumber”.  This value anticipates a three digit integer and does not require a termination character.   The GetDigits Icon is normally associated with a WAV file that prompts the caller for digits.  Once the digits are collected the are deposited into the Call Profile place holder named “ExtensionNumber”.   This value is then past to the Transfer Icon and the value is dialed by this function.   Enjoy!