Call, Click or Text your Contact Center?

Mobile devices are the most ubiquitous devices on the planet! Text messages are read almost instantly, never miss their target and are high impact, high content messages. Why continue to increase the number of incoming telephone lines to your call center? All you will do is cause more people to wait on hold, lowering your customer satisfaction scores while increasing your operating costs. The call center market is moving toward “purpose built” communication solutions through smartphone aps that pinpoint customer solutions and map directly to customer satisfaction solutions. Why not allow your clients to send a TEXT message to your call center? Chances are the Caller ID will have a higher match rate to client records in your CRM system then that of a land line! You can automated the reply, or route the text to the next available agent! Your client either gets an immediate call back, or is offered a scheduled call.

Why call an 800 number, self-navigate through a maze of Automated Attendant menus only to hear the ever present “please hold for the next available agent and your call will be answered in the order it is received”. A simple text message or smart phone ap, could automated that entire process! Your client never has to wait on hold! You agent has all the contact information and can instantly reply with a return text confirming wait time or suggest a scheduled call back time. After all it is a mobile phone, we don’t have to worry about where they might be when we do call back!

Call, Click or Text! A truly unified contact center needs to offer customers a text option. If your contact center is already routing email to the next available agent, we can bring up a TEXT solution in hours, not days. Compare the cost of a text message to the cost of a phone call! Compare customer satisfaction scores with immediate text feedback when compared to and increased wait time. The benefits are astonishing!

Text the keyword DEMO to 424-348-4000 include your email and we will send you a demo account for an automated demo.  SMS numbers can be provided Internationally.  Optionally open an account at PriorityMemberServices.com and we can get your ShoreTel ECC or CISCO UCCX setup for SMS and MMS!

Understanding ShoreTel Connect ECC Shifts!

Why use Shifts at all?

Most call centers have “on hours” and “off hours” that route callers to different options based on time of day and day of week.  ShoreTel ECC has a concept entitled SHIFTS.   Shifts have day types:  Weekday, Weekend and Holiday.    You  go to System Parameters in the Contact Center Director, then Schedules and the create a Shift.  Name the Shift something useful, specific the day type and the time the shift action should occur.   You then  apply it to the IRN you want to alter, open or close based on your shift schedule.   If you do not understand shifts, however  and how they are utilized by the ECC you are at risk of shutting down your call center unintentionally.

Let’s take a closer look at how Shifts work!

Each IRN in the ECC that uses Shifts, has a default setting that specifies where the call should route, if there is no corresponding shift instruction.    The Shift might specify a Script, Service or Device.  For example you might have Shift named “M-F”  defined for day type Weekdays that is active at 8:00AM and specifies that the call should be routed to a script for handling calls during “on hours”.    You might then also add another Shift named “Lunch” for a day type Weekdays and set if to activate at 11:59 AM and point it to script that plays an announcement alerting callers that the call center is closed for lunch and invites them to call back at 1PM (never happen but it makes for a good lesson example).    Now we create another Shift also named “M-F” for day type Weekday and set it to activate at 1PM.  This action points the calls back to the script for “on hours”.   Clearly, you also created a Shift for “M-F” for day types Weekday and set the action time at 5PM.   The action is to send the call to the script for After hours.   Make sense?   Seem easy?

ShiftMenu

Danger – The trouble Spot with Shifts!

Let’s assume you have an IRN for Sales and an IRN for Technical Support and you apply the shifts we defined above, to both IRN’s, but on the sales IRN they do not close for lunch!   For this reason, you do not apply the Shift entitled “Lunch” to the Sales IRN.   Let’s assume the default route for the Sales IRN is the Closes script, so that after hours calls defaul if not specified in the Shift list to the after hours call handling.   So what do you think will happen to the Sales IRN at 11:59?

ShiftIRN

The fact that you created a Shift and one now exists for “Lunch” during the week is the important take away.   Once you apply Shifts to an IRN, ALL shifts apply even if you did not apply that shift to your IRN.  In this simple example,  the Sales IRN will follow the Default route because you did not specific an alternative destination in you shift list on the Sales IRN for Lunch time.   The fact that the Shift exists in the ECC database, requires that you specify an action for that Shift!   This is where most folks get into trouble!

