Category: Virtual Call Center

The Achilles Heel of all Cloud Based Call Centers!

Posted on by DrVoIP

The Cloud Call Center Problem Statement!

A very common call center requirement is the ability to route a call based on the DNIS number dialed.  This is simple enough when you have only a few DNIS numbers to manage, but consider this application:   Consider a central call center that provides centralized appointment scheduling for some 600+ medical offices.    The call center agents are required to answer an inbound call with a custom answer greeting that is based on the medical office that cares for that patient.   The solution in place today requires the cloud platform to have a unique DNIS for each of 600 medical offices.  When a medical office wants to take advantage of services offered by the call center, they call forward their phone to the unique DNIS number on the call center platform assigned to their medical office.   On an incoming ring,  the call center grabs the DNIS and uses that number to index a connected database to retrieve the  name of the medical office and then display it to the agents on call presentation so they can provide the custom answer prompt.

As you might imagine, maintaining and updating both the relative campaign and a database of DNIS numbers is not only a nuisance with many opportunities for an error, it is also not very scalable.  The simplest solution is the ability to normalize or change SIP Headers or obtain the RDNIS in a PRI connection.   Neither of these is an option in any of the many cloud based solutions we have worked with.

The CPE solution!

In a CPE based solution we can touch the boarder controller of the incoming SIP trunk and see the various headers.   In a PRI trunk you could also see not only the CID/ANI  but the DNIS and the RDNIS.   RDNIS is commonly used in a voice mail system for example, to know the correct mailbox to open so the caller does not hear a main greeting but a custom greeting for the mailbox owner.   In either the SIP or PRI environment, we would NOT need 600 DNIS numbers to solve this application.   We could see the RDNIS or the FROM SIP header and use that field to look up the correct answer prompt or medical office name in the database.  We did a complete tutorial on this SIP header manipulation to achieve this same solution though the application was a bit different.

One for all and all for one?

Another major shortfall with cloud based call centers is that you will find it very hard to make modifications that are unique to your call center.  Keep in mind that all the cloud based call centers, with the possible exception of AWS Connect, are solutions that encompass many different clients.   The cloud provider can not make a modification for your call center unless it is applicable to all their other clients.  Likewise, when they upgrade or add a new feature, you are getting the new feature and the upgrade regardless of your desire to participate!

Summary

The Cloud is an amazing resource but it is not a one size fits all.  You will need to understand your requirements and how they match to what is generally available from your provider.  You should also understand that you will be increasing your WAN connectivity requirements to include advanced options like Software Defined Networks and MPLS, BGP along with bandwidth increases and new firewall challenges that you would not have on a CPE deployment.   You will still have phone and video end points, power over ethernet switches, network access credentials, intrusion protection and all of the IT resources you would still have with the Call Center located on site.  There are many advantages to the cloud, but make sure you know what you are hitching enterprise with!

 

 

 

 

Building an AWS Call Center is the definition of a “Disruptive” technology”!

Posted on by DrVoIP

AWS Connect – A Game Changer!

It has been almost a year since we first took a look at the AWS Connect Call Center service and what a year it has been.   Since it’s pubic release, AWS is most likely the fastest growing Call Center solution in the global market.   The reasons for this are clear and unmistakeable.   We think AWS Connect is a game changer!   Our first experience with AWS Connect was the result of a contract to move a ShoreTel ECC to AWS.    ShoreTel had basically abandoned the ECC product with no new feature develops in several years and the product was stuck at Version 9.  Given the great unknown regarding the future of ShoreTel CPE solutions, this client made the decision to move to the cloud and we were choosen to make that move painless.

Why Move to AWS Connect?

AWS Connect is a cloud based solution that follows the AWS mantra of elastic, scalable, reliable and highly available!  There is nothing to install and nothing to license!  You pay only for ‘usage’ at a couple of pennies per minute!   One client was paying some $250K a year in cloud call center licenses before they even processed their first phone call!  On AWS Connect this same spend would yield over 900,000 7 minute phone calls!  Take that to your CFO and note the reaction!  At the AWS reInvent 2017 conference, Capital One the tenth largest American Bank announced that it had moved to AWS Connect and the list of companies grows by the hour!

The DrVoIP Challenge

AWS makes it easy to spin up a call center! In less than one hour, you can have a fully functional call center handling inbound phone calls to an agent population that can be geographically distributed anywhere on the planet that supports a quality internet connection.   More than likely, it will take you more time to upload or enter the names of your agents into the Connect dashboard then it will take to create the Connect instance and obtain a telephone number! In fact DrVoIP will build out a ten agent 3 queue inbound call center for you company to pilot in under one hour!   Just give us a shout and try us!

