Why your call center needs “TEXT” solutions!

21st Century Call Centers still operate with 1980 business models!

I have been working with inbound call center for some 40+ years and despite all the”omni” channel technology the inbound call center model has not changed very much.   Those of us who have call centers that support a for profit business are focused on improving the customer or patient experience.   We all want lower caller holding times, faster response times and lower costs.   I have never heard anyone say, lets add more agents!   The usual answer is lets add more telephone lines!   This strikes me as more than ridiculous!   Basically, increasing the size of the catchers mitt by adding more telephone lines,  enables the call center to increase the number of people on hold awaiting service by the same number of agents.  Now how can that make sense?   If you think about it, the only reason you have more inbound telephone lines than you have agents, is so folks do not get a busy signal.  Over the years call centers have learned that it is better to capture the call and then hold the caller than it is to generate a busy signal.

One of the major differences between a call center in the 21st century and earlier call centers, is the availability of “smart phones”!   As it relates to the American Business Landscape you are on safe ground if you just assume that every man, woman and child in America has a smart phone.   In fact, it is safe to assume that smart phones have long ago out paced wireline connections.   So why not use this resource to change the call center model?   Why have more incoming telephone lines than your call center has trained agents or customer service representatives?  Additionally, nobody is sitting at home or the office holding a phone handset while waiting for the “next available agent”.  They are driving the kids to school, or running around the market place in an ever increasingly more mobile environment.

“Now that cell phones are owned by 90% of American adults, many are ditching their landlines and going completely wireless in their households. The CDC recently reported that 39.4% of homes in the U.S. indicated having no landline phone and at least one wireless device. This trend is now being adopted by more and more households as many find it unnecessary to have both a landline and one or more mobile devices” – Green Mountain Communications 

Enable two way TEXT in your call center!

TEXT notifications are ubiquitous—from doctor appointment reminders to credit card fraud notifications, they are commonly used to send messages, alerts, and reminders. All too often, however, the message only goes one-way and the customer cannot reply with a question or text back anything other than a confirmation code or a request to stop receiving such messages. Or, the customer is provided a phone number to dial for further assistance.  Enabling two way TEXT applications in your Call Center could be a disruptive game changer!

Imagine a call center in which folks just send a ‘text’ to the call center.   The call center could respond with a useful message that estimates the wait time for a return call if an agent can not immediately call you back.  A very simple change in strategy, but the improvement in customer service and reduced operating expense should be obvious:

  • Customer Sends TEXT – “Please call me”
  • Call Center  returns either a voice call from an available agent or;
  • Call Center returns a TEXT message “We will return a call to you at this number in 5 minutes.   Is that a good time to speak with you”
  • No more IVR “call trees” or extended hold times.  The customer knows exactly what to expect and when to expect it!  Options to call another number of call at another time can be easily worked into the TEXT conversation.   NO need to have more than one telephone line per agent!

The Deep Data Integration options are enormous:

  • Customer Sends TEXT – “Please call me”
  • Call Center returns a TEXT message “Hi Peter, we see you have an appointment on the calendar for Monday, is this what you are calling about”?
  • Customer Sends TEXT – “I need to change my appointment”

The fact of the matter is it may not be necessary to speak with an Agent at all!    The application of Artificial Intelligence and “bot” technology to TEXT based information is significantly more achievable than that required of speech recognition.  It is also much less costly to implement!

No more Abandoned Calls!

A TEXT based Call Centers would drop the abandoned call statistics to zero!  Given that all calls are now scheduled and there is no caller waiting in queue on an incoming telephone line that your call center pays for, there are no abandoned calls!  This would decrease holding times and increase service levels across the board.   It is also self documenting, secure

4 Reasons Your Call Center Needs SMS

Many of the benefits SMS affords companies are specific, but there are also some big picture advantages worth exploring. Here are the top reasons why your call center needs SMS.

  1. Customers Want SMS

SMS is the new email. Customers are comfortable with texting and prefer SMS for the flexibility and convenience. While it was easy to ignore in the past (when only a small fraction of consumers used text messaging), you can no longer ignore SMS without some negative consequences.  According to industry research, call center wait times are one of the biggest turnoffs for customers. The vast majority of customers – 95 percent to be exact – feel like five minutes is the longest you should ever have to wait to speak with someone. Unfortunately, the majority of businesses force customers to wait much longer than this. Enabling SMS not only relieves call center congestion, but it also gives customers the option to ask for a callback, as opposed to waiting on the line.

  1. Self-Service Options