What Version of ECC is your Shift definition?

In versions before Connect and ECC 8,  Shifts required you to open and close a shift.  After version 8,  you are not required to close a shift but it would be a good practice to do so!  You must account for all shifts, even if they are to relevant to your IRN.   The only way around this is to NOT apply any Shifts to an IRN.  If the IRN does not use Shifts at all, it will ignore all Shifts!   A bit confusing but once you “get it”  it is easy.

When in Doubt press Explain Shifts!

In the IRN definition press “Explain Shift” and then select the day you want to explore.   The list will populate with all the Shifts that impact that IRN.   Remember it does not matter if it is on your list!  What matters is that the Shift exists for the ECC and you must specify an action, or in the absence of a direction, the default destination for that IRN will be followed!

ExplainShift

 

 

TOP ShoreTel Connect Installation Gotcha’s !

So you are upgrading to ShoreTel Connect!  Watch out for these blistering hot spots:

Assume you have a call center that works three shifts, with 15 Agents per shift.  In the Pre-Connect world, you would define 45 agents but you would only need licenses for 15.  The Pre-Connect ECC license strategy was “concurrent users”.  The new license strategy requires you to license 45 Agents.  Additionally, all agents have to be named in the iPBX, costing you an additional “per seat” license for the newly named agents.  Before, 45 agents could log into extensions Agent1 through Agent15 using their AgentID to differentiate them for reporting purposes.   Wow!  I hope you don’t find this out the hard way.

Here are some of our favorite ShoreTel Gotcha’s:

1 – Ever have to move route points from one server to another?   You CAN NOT use the batch utility to do this and must remove and then reinstall each route point.   So much fun on a large contact center deployment ( If you know SQL you can actually modify the configuration database to do this).

2 – Want to change IP address of your HQ?   If you are using the new family of 400 phones, you will have to touch each phone individually and manually CLEAR the Configuration for the new Option 156 and DHCP values to take hold.  How would you like to upgrade 3K phones across five times zones to learn that gem!

3 – Gee, would it not be nice to use DNS Name resolution in the Phone Setup?  You could just change the IP address in DNS and update your entire deployment!

4 – Is it no time to get rid of the DB9 Serial IO cable for switch configuration?  It is the 21st century and we sill do not have USB on ShoreTel switches?  When was the last time you had a serial printer cable with an DB9 connector hanging around your tool bag?

5 – Setting up OBDC connectors still use 32-bit connector and do NOT support AD login.   If you are connecting to Microsoft SQL, for example, if you use an AD credential your ECC Script will fail.

6 – Active Directory  integration is a one way sync out of the box.   Even adding the ShoreTel professional Service add on for AD will not solve all your issues!

7 – ECC Shifts will destroy you if you do not fully understand their use and impact.   Create a Shift to close on of your Customer Service Queues at 1PM and end up closing your entire call center!  (See this Blog entry).

8- You can not enter anything in the External number field for transfer a call but  9+1+NPA- NXX-XXXX.  No 9+011-44-204-668-5000 for example.  It will not work! Not for a call handling mode, CTI route point, External Assignment.  Nada. no bueno, NFG!

Useful and Helpful Event Log error entries!  Our Personal favorite:

ShoreTelError

Send us your favorite Installation and Maintenance Gotcha’s and we will update the list and credit you for the contribution!

DrVoIP@DrVoIP.com

 

 

Configuring Compliance Recording with CISCO Workforce Optimzaiton

For compliance will you Record Audio or Screen?

There are a range of products and services that can be used to “record” phone calls on a CISCO CUCM, UCCX and UCCE. These products range in sophistication from services that simply save a wav file of a recording which you can search for by time and date, to very sophisticated recorders with advanced index and search capabilities. Some products even include speech recognition functions that can be used to search files for a particular call or even handle a recording base on the audio content.  CISCO Workforce Optimization and Advanced Quality Management adds desktop screen recording and metrics that can also be used for evaluations and service observing.

All of these products have one characteristic in common; they require you to configure a recording capability in your CUCM to copy the media stream from the target source to the recording server. There are a number of options for doing this including SPAN recording and other options that require you to configure your Ethernet switches to accommodate the recording function.  The simplest method to copy media streams is to use the Built in Bridge or BiB of a CISCO phone.  Clearly this can only work for a specific set of CISCO phones, but most phones support this function.