Customization and Functionality is limited only by imagination!

One of the challenges that the current crop of cloud based call center providers face is the need. to standardize their service offering.   If you are anyone on the Gartner Magic Quadrant, you are serving thousands of users.   You can NOT make a change to the platform as it impact every customer in that providers installed base!   If you want to add a new feature, you will have to follow that vendors “product road map”.

AWS Connect has full access to the complete range of AWS Services including Lambda functions, Speech Recognition, Text to Speech, Kinesis, Mobility,  Cloudwatch, DynamoDB and the full range of AWS Storage solutions including S3 and Glacia. (recording storage and historical reports)!   Though the base instance is easy to configure and comes fully functional with a “default” call flow, the range of potential application solutions is limited only by the talent of your implementation team and your companies vision of the perfect “customer experience”.

Artificial Intelligence?

Most of the population now carries around a personal communicator that has Siri or Alex or Google and folks have not only grown accustomed to these features, they now expect them!   Do you really expect to front end your call flow with a “touch tone” based “call tree” or IVR that expects them Press 1 for English?  Come on people!   It is the 21st century!   AWS makes Alexa like features available through a natural language chat bot named LEX.   Is it not about time your call center had a natural language interface to your customer service group?    Try asking your current provider to add that functionality and when you look at the licensing fee, if the feature is available at all, pick yourself off the floor and give us a call!

Text to Speech?

Historically, as call center scripting professionals,  we resist starting a project until all of the prompts required in the call flow have been scripted, recorded, converted to the proper wav format and made available to the implementation team.   We can’t tell you how many project hours have been burned because clients did not think out the IVR messages or record the automated attendant announcements!   AWS has a wonderful feature named Polly that can enable us to script, fill the prompts with “text” and not only have our choice of voice artist and accent, but our choice of spoken language immediately available.   We can prototype call flow announcements and make changes  on the fly without waiting for a recording to be scheduled!

Data Dips with Lambda and DynamoDB

We first got involved with AWS because as consultants, we get paid on project completion.   If we have a call flow that requires a database dip to pull back  a”custom answer prompt” and were told that we had to wait for IT to spin up a Windows Server, blah, blah, blah….we would just log into AWS and spin out our favorite LAMP server and finish the project while IT was still filling out purchase requisitions!   Now we don’t even spin up a sever!  AWS is at the forefront of “server less” technology and Lambda and DynamoDB make it possible for us to write the database functions and completely ignore what the server technology is, let alone what OS it is running on!  AWS even bundles about 1 million Lambda function calls as part of its free tier.

Limitations, ah “No”!

Every system has constraints.   We have only one constraint that we have found to date on AWS but it is the same Constraint we find in Cloud solutions like Five9 and even cloud solution provider Twilio.   We can not access the telephony side of the platform to manipulate SIP message headers of other Call Control signals.  Currently this is hidden from the AWS Connect instance.  We have however, never had this be a show stopper and have always found a way to implement a work around.    At the rate AWS cranks out new feature and services however, we fully expect to see a SIP interface that we as developers can access on the shortest product road map implementation schedule in the global market place!

We Build AWS Connect Call Centers!

DrVoIP can design, deploy, maintain and manage your call center at a cost that is arguably redefines “total cost of ownership.”   Give us a call or let us know what you are thinking and you will find us to be the most experienced group of “full stack” developers available to those seeking an AWS Connect deployment!

 

 

 

 

 

 

 

 

 

 

 

A Five9 Call Center “cloud” migration success story!

Posted on by DrVoIP

Time for a new Call Center?

Recently we had the opportunity to move a major enterprise call center from a premise based solution to a virtual call center.      Though the existing premise call center had performed faithfully for a number of years, we had lost faith in the manufacture and their reluctance to commit to a product road map that we could build on.   Call Center technology changes as often as the weather and the demand for new features that the current system did not provide caused us to search for alternatives.   Our client required advanced workforce and quality management including call recording, scoring and advanced reporting tools.   Website integrations for visual IVR and “click to call”,  Social Networking integration and SMS options were also high on our wish  list.   As the call center was expanding geographically we wanted a solution that did not require us to build a WAN to interconnect agents to a central server.   We also wanted a company with a demonstrable track record, a rich history of experience and a customer reference list of others in our industry with similar deployment challenges.

