If you work in an enterprise IT environment as a team member you know the drill for a system down emergency. Someone alerts someone that the users are unable to access the Corporate Intranet! Panic! A ticket is initiated at the corporate help desk, and a phone call is made to the IT Director who then needs to figure out if we are having a sever failure, network failure or application failure.
The CEO, now getting phone calls from the operating executives, has now called the CIO who in turn is beating up on the IT Director and stuff starts to roll downhill. Somebody sends out a group conference line, the email stream starts up and all hands on deck are scrambling to identify the root issue.
I find the email route is just to confusing and nobody knows what the current status is as people chime in on the email, adding input and more times than not, asking for updates to pass up the line. Trying to work an issue with an open conference bridge is not real helpful and some folks did not get the email that has the conference bridge line number so key content is missing anyway.
This scenario happens way to often and we determined to find a better solution! The result is a SMS2SMS a kind of “group text” for first responders. Basically, you publish a number and have your stakeholders text the word “JOIN” to that number. This will subscribe that user to your list. Future texts sent to that number will now be copied to all other list members. Members can STOP if they no longer want to be part of the list, but generally this is an excellent solution for first responders in any emergency management situation.
Providing options for callers to you contact center after normal business hours is always a good practice. Our standard “after hours call handler” makes use of several options:
The text notification step requires some additional AWS services including PinPoint, SNS and Lambda functions. For this option to work, you will need to setup an SNS topic and make use of PinPoint to get a phone number to associate with the call block.
In the above call flow block, we invoke the lambda function when the caller selects that they want a call back from the on call team member. Lambda then interacts with PinPoint and SNS to send a canned message “an after hours caller needs help” sending both the message and the contact phone number to the SNS subscribers. This is a very effective solution for integrating SMS into your contact flows and is ideally suited to “on call” notifications.
Making the caller “comfortable” while waiting in queue for the next available agent is the primary role of a “customer queue flow”. Our standard practice is to provide a range of options that can be turned on or off as desirable for a specific CSQ. The main greeting contact flow discussed in Part 1 will attempt to hand the caller off to an available agent, but if none are available, the caller is moved to the customer queue flow.
The “customer queue flow” we typically provide does some initial setup and status checking:
Set Loop Prompts (Music and messages and time)
Check Queue Status
Check Call Back hours of Operation
Play EWT prompt
The Offer the Caller options (Wait, Voice mail and Call Back)
In our standard queue hold we check the queue status for “time in queue” of 3 minutes. We use this “poor mans” estimated wait time to provide an option to the caller if they are in queue longer than 3 minutes. We offer three options; continue to wait for next available agent, transfer to voice mail (or operator) and “call back”.
We also create a schedule for offering the call back option. When your call center closes at 5PM you may not want to offer the call back option after 4PM, so we check the schedule and if the caller is after the specified time in the schedule, we do NOT offer the call back but move to a block that only offers wait or voice mail.
You must register on the Home page to download script
This contact flow also has the ability to prompt the caller to leave a call back number. This step requires some SSML in the text to speech block as we want to confirm the number the caller entered and give them an opportunity to correct any errors. First we prompt the caller to enter the phone number we should call them back at.
The Set Contact Attribute block is used to assign the callers input to a variable we can call on later in the flow:
In this example we are setting a destination key of “numberinput” and stuffing that variable with the system provided attribute “stored customer input”. It is important to set the destination key as any further use of this block will over write the stored information which you will need to reference later during the playback verification step.
This block reads the callers phone number back to them as an SSML object as illustrated above. Note that we reference the numberinput from the set contact attribute block as $.Attributes.
Every Call Center is in fact unique, but the all share a common theme that can be encoded for recreating deployments quickly. Generally we divide Contact flows up into manageable contact flows that compartmentalize call handling. For example we generally create a MainGreeting, QueueHandling and After hours Call Handling call flow and these three basic contact flow blocks provide some very powerful options!
Generally, we attach the incoming phone number to the MainGreeting Contact flow. This flow is very important as we use it to setup all the required variables required for whatever CSQ this greeting will front end. This contact flow will usually perform the following:
Set the voice to use for Polly based prompts
Enable Logging behavior
Enable Call Recording behavior
Set Agent Hold Behavior
Set Customer Hold Behavior
Set the Queue Hold Behavior
Set the Customer Queue
Set the whisper behavior
Set the Working CSQ
Invoke Lambda function to check for special closing
Check Operating hours
Prompt and Collect Caller Input
Transfer to Flow or Queue as required
These are all critical parts of the overall call flow and set the stage for call handling throughout the rest of this callers experience. Not burdening the the contact flow with all the queue options while awaiting connection with an agent, makes the flow more manageable!
If the caller can not immediately be routed to the next available agent, they are passed into the contact flow that describes the experience the caller has while waiting including the presentation of any options the caller might elect to initiate while holding.
Sometimes it is better to give folks what they want, rather than what they need! Over the years of working with call centers you develop a sense of what is a best practice and what is something that will be nothing but a problem! You do your best to educate folks on the issues and make recommendations that you know are in their best interest. However, “if you have the peso, you have the say so” and ultimately we do what the client wants to do, right or wrong.
Such is the issue of the “forced release” status that results from an unanswered call presented to an “available” login agent. Most if not all call centers, will attempt to present a call to the next available agent based on the routing plan, generally “longest idle”, “round robin” or “top down”. The issue is what do you do if the agent does not answer the presented call?
Most all call centers will set the agent to “forced release” which does two things. First, it assures that we do not waste the callers time presenting another call to an agent that may not be present. Secondly, an agent in “forced release” alerts a supervisor to a potential staff management problem.
Recently we had a client who did not want agents put into “forced release”. Well if we do not put them in forced release what is the desired behavior? Take an CSQ with one agent for discussion purposes. If we present the call to that agent and the caller is not answered within the system Ring No Answer time, we would normally queue the caller for the next “available”agent and put this agent in “forced release”. if we do not put the agent into forced release, the call will be ping ponging back and forth between the queue and the same agent!
Ultimately it was decided that we would create a global option that would allow the administrator to set the default behavior for the call center. The default behavior is either “forced release” or, thanks to Dextr, “follow Wrap Time behavior”. In this way a call presented to an agent and not answered, would optionally be put in “wrap time” or “after work”. The Dextr application also enables the global setting of a “name” for the wrap behavior to distinguish that mode from a normal wrap period. This seemed like the best solution. This would enable the agent to return to “available” status when the wrap time or after work time expires.
One of the most challenging implementation tasks for an implementation engineer or application developer is getting the client stake holders to agree on customer audio prompts! Having implemented hundreds of call center solutions, having to wait for the client to get their IVR scripts together is the “black hole” of project management. So many other parts of the enterprise have their finger prints on the content of a customer voice prompt. From the call center managers to the legal department, everyone wants to comment on this implementation detail.
Voice Prompts can be a “speed bump” in your deployment timeline!
For the implementation engineer, it is without doubt the speed bump that slows down project readiness! Often the prompt is a source of data collection for “self navigation” through the “call tree” or IVR front end. “Thanks for calling, Press 1 for this and 2 for that” has some hard coding detail that can be easily effected by a simple prompt change!
Thankfully AWS has an embedded service that provides text to speech functionality. This means an implementation engineer can move ahead by popping prompts with text that can easily be changed as the rest of the enterprise catches up on prompt content, format and voicing. This service named POLLY, is a more than useful service and has been a life saver in more than one “instance”, excuse the pun!
Polly Programmatically?
Polly is not only useful for creating test prompts until the content and format can be reduced to a script that a professional voice artist can record, it can be used “programmatically”. For example, Dextr has an embedded application for automating closings, regardless if they are scheduled holidays or “ad hoc” closings for a team meeting called by a CSQ supervisor. Dextr will allow you to not only setup the calendar and time of a closing, but will enable you to enter the text content of a prompt to be played to the caller during the closing. This might be a custom greeting for a holiday (i.e. we are closed for Christmas, or Veterans Day) or an on the fly prompt for an ad hoc meeting.
Polly Prompts on demand!
Many times, it is necessary to create a prompt on the fly! Maybe you want to personalize a prompt by adding the callers name, or some customer specific attribute like an appointment time, or order number. Common applications like reading back a bank balance are also made more flexible by using Polly. Not just speaking back account balances, but making the call flow and content in an AWS Connect instance programmatically customized on the fly, and unique for each caller.
This strategy is a win/win for all stakeholders! It enables a more rapid deployment of a call center context while enabling greater flexibility in the design, deployment and management of prompts. Enabling Polly as a service inside your AWS Connect call center instance is an essential part of your implementation tool box and a software application development engineers best friend!
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!
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!
Setting up options for Callers waiting in Queue for “the next available representative” often include offering a call back option. Generally, it is a best practice to not offer this option immediately but queue the caller for some time before offering this option. They have already called in and you have answered the call, so let them wait a few minutes before offering bail out options.
Common Call Flow Errors!
One of the most common errors in call center call flow planning is allowing a customer caller to queue for an Agent when no agents are logged in! The second biggest error, is leaving folks in the call back queue, at 5PM when all the agents log out and go home! So how do you do make sure this situation does not happen?
As it relates to the first issue, we always check to make sure that Agents are logged in BEFORE we queue a caller! This is a very simple step to do and it saves a lot of aggravation for callers who will never forget how long you left them rotting away in an empty queue!
Now as it relates to ‘call back’ without losing your place in queue, we have the same issue. Let’s assume that you offer callers this option. It is now 15 minutes before closing, what happens if all the agents log out before the call back is next in queue?
Call Back without losing your place?
In AWS Connect, Call Backs will follow the On-hours schedule. So if someone left a request for call back at closing time, that option will not trigger until the next day when the queue is open per On-hours. Lets see if we can improve this, but NOT offering that option late in the day!
We can setup a new schedule that only offers the call back between certain hours, so that if it is near closing, we do not offer the caller this option. This can be easily scripted in AWS Connect Contact Flows by adding a “check on-hours” step that eliminates this option when callers enter the queue and hour before closing time. This assures that Agents can log out at the appointed time and not leave anybody in queue!
AWS Connect is written around “contact flows” of different types. A “contact flow” handles inbound calls and routes them to Agents in queue. A “customer queue” contact flow deals with how to treat a caller while they are awaiting for the “next available representative”. You will learn this the hard way the first time you try to add a block to a contact flow and find that, though the block was there earlier, it is not there now! Why, the contact flow you are working on, does not support this type of block.
Free Call Back Script just for Asking
In this example we use a “Main Greeting” that is triggered by a call to the DNIS number associated with this path. We start the contact flow off by setting up all the variables like what voice to use, are we logging, what queue hold to use, which queue we are using etc. The flow goes on to check operating hours – routing ON- hours to the Queue and Off-hours to the Voice Message center.
If it is “On-hours” we send the call to the Queue flow. If an Agent is available, we connect them to the caller. If all agents are engaged with other callers, we queue the call. We play our “poor mans” Estimated wait time and then queue them with a “care message” followed by Music. 60 seconds later, we offer the option to continue to hold for an agent, or press 1 to receive a call back without losing your place in queue’.
Before we offer this option, we check another schedule that determines if we should offer the call back option. If the caller hits the center during the call back hours, the call proceeds as described above. If it is an hour before closing time, we do not offer the option.
So hit us up with a request and we will send you three “Quick Start” scripts that enable you to get this working as quickly as you can import the scripts into your AWS Connect call center instance.
Better yet – Give us a call and we will set this up for you!
Recently we had a client with a very specific set of requirements and DrVoIP was able to satisfy with Dextr dashboard! The client had a ShoreTel deployment that used ShoreTel Workgroups. ShoreTel Workgroups are often called a ‘poor man’s’ call center. The client had made a decision too they were migrating away from ShoreTel to Skype for Business, they needed a new Call Center solution. Workgroups act like traditional hunt groups but they enable customer queueing and both historical and real time reporting in a manner that is very similar to a formal call center.
The client wanted to replicate ShoreTel Workgroups along with the same ‘look and feel’ as ShoreTel Workgroup agent dashboard. This dashboard enabled queue monitoring and also enabled a supervisor to change an agent state from Forced release to available or move an agent between queues. We had no doubt that AWS Connect was the ideal solution, but we knew the Connect Control Panel or CCP as AWS calls the webRTC soft phone, would need a lot of work if it was going to provide the same functionality as ShoreTel.
We created the basic Dextr Agent dashboard to have the same features and functionality as the ShoreTel Workgroup Agent interface with several new and advanced features. We needed to create a solution that would enable Supervisors to create an ‘ad hoc’ meeting and to close the call center and even create a new ‘CLOSED’ greeting. Additionally it would be desirable if the Supervisor could send a broadcast message to all the agents in the queue. This broadcast message would scroll across the agents screen, alerting all to a situation that the Supervisor wanted to bring to the attention of all Agent.
AWS Connect Holiday Schedule.
The first requirement was to setup a holiday schedule and also to allow the supervisor to create a ‘CLOSED FOR MEETING’ date and time. AWS Connect does not have this ability out of the box, but it does have the API’s available to create such a solution. So our team added this functionality! Dextr enables a user with Admin privileges to open a window and create both HOLIDAYS AND AD HOC closings. The instance is initially stocked with all US Federal holidays already listed. The Admin can modify, add or delete these dates. They can also specify, via the drop down window, which queues they are closing. There is also a Text to Speech window in which the supervisor can enter the text of a prompt that will be played to a caller should they call during that time slot.
Dextr uses AWS Lambda to test for a holiday or ad hoc closing as step one in the opening contact flow. The Lambda function brings back open or closed, a reason code and the text to speech prompt. In this way the caller might hear ‘ You have reached us at a time we are closed for <insert reason from Lambda>, please hold while we transfer you to the message center’. The entire message is created by the supervisor as the TTS or text block that will be returned by Lambda.
Dextr also enables the Supervisor to send out a broadcast message that scrolls for all queues or just a selected queue! This is a list of all the features of the Dextr Dashboard basic version;
Nothing to install! Instant Access via https://go.dextr.com which has video instructions for on boarding;
Customizable Logo;
Role based Login (supervisor, agent, administrator)
SAML support;
Agent Team Status Display;
Agent Call Activity with (click to return call);
Directory System with Click to call;
Help Button – Alert Supervisor;
Queue Monitor – including calls in queue, max waiting time; optional red, yellow tags)
Ability to set Holiday Schedules and “ad hoc” closings with new close prompt (think team meeting).
Push Announcement String out to Agent Dashboard for alerts and other notices.
Dextr augments the basic AWS Connect CCP softphone to enable advanced features that we find most call centers demand! See Dextr.Cloud or DrVoiP.COM for additional details!