General Recipe!

The following is a basic general recipe for setting up your CISCO CUCM for recording and identifies some of the decisions you have to make along the way.

  • Gateway or Phone;
  • Notification or not; Notify the caller, or the Agent or both?
  • Route Pattern for Recorder along with a Partition and Calling Search Space.
  • Create a Recording Profile;
  • SIP Trunk Setup between CUCM and Recording server; and options CUCM and Gateway;
  • Identify Users and add them to the proper CTI Recording and Monitoring Group;
    CTIPemissions
  • Enable BiB on the phone;
    BiB
  • Enable Recording on the DN;  Auto always or Selective and reference Recording Profile;

Basically you are creating a conference call between the “source media”, the CUCM and the Recording server.    The actual configuration has a lot of details and you will need to carefully consider each element, but the actual setup is routine for your average deployment engineer.   We summarized them below in video format.

You can also use CISCO XML services to enable SELECTIVE recording in which a phone is recorded only on the demand of the user.  This uses the Calabrio XML api and Phone Service option in CISCO.  This will enable the user to push RECORD, PAUSE, RESUME and STOP.  The second video walks you through the configuration options for that service.  This can also be deployed in Finesse as a desktop button!

Build ShoreTel Connect inside your own private Cloud using AWS!

Placing your ShoreTel HQ in the “cloud”?

Moving the ShoreTel HQ server to a data center to increase system resiliency, reduce or eliminate down time and increasing overall recovery times has always been high on the check list for business continuity and disaster preparedness.    Our preferred “data center” however is Amazon Web Services, or AWS for short!   We have been deploying ShoreTel in AWS as a “private” cloud solution for some time and have several blogs on the subject.

Do you already have an Amazon Account?

If  you have a regular old Amazon book buying account, you already have all you need to log into AWS and get started building out your own virtual private cloud!    Though there is a lot to learn,  in less than 15 minutes you can spin up a Windows 2012 Server in a virtual private network and then link it back to your onsite location with an AWS provided VPN Gateway!

The simplest ShoreTel/AWS deployment model

The simplest of VoIP deployment models is the placement of the ShoreTel Connect Server in an AWS Region and availability zone of your choice.    Typically, we defined a private subnet in three different AWS availability zones and then launched a ShoreTel Connect server.    The availability zones provide additional resiliency  options.  It is even possible to setup an Elastic load balancer than can move from one ShoreTel HQ server to a standby duplicate in another availability zone in the very unlikely situation of a AWS availability zone going off line!

You can interconnect your ShoreTel Connect VPC  with your remote sites over a VPN, ultimately moving to a “direct connect” circuit and only using the VPN for backup.   The remote sites will have ShoreGear resources to support localized carrier access and onsite user phone services.   The distributed nature of the ShoreTel architecture makes this a natural deployment model.   This is  by far the simplest of the deployment options and one that everyone who is considering moving a ShoreTel HQ server to a data center should consider.

Even Ingate in the Cloud?

With ShoreTel Version 14, virtual switch resources make it possible to create the entire deployment in your VPC.  You can even deploy your Ingate as a virtual Session Border Controller, in the AWS cloud and centralize your SIP carrier access.    This is a bit more demanding then spinning up a Windows server but now that AWS enables you to import vmware machines, it is an exciting option.

Importing vmware based ShoreTel machines

The secret to deploying ShoreTel vSwitches in the AWS cloud is to first build the machines as vmware machines in your local environment with an IP that can be duplicated in your private virtual network.   Once your machines are created, you can then import them into AWS.

The options for deploying VOIP in your own “private cloud” have never been more flexible.   Your CFO is going to be impressed when comparing AWS to the cost of building out your own data center or renting space in a collocation facility.   You have all of the benefits and none of the cost associated with a typical infrastructure build out.    Connection options are unlimited and you can access AWS facilities on a global bases!

The Video clip demonstrates a ShoreTel HQ and ECC Server in an AWS VPC, with a VPN back to the main office site.   The office site contains ShoreGear switches for SIP trunk access and 400 series phone support.  There is a synergy when integrating AWS and ShoreTel that every CIO should be seriously considering.    Give us a call and we can help make this happen for your company!

 