We worked with our client to do the usual due diligence and explored both premise and cloud vendor solutions.   The premise challenge was that the affordable architectures were basically centralized server applications.   So if you had Agents in California, New York and London, you would have to network  all your Agents back to wherever you put the contact center server.   We have done literally hundreds of deployments these types of  solutions,  but in each case Agents would need to come up on a quality WAN network to be under the control of the contact center servers.   CISCO has an excellent solution for geographically dispersed work groups with either the PCCE or UCCE.    These are excellent call center solutions for mixed vendor ACD or geographically dispersed workgroups, but it would be more costly than the purchase of a used Russian ICBM missile.    Additionally, the IT staff required to manage that caliber of deployment was more than our client was prepared to underwrite.   Add in the ongoing cost of ongoing server refresh,  system upgrades and other maintenance requirements we determined to focus on a “cloud”  solution.

Clearing the Clouds!

When you focus on who has the experience, the references and the credibility to pull  off a cloud based call center, the competitive playing field narrows quickly.  Every vendor has learned to say “cloud” in the last couple of years, but who has really been executing customer focused call center solutions for more than 10 years?   If you like the Gartner Group “magic quadrant” analysis, you will find about three players in the upper right hand quadrant.   During our due diligence and RFQ process,  two of the tree vendors in that quadrant changed their corporate identities through either merger or acquisition.    This caused some concern  on our part that as these new entities struggled to redefine themselves and the product lines that might result from their new combinations,  we might be at the mercy of a company that was not yet fully formed!

In final analysis we chose to go forward with the Five9 solution and it has made all the difference!

Doing business the Five9 Way

They say “pre-sale” is about as good as it gets when it comes to vendor customer care.  The Five9 team has set a new standard for both “pre-sales”  and “post-sales” by which we will now measure every other vendor relationship going forward!   Admittedly the Five9 “Enterprise Sales Director”  we worked with was absolutely astonishing in meeting our requirements and exceeding our expectations.    Always ready, prepared and available he never failed to deliver on a promise.   We went through the normal “legal man and his bag full of deal killing goodies” back and forth between company attorneys,  hammering out a Master Service Agreement but in the end both sides had come to an agreement that was fair and reasonable.

Five9 Project Implementation

Five9 assigned a Project Manager,  Platform Architect and Connection Manager within hours of signing a contract.    We had network readiness test instructions and project workbooks almost immediately.   Just as quickly we had access to the Five9 platform portal including DID numbers to build and test with while waiting for carriers to do the vaudeville act known as “porting”!  We had a goal of having the Five9 solution replicate our existing call center as a project first phase and we set a goal of achieving “go live” within 90 days.    As  you would expect the Five9 team had a number of workbooks that needed to be completed.  The existing call flow had to be documented, numbers assigned, agents and supervisors listed, MPLS circuit connectivity options ordered and database access requirements considered.

Most of us that have had to deploy large telecommunications projects know the drill.   The bottleneck is always the client’s ability to get their homework assignments in on time!   One of the early on challenges for this project was to replicate the CRM SQL database lookup we used for call routing decisions and agent screen pops on call arrival.   When moving to a cloud solution the usual ODBC connector to the local server strategy was not going to work!   We had to build out a web service front end to our SQL farm and not knowing the Five9 IVR scripting tool set gave us some concern.   The fact of the matter was, that the Five9 scripting for IVR is as good or better than anything we have worked with historically and we think we have seen them all.   Having never seen the solution before,  it took about an 30 minutes for us to create an inbound campaign complete with audio prompts,  agents profiles, screen displays and basic call  flow.   We were impressed with the breadth of functionality that could be created with the Five9 IVR scripting tools.     Again, if you have deployed even a simple iPBX, you know that at “go live” you are still waiting for the client to record the auto attendant script!   Five9 has a text to speech option that enable you to create prompts on the fly and worry about the professional voice artist later!  The Platform engineer who actually implemented the solution, managed the webservice conversion from OBDC  with style and grace.   We had it operational and tested in no time!

The Five9 platform web portal has a rich library of training materials for administrators, supervisors and agents.   Our call center supervisors were able to create agent profiles and add agents with the appropriate skills to new campaigns in no time.  Actually, it was easier to log in to the portal and add the agents than it would be to list them in the workbook and dumping it on the implementation engineer!  Agents could log in to the portal and take video training sessions that increase comfort, knowledge and reduced the jitters that come with any type of workplace change.

 

One of our early on decisions was to use the Agent Softphone rather than an actual handset.    This meant that each Agent would have a workstation with a USB headset and no other  phone hardware.   While waiting out the usual 90 day carrier window for an MPLS link to both Five9 data centers in Santa Clara and Atlanta,  we built a VPN tunnel to enable our aggressive “go live” target.   In one location we had a VPN link, in the other we used a pure Internet connection.   Truth be told the quality of the connection was so astonishing that we are no second guessing the MPLS requirement!