As you know, many of the calls your customer service department fields are simple. However, they still tie up your time, energy, and resources. What if you could automate these simple, yet time-consuming calls and free up your resources for the bigger picture issues? Well, you can.  Ultimately these self-service options benefit businesses in multiple ways. To quote our article, “consumers will often take the path of least resistance, so offering a text in service will save them having to call in, while avoiding having complaints aired in public on social media.” In the end, this leads to more satisfied customers, better brand image, and fewer wasted call center resources.

  1. Superior Service

The bottom line is that phone lines simply don’t cut it anymore. The modern consumer expects businesses to offer multiple channels of engagement and doesn’t want to be forced into placing a phone call. SMS is seen as much more convenient and service-oriented.  This is why text-enabled concierge services like GoButler have seen tremendous success. Customers feel like they’re getting more value from a company or service provider when the company is willing to communicate in comfortable and convenient ways.

Consider a cable and internet provider. Instead of needing to place a phone call and wait on hold for 10, 20, or 30 minutes, a customer could send a simple text message to the company that reads, “Hey, my internet is down. Can you help?” The provider can then respond with some simple questions about the situation and set up an appointment time without further disrupting the customer’s day.

  1. Customers Answer Texts

From the enterprise side of things, it’s sometimes necessary to contact customers. Well, the problem with contacting customers is that they’re often hard to get in touch with. Many users won’t answer numbers they don’t recognize and others rarely check their voicemails after missing a call.   SMS is an entirely different story. The Pew Research Center says 67 percent of cell phone users check their phone for messages even when they don’t notice it vibrating or ringing. Roughly 44 percent sleep with their phones next to their beds in case they receive a message or notification while sleeping.

Both of these statistics prove that customers are highly connected to mobile messaging. This rapid response makes SMS the quickest way to connect with customers, especially when the issue at hand is timely in nature.

Give TEXT a chance now!

The benefits of enabling TEXT in your call center will increase customer satisfaction, enhance the service experience and significantly increase productivity in your call center while reducing over all costs!   If you would like to experiment with TEXT in your call center, send the keyword DEMO to 424-348-4000 and we can get you setup in short order.   You might also check out www.Click2WebChat.com for some additional thinking on this subject.

Configuring a SIP Trunk TIE Line between CISCO CUCM and ShoreTel iPBX

Merging Systems is fun and easy?

In a world of swirling mergers and acquisitions,  IT organizations are expected to integrate the different systems so that they all work together.   In the world of  IP PBX systems, that might result in having to make a ShoreTel system play nice with a CISCO system.  Actually, both systems support SIP and though it is sometimes more of an art than a science, it can be configured and made to work.   In fact we are seeing this request a lot lately.  Not sure why, but there are a lot of ShoreTel/CISCO integrations out there in the real world!   This video cheat sheet takes a look at a real world configuration from both the ShoreTel side and the CISCO side, so there is something for everybody who has to work with either or both systems.

Quick Topology Overview

In our example we have a CISCO Version 11 deployed in France and a ShoreTel version 14.2 CPE solution deployed in several NY locations.    This will be an interesting configuration as both systems have over lapping extension numbers.  For example, both systems have the range of 4100-4199 as extension numbers.  This along with a requirement for tail end hop off or TEHO at both ends makes for an interesting configuration puzzle.  We determined to take it a step at a time and get a basic SIP  TIE line working between the two systems.  Once that was up an operational, we could then focus on the basic dial plan strategy that would enable us to resolve the extension number conflict.

We are not going to use a session boarder controller at either end.   The good news is that it will greatly simplify the configuration as the two SIP proxies will directly exchange SIP messages.   In the case of the CISCO, the SIP trunk will originate on the call manager server itself and will terminate on a ShoreTel SG appliance (one of those orange boxes for you CISCO guys) with SIP Trunk resources sufficient for the number of channels you want to set up.    The bad news is, that on the CISCO side it makes trouble shooting a bit more time consuming.  If you had a CUBE in the mix you could easily open up CCSIP Messages in the debug on the IOS device, but when you do not have IOS you need to download logs from RTMT.  On the ShoreTel side, there is the ability to do a remote wire shark capture from the HQ server diagnostic panel using the SG appliance as the end point source.   (As a VOIP engineer SIP debugging should be second nature).

To avoid the use of a SBC on either end, we have to configure the solution entirely within a private IP topology.  In this case we have a 10.0.0.0 /24 network on the ShoreTel side and a 192.168.53.0/24 network on the CISCO side.   The WAN connection is an MPLS network.

ShoreTel and CISCO dial plan strategies