Add DNIS routing to your ShoreTel ECC Contact Center!

Why Route by DNIS?

Routing by the number the caller dialed, or DNIS is the preferred routing strategy for any Call Center call flow.  Clearly you can assign a DID phone number to a specific call flow and anyone who knocks on that door is answered by the same group of agents.   It is much more efficient to grab the DNIS information, however, and use it to index a database to retrieve the call routing information.  In this way, we only need one door to the call center!  The DNIS might be used to route a call to the proper product or service group and it may also be used to retrieve client information that the call center Agent needs to see displayed  in order to provide a custom care answer prompt.

Consider the requirements of a Hospital that is providing “centralized scheduling services” for 1000’s of primary care physicians.  When the inbound call is presented to the Agent, the requirement is that the caller be greeted with a customized answer prompt.  For Example:  “Doctor Leary’s office, are you calling to make an appointment?” or “Thank you for calling Doctor Williams”.  This type of dynamic call handling can best be managed by using DNIS information to retrieve the Doctor’s name from a database   We do this regularly in CISCO UCCX and ShoreTel ECC Call Center solutions and the process is essentially the same for both solutions.

ShoreTel ECC Route by DNIS example

First, we need to create a DNIS Map in the ShoreTel PBX; a ‘route point/IRN ‘ combination to pass the call to the ECC;  and an ODBC connector from the ECC server to your favorite SQL database server.   The SQL server would host the database your scripting application needs to access in order to obtain the correct answer prompt.  Lets assume that the database contains a very simple table structure:

DABASE = DNIS_listofDoctorsOffices = (Field1 = DNIS Number, Filed2 = OfficeName, Field3 = QUEUE_IRN)

You would then write a simple script to take the incoming DNIS information and use it to index the database and get the OfficeName and maybe the Customer Service Queue that handles that office (City or State or what have you).  There is no limit to the information you could retrieve and present to the Agent,  For example: Name, Service Class (Platnium, Gold or Silver), Renewal date, last order, shipment date, the list goes on.   In this simple example the script would take the DNIS and use a SQL expression to retrieve the answer prompt data:

Select * from DNISlistof DoctosOffices where DNIS = %DNIS_NAME%Sample ECC Script Screen

Creating a DNIS MAP in ShoreTel iPBX

In the ShoreTel iPBX Trunk Group it is necessary to create a DNIS map for two reasons:  First, the ShoreTel ECC can not read the DNIS directly, it requires the administrator to fill in the “dialed number” column in the DNIS map.  The ECC has a mandatory call profile filed named DNIS-NAME which will be auto filled with the information you provide in the DNIS map “dialed number” column.     Secondly, unlike a DID number that might be directly mapped to an extension, we need a way to get the incoming call connected to the IRN on the ECC that is running the DNIS SQL lookup  Script.   In this example, the Destination field of the DNIS Digit Map in the ShoreTel iPBX Truk Group points to the Route Point/IRN in the ECC that supports the script.

 

DNISMAP

POPing the Agent Display with useful Data

The ShoreTel ECC has two variables data types: Mandatory or System Variables; and User create Variables.  The Mandatory variables are system call parameters like ANI or DNIS and a long list of other system based data.   ANI contains the digits that make up the caller identification and that is also often used to retrieve database information.   If you are using ANI you will need to do some string manipulation to strip off the +1 from the 10 digit number, or format to match your database.   User created variables are the name you create for the fields you will get from your database.  Useful examples would be CustomerName, DateOfService, AccountBalance and RenewalDate.    Any Variable, User created or System,  can be pushed out to the Agent Display within the ShoreTel Communicator.

ScreenPop

What is your Call Center Application Requirement

We have seen it all, so we are always interested in your requirements for custom CRM integration and Call Flow management.  Give us call or drop us an email and play “stump the vendor”.   We would love the challenge of finding yet another new ShoreTel ECC or CISCO UCCX Contact Center application requirement!

[show_related ids=”2828, 2610 ,2447, 1378″]

What Carrier can provide Fiber to my branch office?

What Carrier do I use for this location?