Virtual Contact Center “Go Live”

Again the quality of folks we worked with at Five9 was astonishing!   This was most obvious at “go live”.    We noted that several of the Five9 team members were at one time Five9 customers.  These folks were so excited about the company, product and technology that they wanted to evangelize as employees!    Our Project Manager and Solutions Architect were both former customers who now worked on the implementation team at Five9.   We had multiple geographic locations for this deployment  and the Five9 team showed up at 0500 at each location ready to work!    Their knowledge and experience was a great part of the success of our launch as both Agents and Supervisors could benefit by the many operating hints this folks could provide.    This call center is no sleeper,  handling some 5K calls a day!   The move to Five9 was painless and event free. We never lost a single call or skipped a beat in our normal daily operations!

Post “Go Live”

The Five9 project team began to transition the project to the customer service group.   As part of this process a technical account representative was assigned to the project.    This individual would be available to us for some number of hours a month to work with us on new campaigns and smooth any transition issues.   So far, all has been better than expected and the experience and overall implementation has been excellent.   We are now moving into the second phase of the deployment, something we will tackle internally as the tools and resources to do so have all been provided by Five9 expertise.    We are looking forward to implementing a Salesforce connector; integrating the corporate website with a visual IVR component and getting the outbound campaign process cranked up.

Cloud Contact Center Advantages

Some of the advantages we have found moving the call center to the “cloud” are  benefits of virtual call centers in general:

  • Elastic scalability, pay as you go.
  • Geographic Independence – Agents can be located anywhere that they have access to the Internet.  Think Business Continuity and disaster recovery.
  • Cost Allocation – Most call center expense is embedded in the general budget, with a VCC your costs are easily identified including call costs in real time.
  • Media Traffice off the WAN – Calls to the VCC are over the PSTN and not over your internal VoIP network.
  • Browser based Call Control – It is no longer necessary to push configuration files to desktops.  This also enable desktop OS independence.  Mac, Windows, Citrix whatever.
  • Freedom from and endless cycle of software maintenance, upgrades, server and desktop refresh.

Cloud Transition Assitance

DrVoIP has been deploying VoIP solutions with a core competency in geographically dispersed Enterprise Contact Centers since 1998!  We have worked with most of the solutions in the market place and regularly implement custom contact center software and scripting services for ShoreTel, CISCO and Calabrio.   If you are considering a cloud based virtual call center,  give us an opportunity to assist you with RFQ, vendor selection, design, deployment management and custom software integration.    Our experience is global, our expertise is verifiable, our projects are on schedule and always exceed expectations! – DrVoIP

 

 

 

 

In search of the Killer Contact Center Script (UCCX or ECC)!

Posted on by DrVoIP

The “Killer UCCX Contact Center Script”

After your first 100 or so Contact Center Scripts, you begin to wonder if it would be possible to generate a “killer script”!   No matter how many hours you sit with clients and do your very best to extract their call handling requirements, it just never seems to be enough! Generally, you have some block of professional hours to complete the script, test, train and turn up before “go live”.   You ask the client for their requirements and “wish list”, then prioritize the list toward the goal of getting as much done as possible within the budget allocated to the project. You no sooner get the script up and operational and the client is  asking for six options that never came up during the time you were discussing requirements. They were never even on the “wish list”!   Last time this happened to me, I determined to write a script which would have run time options for the various script extensions I have seen over the years.  Starting with a basic Generic script which had modules you could switch in and out to achieve not only increase functionality,  but efficiency in both cost and time.

Route Type?  Prompt and Collect!

Most call flow scripts can be reduced to answering an incoming call, playing a menu of options, navigating to a Contact Service Queue, finding the most appropriate human resource or managing queue handling while the caller waits for service.  Sometimes there is no menu after the call is answered, and the call is sent directly to the Queue.   At other times, we need to provide some “prompt and collect” for database look up prior to call routing. We are always looking at operational alternatives for time of day, day of week and holiday or emergency closings.   This sounds like something we could develop into a general purpose call flow script, complete with generic record prompts in the language of choice.  So the Killer Script contains a library of professionally recorded prompts and prompt segments for enabling you to assemble your own prompt!

Where are the IVR Prompts and professionally voice WAV files?