CISCO does not really care about over lapping extension numbers of difference in extension number ranges.  When I say, they don’t care, I mean they have a strategy for dealing with it.   You might have a multi-site deployment as a result of a recent acquisition and you have four digit extension numbers at one site, and five digit extension numbers at a different site.  CISCO can deal with this.  ShoreTel not so much.   With ShoreTel you would have to convert the four digit site to five digits (you can expand from four to five digits,  but not five to four) if you are going to have one dial plan.  In CISCO you could actually let both sites coexist with different extension number lengths.

CISCO has a verbose dial plan strategy that expects you to create route “patterns” that when matched by dialed digits, point to a gateway or route list that contains a destination reachable by that route pattern.  In our example, we set up a dial pattern of 51.xxxx with a pre-dot discard that points to the SIP trunk TIE Line over to the ShoreTel.   The SIP Trunk configuration is relatively simple and is shown in the video below.

ShoreTel requires you to configure a Trunk Group and then put your individual trunks into the group.  These individual trunks are basically SIP channels and the video also shows this configuration.  The difference in the strategy of both systems is interesting to note.   CISCO is routing to this trunk group based on a route patter that matches dialed digits.  ShoreTel is going to want you to define both an access code and list out the OPX (off premise extension) numbers that this trunk can reach.

From a digits dialed perspective, ShoreTel is going to match the dialed digits against the list of OPX extensions to route calls over the Trunk Group that contains a matching OPX list.   Note that no access code will be required, though it will be required in the Trunk Group configuration.

SIP Trunk Group Profiles

Both systems required a reference to a SIP Profile that defines specifics of the call setup messaging.    Sometimes this is a bit more of an art than a science and it may take a bit of tweaking.   CISCO has a standard SIP Profile and an associated SIP Security profile both of which will be referenced in the SIP trunk configuration.  The only change I typically make to the SIP Profile on CISCO is to activate the “enable PING option” so that I can keep track of my trunk status which would otherwise be “unknown”.

I made all my SIP Profile changes on the ShoreTel Trunk side.   This is the  list of configuration options we applied and it was the result of trying and retrying, so this list alone should be worth the blog read as it most definitely works in our example:

OptionsPing=1
OptionsPeriod=60
StripVideoCodec=1
DontFwdRefer=1
SendMacIn911CallSetup=1
HistoryInfo=diversion
EnableP-AssertedIdentity=1
AddG729AnnexB_NO=1
Hairpin=1
Register=0
RegisterUser=BTN
RegisterExpiration=3600
CustomRules=0
OverwriteFromUser=0
1CodecAnswer=1

If you have never configured a ShoreTel SIP Profile, the video walks you though this in detail.  ShoreTel provides a “standard tie-line” sip profile and suggests that you use it.  In fact if you change it, they generate a strong message urging you not to do so, but change it we did to the settings above and we had a more than acceptable result.

Extension conflict resolution

ShoreTel trunks do not out of the box allow abbreviated dialing.  The Standard ShoreTel domestic dial plan really wants what amounts to an E164 format.   ShoreTel will take all digits dialed and attempt to construct a +1 NPA – NXX – XXXX dial string.   So in this example, we are not going to be able to dial 51 as an access code on the ShoreTel side, then output only four digits.  Not going to work.    As outlined above, ShoreTel will want you to define the OPX extension reachable by the encapsulating trunk group in a detailed list as part.   The good news is that this means that you only have to dial the distant extension number and ShoreTel will see it as an OPX and route it over the associated trunk.

Clearly this means these extensions are unique.   What are we going to do? We have extensions on both sides of the TIE Line that are not unique, they are the same 41xx.   ShoreTel will allow you to create translation table to over come this limitation.   We could create a range of 61xx for our OPX list and then convert it to 41xx in the translation table and that would eliminate our problem.  Not my favorite solution but it may be the one we have to go with.   The down side is that we have no eliminated the 61xx range for use on the ShoreTel side.   Additionally, it is not very friendly to directory systems as people have to remember that if you are calling 4304 in France from New York, you need to dial 6304 not 4304 another colleague in NY!

Ideally we want to make use of that access code.  It would be nice to dial 51 + XXXX and be done with it, but as previously explained ShoreTel does not easily support that option.   It may be possible to write a custom dial plan and apply it to this specific trunk group.   For example, when working with paging adapters that have zones, you want to dial the paging amplifier and then dial your zone.   The custom dial plan for this would by “;1I” but you would still have to dial an OPX number.   For example, you would create the trunk group and maybe put 1234 as the OPX which would route the caller to the paging adapter.  The custom dial plan rule would be interpreted by ShoreTel as “do not echo any digits” enabling the paging adapter to play a second dial tone, and then you could touch tone out some digits.   Sounds like this would be a good solution but you would end up dialing eight digits, but it would free up a range of extensions that might otherwise be eaten alive by the required translation table.