If are responsible for planning out a WAN connectivity solution for your VoIP deployment, you need to know what carrier services your target circuit location. This can lead to the most frustrating experiences an engineer can have! You actually have to rely on someone else to provide information so you can finish your work! Even a simple point to point VPN tunnel requires you to figure out what carrier options are available at your target location. How do you do that? Start calling a list of carriers and asking the first line call center sales folks if they can provide an internet circuit to your branch office in Syracuse, New York? You do a google search and you end up with a list of possible candidates and then you start your outbound calling! Maybe you have a friend who is a sales rep for a circuit aggregator, so you try that option.

The secret Carrier database!

What if you could go to a website, you don’t even need to talk with a sales person, you just plug in an address and Viol! A list of all the Carriers that can service that location magically appears! X marks the spot of every Fiber drop that carrier has in the specified distance from your target address. Not just the carrier your aggregator wants to show you, but all the carriers that can service that target location. You even get a Google map street photo of the location! What if you could just click on that magic X and get a quote! Now that is freaking awesome!

We have been working on a very large WAN deployment to a ShoreTel system that has over 500 branch offices! Now try and knit together that circuit map without a database resource that you can directly tap. We discovered a website that makes the process as simple as entering a location address. Blow out your candle Pilgrim you search has ended, just click here  enter a Street location and you you will get a list of carrier solutions.

buildinglit.com

The good folks at BuildingIT have made finding WAN solutions as simple as locating an Uber Driver!    You don’t have to talk to a sales person, but if you do, they have some of the smartest circuit folks in the industry.  Can’t find fiber for  your Laramie WO location, ask sales to quote a solution through the website and they will come back with any number of alternative solutions, priced and ready for the next phase of your deployment, installation.   They even offer  bundled project management so you don’t have to worry the deploy.  One throat to choke, one website to research and one solution that makes a lot of sense to us!

 

ShoreTel lsp_ping and the SG-Vphone coma!

Ping a network engineers best friend!

Most network folks are comfortable with a standard Ping command.    Some even know that you can add options to ping to set packet size and repetitions, but at the end of the day, Ping is a level three ICMP command.

Ping Command Syntax

ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS] [-r count] [-s count] [-w timeout] [-R] [-S srcaddr] [-4] [-6] target [/?]

As an example: ping -n 5 -l 1500 www.google.com  the ping command is used to ping the hostname www.google.com. The -n option tells the ping command to send 5 ICMP Echo Requests instead of the default of 4 and the -l option sets the packet size for each request to 1500 bytes instead of the default of 32 bytes.

Ping is generally a knee jerk reaction for a network engineer!  It will establish and demonstrate connectivity between network devices.  It can be used to determine latency and jitter and is a very quick, effective and easy to execute network test tool.

ShoreTel Connectivity

ShoreTel administrators learn very quickly that the first place you go when someone complains about the phone system is the ShoreWare Director portal to the “Quick Look” section.   You quickly scan the screen for RED!   (That is what is so simple about alarms:  Green is good, Yellow means something needs attention and Red is bad)!   In this example the site known as Carol can not connect with the the Bob site.   Bob however can connect with the Ted and Alice Sites.  Carol can also connect with the Ted and Alice sites.   How do you visualize this in ShoreTel?   You go to the second screen and by clicking on  Connectivity and you see the famous ShoreTel Christmas Tree!

xmastree

This is very not good!   Sites can not communicate and calls are failing all over the place!  For  example the trunk group that terminates on HQ SGT1K-03 (Line 13), for example will not be able to complete an incoming call to a user on the user switch Central Time Zone (Line2).  The RED box at the intersection of two lines helps you visualize connectivity or lack of connectivity.   Why is this happening?

Lets Ping and find out!

The network engineer will undoubtedly do a Ping test.   You will ping from the source IP address of one site, to the destination ip address of the other sites device.  Now if the test fails, the next step is to figure out where the network connection is broken.   The more challenging problem is more perplexing.   What happens if the Ping is succesful?  You do your Ping test and you get an excellent reply and the network is not broken at the Layer 3 level.  What then?

Enter lsp_ping

