Lex a conversational voice interface for Amazon Connect call trees.

Historically touch tone “call trees” have over populated the IVR landscape prompting callers to “Press 1 for this and Press 2 for that”. This has been the standard since the first half of the last century! You would think that in the 21st century we would have a solution that can eliminate this kind of button pressing, sequential logic, menu after menu of options and hope the caller gets where they wanted to be!

Which would you prefer?

Think about it. What would you prefer as a caller? “Thanks for calling BoringCompany greetings, if you know the extension of the party you want to talk with, enter it now. Press 1 for Customer service, Press 2 for Technical support, Press 3 for another menu with even more options for you to select from”! Or would you prefer “Thanks for Calling, how can I direct your call”?

To achieve that simple interface takes a lot of technology, but fortunately AWS Connect makes use of an AWS service named Lex. Lex is a combination solutions that include Speech Recognition, natural language processing and artificial intelligence. Lex can prompt a caller with a friendly voice “‘how can I direct your call” and then understand the callers spoken response. NO more pushing buttons, no endless menus.

For example, Lex could even figure out what language the caller is speaking and respond according, no more “to continue in english please press 1”, which in and of itself is worth the price of admission.

What is an Utterance?

Lex is built on the concept of “utterances” which is nothing more than a spoke phrase to which you can create additional responses. For example, the caller might say “I need to check the status of an order” and Lex might respond with “is this a recent order or do you need to speak to your sales rep”?

Keep in mind that Lex has captured the Caller ID of the caller and could actually look up either the order or the sales person that took the order. Lex might even be able to greet the caller by name. “Thanks for calling Peter, how can I help you”.

What can a “ChatBot” do in a call center?

As a “ChatBot” Lex can enable callers to self navigate through solution options without ever speaking to a call center agent. Lex can book an appointment, change schedules, update status information, change passwords, update calendars, summarize the new, weather and sports and greatly enhance the speed of answer and call resolution.

If Lex replaces three call center agents, is that an increase in productivity? We think not, if it only gets the same amount of work done as before Lex was introduced to the call center. We increase productivity when we can redeploy those three agents to do other work!

As always we are happy to setup a “proof of concept” that applies Lex natural language processing and automatic speech recognition to your specific environment. Just click or call and we would be happy to help you!

 

Amazon Connect Custom Integration tools!

If you have taken the time to experiment with AWS Connect and the creation of a cloud call center instance, you know that the basic setup is achievable by a business analyst and no implementation engineer is required. This is good news for very simple, inbound call centers but if you are planning to connect with the rest of the enterprise, you will need some folks skilled in full stake web service development.

No Call Center is an Island!

Call Center as a business process and customer experience management, require that the call center be able to communicate with other information resources throughout the enterprise. The interface between the AWS Connect call center instance and the rest of your organization will must certainly require both middleware and API’s that make use of advanced software development tools within AWS!

Common integration requests that dominate the call center technology space include:

  • Customer Routing Database Integration;
  • Work Force Management
  • Voice and Screen Recording and Playback
  • Voice Analytics
  • Salesforce.com
  • Electronic Health Record
  • Website Integration (think MyChart or CoBrowsing)
  • Microsoft CRM
  • Microsoft Skype for Business
  • Custom Agent dashboards
  • Real Time Metric display boards

These are just a few of the common requests we see on a daily basis. There are also unusual requests for custom solutions that are unique to the business enterprise the call center is deployed in!are also unusual requests for custom solutions that are unique to the business enterprise the call center is deployed in!

Common AWS Connect Integration Tools!

There are a few tools that are essential for developing integrations in AWS Connect. Generally, you will always require Lambda a “function as a service” to unite the call center to any other service. Lambda is “serverless” so you do not need to worry about setting up a server and you can write your function in any of the popular programming languages including Node.js our particular favorite!  Unless you are interfacing with a CRM, you will need a database and we would choose a noSQL solution like AWS DynamoDB, another server less solution.  Lets assume you want to route calls based on the callers area code, so that east coast calls go to the Agent group in your hierarchy that is optimized for east coast callers.  Maybe you want to greet your callers by name. This would require you to pass the Caller ID on an incoming phone call to a function in Lambda that would look up the customer and find the name, then pass the name back to the call center and activate Poly, the AWS text to speech service, so that you can prompt the caller with “Hi <customerName> before continuing to route the call to an agent!  Maybe you want to display the callers name to the Agent when they answer the call, which would again require both Lambda and DynamoDB in addition to some custom code!

Custom Agent Display?