ShoreTel Update

At the end of the day, the solution was to create a custom dial rule and apply it to the ShoreTel Trunk Group.  Users inside the ShoreTel would dial 50+xxxx but as a result of the custom dial rule, the ShoreTel would see 999-555-xxxx and only pass the xxxx.   Remember that ShoreTel wants you to list the extension numbers on the other side of the TIE line in the OPX list of the Trunk Group.  In a situation in which you have extension conflict you can use a translation table, but often that is not the most friendly solution.  Ideally you will want to dial and access code, get connected to the distant phone system and then out dial the extension digits regardless of extension conflict.   To do this on a ShoreTel system will require a custom dial plan modification to the trunk group.  The document on this subject is very limited so you either have to pay ShoreTel  Professional Services or be prepared to play detective.  We went the detective route, so hit us up for the solution.

 

 

 

 

 

 

 

CUBE SIP Header Matching – Extracting DNIS from a Toll Free Number!

The Problem – Call Forwarding DNIS to Toll Free Numbers

Recently we were presented with a new challenge while deploying a Call Center based on the CISCO UCCX Version 11.5 feature set. Generally, we employ DNIS as a strategy for defining the CSQ  service parameters.   The more specific you can make the inbound number, the less you will need to “prompt and collect” digits from your caller.   A call to a specific DNIS number can separate the English callers from the other language options, or route “customer service” differently than routing “technical support”.   DNIS is always a preferred routing strategy.    Using DNIS we can design a single call routing script that can  pull in the CSQ name; offer up the proper audio menu’s; provide unique queue handling options and customize the caller experience all based on the dialed number.

In this centralized scheduling application for a large national medical practice, patients would call a local number in their community.   This number was then forwarded by the carrier to a toll free number that rang into the centralized CISCO cluster and UCCX call center.   The issue was setting up the dial peers to address the number the caller dialed, not the toll free number.   These numbers terminated on a SIP trunk that was serviced by a CISCO CUBE and the number presented was the 10 digits of the toll free number.   The DNIS number, or the number that the caller originally dialed may or may not be buried in the TO field of the incoming SIP headers.

Solution – Step 1 Debug Captures of inbound SIP messages

We need to setup “debug ccsip messages” and “debug voice ccapi inout” and make some test calls.   We need to understand how the carrier is handling the forwarded number.    In the log output below we can see the INVITE is the 877 toll free number.   The number that the caller dialed is the 9323646969 number and we can see that it is in the TO filed of the sip message headers.   We will need to write a dial-peer,voice class uri,  translation rule and profile that extracts the TO field and routes on that number rather than the original INVITE.   It is the “voice class uri” that is most magical in this solution.   (Note that we got luck here and the carrier was handling the call forwarded number in a manner that was appropriate to our goals.   This however is not always the case)!

 

Solution Step 2 “Voice Class URI”

In this example, the caller is dialing 93236453XX which is being call forwarded to the  toll free 877 number and shows up in the sip headers in the TO field.   The solution here is to create a “voice class uri”  rule.  In the snippet below we can see “voice class uri 102 sip” with a “user-id of 9323645323” as an example.   We are going to ultimately want to translate this to a four digit extension number 5323 and this is done with the traditional translation rules.  In this example “voice translation rule 102” does this conversion.  Note however that the translation rule refers to a match on the 877 toll free number, not the  9323645323 number.  This is where the magic of  “voice class uri”, the ability to do dial-peer matching based on the uri.

The Voice Class uri is structured such that it has a unique TAG and then a matching expression or host IP address.   The the snippet below we can see two attemtps to setup up a uri filter based on the last digits in the TO field of the SIP header.  Tag 102 looks to match 5323 and tag 103 looks to match 5324:

Solution Step 3 Dial Peer Matching

The call flow is dictated by dial-peer matching.   From the following snippet:

dial-peer voice 103 voip
translation-profile incoming 5324
session protocol sipv2
incoming uri to 103
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte
no vad

!

dial-peer voice 102 voip
description Incoming – FAX DID
translation-profile incoming 5323
session protocol sipv2
incoming uri to 102
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte
no vad

We can see that the voice class reference is applied to the dial-peer much the way a voice translation-profile is applied with the expression “incoming uri to 102” which sets up a filter to match for the number  9323645323.  Note that the dial peer matches the voice class but it is the translation-profile incoming 5223 that changes the ten digit number of the URI to the desired four digit extension.  In fact if you study the voice-translation rule 102 rule 1, references the toll free number!

These tools, the voice-translation rule and the voice-class uri work together to enable us to route and match dial-peers on information in the uri and not necessarily the original INVITE sip: number! Way powerful!