ShoreTel has a proprietary protocol named lsp_ping.  This ping makes it possible to test network connectivity at the higher L4, transport level by enabling you to Ping with a port number.    In the example Bob can Ping Carol, so why is the BOX red?   The answer might be to run an lsp-ping  command.   Unlike Ping which you can run from your local computer to a destination ip address, you will need to telenet or Ssh into a ShoreGear switch to run lsp_ping.   To do this you will need to run the ipbxctl  security  command from a ShoreTel server first, then telnet into the device and run your test. It will look something like this:

lsp_ping “192.168.10.12”, 100

This will setup a ping to port 5440 at the target device of 192.168.10.12 and the quotations are required!  The comma 100 means, send 100 packets in this test.

What is lsp_ping?

Shoregear switches all keep a copy of the current configuration and know where the end points (i.e. handsets ) are and how to get there.   This is one of the strong points of the ShoreTel architecture.   You do not need to check with a server to get the current configuration, and if the server crashes, ShoreTel keeps on trucking!   The proprietary lsp or location service protocol, keeps updating configurations around the deployment reporting any changes.  They do this through ports like 5440 and if they can not update, they assume that switch is off line and thus you can not connect to it.

If you study the screen shot above and you knew the IP address of all the devices, you would be puzzled as to why two devices in the same subnet, using the same network path, going through the same network connection should have different connectivity status reports?  Every engineer has asked “what changed in the network” and every client answers the same; “nothing”.   If is always frustrating when you get a situation reported like the graphic above.   A working network for months with no problem and then suddenly the Christmas tree appears!  Especially when everyone reports that nothing has changed in the network!

ShoreTel TAC will always tell you a failure of lsp_ping means a network issue.  Most times it is, but this time it was not!

The take away from this discussion is that Ping can establish network layer connectivity, but ShoreTel can still have a connectivity failure.  You will then need to trouble shoot higher up the stack and look at the transport level and perhaps the application level.  In this scenario, we mirrored all network traffic to a packet capture device.  We ran Wireshark on the packet captures while doing lsp_ping and were surprised to see that lsp_pings on port 5440 were in fact not only sent, but received by the traget device, yet no answer packets were returned.  At first we though that it might be that a UDP packet, being connection-less, would not report, but looking at working sessions we determined we should see a return packet!

ShoreTel V-phone virtual appliance  coma!

The interesting fact in this mess was that the failure was always between the two sites (main location and a data center); and that the pair was always a hardware switch and a virtual switch!   The virtual switch seemed to be in some kind of coma as it did not return lsp_ping packets yet showed green in quick look.  As the issue was causing major ShoreTel call failure and a lot of people had investigated the network with no root cause identified, a decision was made to rebuild all the virtual switches or Vphone and Vtrunk as ShoreTel calls these linux based OVA files.  This cleared the problem with no changes to the network and all is now Green!

Summary Recommendation on SG-Vphone and SG-Vtrunk

We recommend the use of ShoreTel SG-Vphone virtual appliances only as failover and not as production resources.   Inside those ShoreGear Orange boxes is a rack full of dedicated micro-processors that provide DSP or digital signal processing resouces.   When these are vitualized all that processing most now be done in software.  What a work load!

 

 

 

Compare CISCO and ShoreTel “dial plans” and “calling priviledges”!

What is a route or dial plan?

Most if not all phone systems provide for route plans and calling or “class of service” privileges.   The dial plan defines the over all numbering system used through out the system.  For example, how many digits do we need to define all of our extension number or telephone endpoints?  What access code do we use to indicate we want an outside line?  What numbers will we set aside for system features like the automated attendant, voice mail, contact center and conference servers?   Generally this is one of the first decisions you make when designing a new phone system.   Once set, it is usually very cumbersome to alter or refine.

Calling privileges or “class of service” defines what facilities a specific user might have access to.   For example, we might want the Lobby and Kitchen phones to be able to dial 911 and make internal calls, but we might restrict them from dialing outside numbers at all, let alone long distance or international phone calls.   Some systems even restrict internal extensions from calling other internal extension numbers.  For example you might isolate the CEO from being dialed by the automated attendant “dial by name” directory and you certainly do not want the over head paging system accessible by an outside caller!

How do we include a new branch with the same internal Extension numbers?