We long ago learned never to start coding a project until we had the actual recorded prompts and wav files in hand!  How many hours of development time have been squandered because an attempt was made to code without the scripts.  When the client finally delivered the actual recordings to be used in the script, they were different than the call flow we all signed off on during the requirements meeting!  Don’t do it!  Get the recordings done first.  Then and only then code your call flow!  This thinking gave way to a concept of numbered prompts!   Again, you no sooner get the project on line and “go live” and the client is back asking if they can change a recording!  Why not create a module that would allow the client to call into an IVR script, select the prompt they want to record, play it to confirm that it is the correct one, and then let them record it themselves!   I started thinking about this after the first experiences in which the client asked for special closing recordings.    The client would say something like this: “Sometimes we have a staff meeting and we need to close the queue.  We want to play a special greeting to the caller letting them know we are in a meeting.”

CCAdmin to allow supervisors to Open and Close Queue with custom Closed prompt!

So we now have a Generic Call Flow Script that has an option for a Contact Center Administration and prompt management!   The Generic Call handler offers some run time options that can be set at run time.  They include a ROUTE TYPE  (i.e., Menu, Direct, IVR or Transfer) that dictate how to handle the incoming caller.   In fact, we can change the route type based on the DNIS or ANI, so the script actually changes its call flow to play a Menu or send the caller direct to Queue with each new call.  We then created a Contact Center Administration module that would allow an authorized user to open and close a queue on demand by dialing into an IVR script.  If you closed the Queue, you were offered the option to record a new closed greeting.  Optionally, you could record any existing prompt by  entering the prompt number.   All of this done by an authorized user with a PIN number and not requiring the System administrator.

Queue management was another area in which a modular approach to scripting could enable a range of options.  Do we play “your estimated wait time” or “your position in queue is” or just play music on hold?  If they are in Queue awaiting an agent resource, do we offer them options like, “Press 1 to leave a message, 2 to schedule a call back, or continue to hold and your call will be answered…?”   Not every client wants these options, but many want the choice. How do you make that option available without burdening  the project with more develop hours?  In fact you might want these options to change based on who called or what number the caller dialed.  We determined to add a third module to our script library. We can now offer the call back option on module basis.

Clearly every call center is different. You will always need to modify your scripts.  It is possible however, to create a flexible, reusable script that has configuration options or modules.  It is also possible to make these options available at run time based on DNIS or ANI. There is no need to launch a separate script when you can reconfigure the same script on the fly to address the various call handling options required to manage a caller through a successful contact center interaction.  Ask us about our generic scripts and save yourself a ton of money while paving the way for self-managed call center flexibility as you move through your business process! DrVoIPGeneric, DrVoIPCCAdmin and DrVoIPCallBack are all available for CISCO UCCX and come with professionally recorded generic voice prompts that can be easily branded.  We also include supporting XML documents for Scheduling, Holidays and a Queue options template for changing call flow based on DNIS!

 Killer Script Overview  – Updated for 2019 Version!

The Core Root script is a single thread that enables both application level run time variables as well as “variables on the fly” through the QueueOptions.XML file.   Typically the script will be trigger by one of the DNIS numbers attached to the script.  This DNIS become strDNIS in our application and it is used to index the XML file to pull back all the variables for that specific CSQ.  One of the variables that is returned is the strApprefix value.   For example we have  “CSQ_SandBox” for testing and it has a strApprefix of “SBOX”.  This variable is prepended to objects like Queue Message Wave Files.  In this way SBOX_QueueMessage1.wav and PTAC_QueueMessage1.wav can both be represented by strApprefix+”_QueueMessage.wav” in the same script!    This also makes it possible to create Layouts that are pushed out to the agents.

The QueueOptions file contains all of the variables that you want configured for a specific CSQ.   It sets options for offering Estimated Wait Time and Position In Queue.   We offer the option of a call back without losing your place in queue.  This has a variable that can be set to enable “record a short message to be played to the Agent before you call is returned” or to disable that option and move directly to collecting the target call back number.

Route Types  (Direct, Menu, IVR, Debug)

Some CSQ’s require that the caller be sent directly to the Call Center.   Others require the caller to navigate an IVR or MENU and the option strRouteType defines these options.   If the caller is to be offered a Menu of choices the script loads the correct menu, again using strApprefix to bring back SBOX_Menu.aef at the appropriate point in the call flow.  Likewise the caller can be directed to an IVR platform before the call moves to the call center.

 

 

The Killer Script is actually a series of scripts, documents, professionally recorded voice prompts and sample XML documents that you can copy, modify or edit to suit your call center CSQ configuration goals.  All this for $295?   What a deal, your average professional service company is billing scripting engineers out a $275-$350 and hour!   If you have any scripting experience at all, you should be able to configure this script!  Optionally, we can quote a fixed project fee to install and configure it for you!

Text Us at 929-292-8100 for details!