Sometimes it is necessary to create an entire Agent dashboard to handle information displays, team collaboration, key metric broadcast, recording retrieval and playback.   We created the Dextr.Cloud dashboard to provide such an interface.  This is an example of the type of integration that is possible with AWS Connect and the many services that exist in the AWS Cloud.    We are interested in learning more about your own call center integration requirement and invite you to give Dextr.Cloud a try and also to contact us with your integration “’wish list’.   We have seen a lot of requests and nothing suprises us anymore!  So please feel free to play ‘STUMP THE VENDOR” and we will see if we can help you or at least direct you in the right direction!

 

 

 

ShoreTel Contact Center Overflow Concepts and Direct Calls to Agent!

I would like to kill call center challenges with one blog!   In many call center environments, it is possible that an agent has a Direct in Dial (e.g. DID) number that a client might call and bypass the entire call center process!   For a call center manager, this is very frustrating!  You create a Contact Center to organize the flow of calls to your Technical Assistance Center, and clients by pass the process by calling your Agents/technicians directly!

Clearly, you can eliminate this by not giving DID numbers to Agents, but we end up doing this to facilitate an orderly problem resolution strategy.  You might give a client a “homework” assignment and ask them to call you back.   They might object to being put at the back of the queue again, so you give them a DID number that gets them directly back to you.  The challenge is, that this call would not be accounted for in your contact center reporting!   So how then do you provide this feature and also create a mechanism for enabling your contact center to capture all calls for Agent Performance reporting?  One answer is to establish a “service” that has only one Agent in it!   Then build out a DNIS/DID route point to IRN relationship that brings that DID number into the call center and routes it to the Agent.

Actually, it is not a bad strategy!   The Contact Center can now account for all calls, even the ones that reach your Agent through a DID number and you can apply normal Contact Center routing tools like “overflow”, which brings me to my second point!   Is it possible to overflow calls to more than one other group?  Based on more than one overflow time in queue?

The Contact Center provides a wide variety of methods for handling callers in queue awaiting service.   One of the more interesting concepts is the ability to “overflow” a caller from one group to another group based on the amount of time they have been waiting in queue.   This contact center parameter is set within the “service” and can be found in within the tab labeled “Overflow”.

In figure One below, you can clearly see that we have a number of services defined, including a service named TAC1.   Let us assume that this is a technical service group and that TAC1 is comprised of Agents/technicians that include Agent Gandalf, Kipling, Regan and Jack.      You can also see that a service has been enabled by the name “Direct Kipling”.    This service was created to enable callers to Kipling’s DID number to be brought into the Contact Center, and routed to Kipling even though they did not enter through the TAC1 service.   Hopefully, we can now count the phone calls Agent Kipling is handling that otherwise would not be reportable!

ecc_figure_1

In Figure One we can also see that we have set an “Overflow” counter that,  should anyone be in the Kipling Queue for 10 seconds they will overflow to the TAC1 queue.  What is interesting is that when you overflow in the ShoreTel Contact Center,  you don’t leave the queue you are in, you basically add another queue containing agents that have a cumulative effect on the call.    Should that “overflow” not result in an available agent and the caller continues to wait for service, you can actually set a second timer that would “overflow” (e.g. expand the number of agents ) to yet another queue.

In Figure two, you can see the original call in the Queue for Kipling.  After the pre-configured overflow interval is met, the call is distributed to the “overflow” queue but is also available to the original queue.  You can see this in Figure Three, by noting that the call is now in queue in both the Kipling and TAC1 queue.   In this way, if an agent becomes available, in either the original queue or the “overflow” queue, the call will be answered.   Had we set up a second interval timer in the Service, we could expand the number of Agents to include the additional group specified by that timer.  This is one of the more interesting, if not misunderstood capabilities of the ShoreTel “overflow” concept!

ecc-figure-21ecc_figure-31

Call Center Design

It is very normal to start planning a call center around the concept of DNIS, Groups, Agents and Skills.  Experience has taught us, however, that call center design needs to start with a more important concept.  Call Centers are performance oriented.  We measure the number of calls presented, the number calls answered, the number of calls abandoned, average talk time, the average time a caller is waiting in queue for service and any number of other key parameters.  We want to know call disposition, agent availability and how much time was used for lunch and breaks.   Is the staff sized appropriately for the volume of calls that are arriving?  Do we over flow excess call volume from one group to another group? How often do we do this and how long did callers waiting in the original queue before this happened?  Do we Interflow from one call center to another?  These parameters are all key characteristics of a call center and the very parameters we want to measure.   For this reason, call center design should begin with the actual report that we want call center to produce in order to verify our performance!  Lets construct the report we want to use to manage our business and from this document, we can best work backwards to creating the groups, agents, skills  and Queue messages.