These options become increasingly more complex as organizations redefine themselves as a result of a merger or acquisition.   How do you add that new branch office into the company phone system?  Things become even more exciting when the new office has a “dial plan” that uses the same internal extension numbers already in use by the HQ phone system.   ShoreTel and CISCO tackle this in very different ways and it is interesting to note the different strategies.

In ShoreTel you define you “dial plan” as the necessary first step in designing the phone system.  How many digits do we need to dial internal telephone numbers?  Out of the box, ShoreTel assumes you want to use three digit extension numbers.   You can change them to four, five or more digits but you can only do this once.  You can increase extension digit length but you can not reduce them, so plan carefully!  The next issue is what range will we use for extension numbers?  Will they start with 1, 2 or some other digit?  Don’t forget those “system extensions” as you will need them for many features and system resources.

ShoreTel also uses the concept of a User Group and a Class of Service.   A user group might be a function like Executive,  Manager, Employee and House phones.   The Class of service defines Telephone Features, Calling privileges and Mailbox options.   Telephone features might include who can access the Intercom, or record their own phone calls.   Calling privileges enable internal, local and long distance dialing options.  Finally mail box options indicate the size of messages, greetings and administrative controls.

ShoreTel has a very simple to implement and understand concept for dialing plans and calling privileges.  With simplicity, however, comes some restrictions.   Lets take the example of acquiring a new business unit and they have an existing dial plan that conflicts with the one already in place.   Well, you could through the inplace  phone system out and install ShoreTel at that location (certainly the ShoreTel re-sellers plan) by expanding the existing ShoreTel but that would certainly mean an change in extension numbers at the newly acquired business unit.  Optionally, you could install another ShoreTel system and integrate the two separate system through a SIP  tie-trunk.  Using a digit translation strategy you could let the other guys keep there old extension numbers but you would have two separate telephone systems, each with their own configuration database.   (In CISCO parlance that would be a two “cluster” solution).

ShoreTel Simple or CISCO Complex?

CISCO uses the concept of “route patterns” to define a dial plan.   It is a bit more complex, but with that complexity comes great flexibility.   A “route pattern” is a map for taking the digits a user dials and searching a database to find the route those digits should follow to complete the call.  For example, a user in the California Office might dial 9,1-212-523-51234 to reach extension 234 in the New York office.  The route pattern would then hit route list that might include a local PRI for a long distance call to NY, dropping the 9 and out dialing the E164 1+area code and number.  That route list might also include a WAN gateway that directly terminates in NY and in that case, drops all the digits but the 234 while placing the call over the company’s WAN connection.

To be fair, ShoreTel can also complete a call over the WAN and would be smart enough to know that #234 also has a DID number of 212-523-51234.  If the California user dialed #234, and the call could not be routed over the WAN, the call would be completed over the Long distance line using “PSTN fail over”.  The feature does not, however work the other way.  Had the user dialed the LD number and encountered  a network busy condition, it could not then route the call over the WAN.

As to”class of service”, CISCO uses the concept of a “partition” and a “calling search space” (i.e. CSS).   Though some folks like the “lock and key” metaphor,  we think the best way to understand this is to realize that “partitions” define who can call me.   “Calling Search Spaces” define who I can call.    So if my line or phone is in a CSS that specifies partitions NYPhones, SFPhones, UKPhones, Windstream, COX and Verizon, then those are the objects I can call.    If my device is in a partition named SFPhones and your CSS does not contain that Partition, then you can not call me.

Sounds a bit confusing, and at times it is.   The structure however enables us to build some very  significant solutions.  Take that example in which you have phones with the same extension number in two different business units in the same “cluster” or phone system.   You could put Extension 1234 in the NYPhones partition and in the SFPhones partition!   They would not conflict with each other!  Every phone, feature (i.e. intercom, conference), line in a CISCO deployment is in a specific “partition” and only reachable by an entity that has a Calling Search Space that includes that partition.  Simple!

Given that we are not in the business of selling phone system, only engineering and supporting them, We do not  have an emotional attachment to one over the other.  We observe that ShoreTel is best suited for smaller deployments and in fact can be easily deployed and managed by a small business of 25 or more.   Though there are larger ShoreTel deployments, we see them in the 100 – 1000 user line size most frequently.  CISCO has a low end Solutions, the Business Edition 6K-S for system under 150 users,  but the CISCO Collaboration solution could run a small a small country though the Business Edition 6K and 7K are optimized for 100 – 5000 users!

The video shows the two different approaches to solving these common route plan issues!

 

 

 

 

 

 

Trouble Shooting ShoreTel ECC Scripts

ShoreTel ECC Future?

The ShoreTel ECC or enterprise contact center is a remarkable product in many ways.   Though we are depressed to see that it has apparently taken a back seat to ShoreTel Connect as it relates to product enhancements, it remains a formidable player in the contact center space.   Clearly, if you are deploying a ShoreTel phone system, then it may be the only viable option.    We note that ShoreTel has made a new acquisition for contact center functionality in the cloud, so the potential of supporting ECC product enhancements may even be less hopeful as product development resources shift to the “cloud” and ShoreTel Connect.

Remember EasyRun?

We have worked with the ECC since before it was a ShoreTel product.  It actually originated as an OEM product, a re-branding  of a software solution brought to market by EasyRun, an Israeli based company founded by Avi Silber, long time VP of Software Development for Telrad.   ShoreTel ultimately executed a software source code licnese and the rest is history.  Unfortunately, we seem stalled at Version 9 of ECC, which was not a major evolutionary step from ECC Version 8.

At any rate, the product does a super job in small to medium sized Call Centers and meets the minimum daily adult requirement for call center functionality.   One particular  function enables the system to integrate with popular database solutions like Microsoft SQL.   This enables the system to take on some very sophisticated applications that include routing inbound calls based on the return of data in the customer service database.  One of them most asked questions of marketing professionals as it relates to Contact Centers:  “are all customers created equal”.   You might want to route an incoming call based on the callers status in your customer database as a Platinum client or as a deadbeat on credit hold.

SQL database dips are almost essential for any Contact Center offering.   ShoreTel enables this functionality through OBDC connectors to the host SQL server or CRM system.    One of the challenges for design and implementation engineers is testing the design and results of the SQL data dip.  Historically, ShoreTel has not provided a lot of debug tools here and documentation on inner workings of the ECC is not generally available.  If you are bold and go poking around in the BIN files, you will note a lot of exe files and if you are curious, brave and inquisitive you might take on an exploration of what these files are used for.

Undocumented ShoreTel Debuggers!

One file in particular seems to launch a very useful test tool.  We have never found any documentation on it, and it has become something of a legend among we ECC implementation engineers.   If you are fortunate enough to maintain a relationship with other engineers that share information, you can build up a library of useful tools based on shared results from others.  Kudu’s to one such brilliant engineer, Bill Fraedrich for sharing his growing list of FC_Thingy functions and the other members of the development community who regularly publish results.

Route Caller by ANI (caller ID)?

Recently we had to create a SQL data dip to pull back a customer record using Caller ID or ANI as the database index.   Now anybody who has done any Contact Center CRM integration regardless of vendor, knows that you have to do some string manipulations to strip off the +1 that will be passed by the carrier as part of the ANI information.   ShoreTel ECC, CISCO UCCX, it does not matter it is all relatively the same.   Once you clean up the ANI you can pass it off as part of a SELECT command and go get your data.  Then manipulate the data to find the fields you are looking for to make your routing determination.

The undocumented debugger!

The issue becomes how do debug a script that is not producing the results your design expected?  Again, ShoreTel comes up short here as it relates to documented debug tools.   The CISCO UCCX, for example, has a step by step debugger built right into the script editor, which is really helpful for those of us who have to design, implement and test these scripts.   It turns out that ShoreTel has one as well, you just have to know where to find it.   Again it is not documented and is well known only to those that know it well.

In this video clip we take a look at the tool and show an example of how you might use it to unravel a particular SQL data dip problem.    We have found a number of these tools and we are always looking for documentation and road maps produced by those who have gone this way before!   Next blog we will take a look at a TAPI debugger that is also very useful when troubleshooting ShoreTel phone system Communicator issues.

At any rate, the ShoreTel ECC has great potential and is a wonderful solution when applied in the proper environment.   You can create some very sophisticated routing applications based on a variety of CRM integration, custom software solutions and IVR scripts.    Despite all our grumbling and complaining,  we have not found anything we cant make work on a ShoreTel ECC!