Blog

Voice Drop for Amazon Connect August 25, 2020 by Daniel Bloy Under: Blog, Business, Technical

Several of our customers ask us ‘how can we provide agents the ability to leave pre-recorded messages on a customers’ voicemail system’. This is also known as Voice Drop.

In this article, we cover how this can be solved using Amazon Connect.

What is Voice Drop?

Many companies require the need to make outbound calls to contacts and if the agent gets a voicemail, they want to leave an automated message. This frees up the agent to do other work. Therefore when an agent gets a voicemail, after the beep, they press the ‘Voice Drop’ button. This disconnects the agent from the call, and the phone system will leave the message and then disconnect.

 

What types are messages are left?

When a system is leaving a message they are 2 types of messages that really can be left. One that uses TTS (Text To Speech), or one that uses recorded audio.

When to use TTS

TTS is great if you want to provide an automated, yet personalised experience. For example:

“Hello, Mrs Ahmed, this is Your Company leaving you a message regarding your recent order. The table will be with you tomorrow between, 9-11am. If you need to change this simply return our call”

This provides a high degree of personalization, with reference to the customers, name, item and delivery slot information. As Amazon Connect uses Amazon Polly for TTS, there is a range of languages and personalities that can be used, including the impressive NTTS languages.

 

When to use Recorded Audio

Recorded audio is great for an ‘account management’ interaction. The pre-recorded audio would be recorded by the agent themselves.

“Hello, this is Sophie from Your Company, I tried to call you today. Please can you call me back on my direct line 01 2345 6789, thank you.”

Whilst this provides less customer-specific information, the customer can call Sophie back on her direct dial.

 

Can I have the best of both worlds?

Yes, this can be achieved. There are some considerations that will come out during planning/scoping this out.

How can I achieve this with Amazon Connect?

Amazon Connect provides significant value out of the box, that enables customers to focus on the customer/agent experience. As Amazon Connect provides several APIs we can create the experiences above.

Architecture:

 

VoiceDrop Architecture

At a high level:

  • Agents will use an Extended or Customer CCP .
    • This provides the necessary UI changes for the agent to see the Voice Drop buttons
  • API Gateway and Lambda
    • This provides the ability to process the API requests that are triggered by the agent when they press the Voice Drop buttons
  • Amazon Connect
    • Providing the telephony
    • Contact flows
    • Prompts
    • APIs

The magic here is the way we use all of the above together to create the Voice Drop feature. By using the set disconnect flow action block, we are then able to ‘catch’ the customer leg when the agent disconnects from the call, and perform some additional treatment.

Simply by doing the set-disconnect flow, this will not create the experience we need, the reason being, it gets executed for every call, even if we spoke to the customer, got a voicemail or just ringing phone. And this is not the experience we require.

Enter the updateContactAttributes API from Amazon Connect. This API, allows you to update metadata about the phone call in real-time, and this is how we tell the disconnect flow, whether to play a message or simply disconnect the caller. But how can the agent set these contact attributes? Enter the Extended CCP.

 

Agent Extended CCP

Amazon Connect provides a WebRTC client that can be used within Chrome or Firefox and allows agents to make and receive phone calls, along with handle inbound chats. This softphone is called, Contact Control Panel or CCP. Amazon provides an API to be able to customise the features and capabilities of the CCP. (For more information see here: https://blog.voicefoundry.com/blog/amazon-connect-agent-desktop-improving-agent-and-customer-experience)

My personal favourite for creating an extended CCP is to use another service called AWS Amplify. Amplify provides the ability to create and host web and mobile applications with integrations with other AWS services such as Cognito (for Auth) and API Gateway. By using Amplify we’re able to build out an extended CCP like this:

ExtendedCCP

The whole bottom bar is new and provides additional features and capabilities that we’ll discuss in future blogs. So let’s see Voice Drop in action from an agents perspective

(Below is an animated GIF on loop)

VocieDrop GIF

What changes have we made?

  • We have used the Amazon Connect Streams API to listen for Outbound Contacts and then when connected present the agents 2 additional buttons
  • The 2 additional buttons allow for 2 different experiences.
    • Voice Drop 1 will play message 1 within the contact flow
    • Voice Drop 2 will play message 2 within the contact flow
    • If the agent doesn’t want to play a Voice Drop they can simply press ‘End call’
  • When the Voice Drop buttons are pressed,
    • An authenticated API call is made to the API Gateway,
    • The API Gateway validates the security and passed onto Lambda
    • Lambda reads the provided details from the client (Agent Desktop) and updates the contact attributes
    • Upon successful response from API Gateway, the extended CCP then disconnects the agent from the call. This leaves the Amazon Connect contact flow to play the required message.

As you can see this process is quick, secure and easy for the agents to follow. You are able to customise the buttons however you require, even listen to keyboard presses if needed to trigger them. It’s all JavaScript providing you with great flexibility.

 

This is just one of the many ways in which we help our clients create the agent and customer experiences they require. If you’d like to discuss this with us, please get in contact.

Thx

Dan

 

Ps. Don’t forget you Amazon Connect service quotas!

 

Connecting the Contact Center August 6, 2020 by Daniel Bloy Under: Blog, Business

2020 ushered in significant change in the manner and speed at which contact centers are adapting to new business requirements along with ever changing customer behaviors. Public and private sectors have been impacted in ways not previously seen and social distancing impacts on the contact center are far reaching and long lasting. Thankfully, Amazon Connect is front and center as a great strategic choice.

 

Social Distancing

The key requirement that spanned across all verticals and sectors was the need for social distancing. Almost overnight contact centers became a significant challenge compared to the rest of the organization.

For decades, contact centers have been designed with offices in mind, both from an operational management and security point of view. A contact center will drive a significant cost and require many different teams to support. Typically being one of the key services that IT provides to its customer (Operations).

Network, security, storage, compute, desktop are just some of the other teams needed to build, support and maintain a contact center and that’s before you add the contact center/voice team. Decades of designing, product choices, security reviews have made contact centers difficult to adopt with pace.

Thus, when faced with the requirement to social distance, companies tackled this with 4 significant approaches.

Work remotely

Those who had the existing capability were able to relatively seamlessly, support working from home or could create a way to allow remote working did so. Some organizations had to make some difficult decisions in doing so, such as ensuring compliance with PCI-DSS.

Close the contact center

Some organizations took the approach to close the contact center, the governments furlough scheme made this a slightly less difficult decision. However, as they return to operational norms, changes will need to be made to support social distancing.

Relocate / reduce staff

For many organizations, their services directly support the COVID-19 efforts and some of these organizations were able to reconfigure their offices or use other premises to maintain their services whilst adhering to social distancing.

Deploy a new contact center

Then we have those organizations that were facing office closures or needed to scale by orders of magnitude in a short space of time to provide vital front-line services. For these customers, many turned to cloud contact centers such as Amazon Connect, where 100s of agents were able to be deployed in days to support critical front line services. Such as the London Borough of Waltham Forest, who discuss their rapid adoption here: https://www.ukauthority.com/articles/waltham-forest-shifts-contact-centre-through-aws-cloud/

Channel Swapping Acceleration

Social distancing certainly drove the short term and will continue to affect the medium term strategy as the world starts its road to recovery. Another key theme I’m seeing is the acceleration of channel swapping. Some organizations turned off their voice channel and in its place offered services on the digital channels. These do not envisage a return to the norm, instead the current situation has accelerated chat as the dominate channel.

Where Next

If ‘cloud first’ were not already the number 1 requirement for a call center  going forward, I fully suspect this will be feature 1 going forward. A cloud first contact center must support the key tenants of cloud and customer demand:

  • 100% cloud
  • Enables remote working
  • Digital channels first then voice
  • Burst capacity and evergreen
  • Simple consumption based licensing (no agent licensing)
  • Self service
  • Smart devices (speakers / car etc.. aka Alexa)

During the past 2 months, our fully remote team have supported several organizations adopt Amazon Connect, the immediate need was to scale / allow working from home. However, as the dust settles on the new normal, these organizations are realizing the other benefits of Amazon Connect. What was a short term requirement, has turned into a happy strategy acceleration that has given them the ability to reform their own culture and organization around cloud adoption, which in turn will result in greater services to their customers at a price that supports the recovery from COVID-19.

As always, feel free to get in-touch. 

Stay safe!

Dan

The ultimate callback in queue survival guide June 2, 2020 by Daniel Bloy Under: Blog, Business, Technical

“Your call is important, please continue to hold”…. is this really necessary? In this blog post, we discuss what is callback in queue and how to use the valuable tool.

What is callback in queue?

Callback in queue (CBiQ) is a technology that enables telephone callers to keep their place in queue with a q-bot, also known as a virtual queue. As a customer, if you’re offered CBiQ and accept this, your phone line will disconnect. Then a period of time later, you will get a call back from the company you was contacting and speak to a representative who can support you.

 

Does Amazon Connect support CBiQ?

Yes. This is a native capability.

 

When should I use CBiQ?

In short.. with care. There are several factors to consider here.

  • How long should the queue be before I offer CBiQ?
  • How do I handle phone numbers?
  • What messaging should I use?

If you didn’t want to implement CBiQ, a good interim step is to set callers’ expectations. Within Connect you can do this by, getting the queue metrics (first block in the image below), then we check the time of the oldest contact in the queue, and based on the time we play various messages. These messages can be ever-escalating, such that you actively promote the caller to use digital channels, either way, the key here is setting an expectation.

QueueTimeFlowExample

Below is an example of the messages that you may choose to adopt. We recommend that customers deploy our Admin Portal that supports some great features, including multi-language.

MessageAppPrompts
(Screenshot of the VoiceFoundry Admin UI)

 

How much does it cost?

There is no cost of this feature. In many cases CBiQ will save money, in some cases, CBiQ could increase the costs. Let’s take a look at 2 examples to explain this:

Example of cost-saving

  • Customer calls a UK Freephone number
    • $0.030 per minute telephony charge
    • $0.018 per minute service charge
    • Total per minute charge $0.048
  • Customer queues for 5 minutes
  • Customer talk time is 5 minutes

Cost for the call without CBiQ = 10 minutes of inbound duration = $0.48

  • Customer calls a UK Freephone number
    • $0.030 per minute telephony charge
    • $0.018 per minute service charge
    • Total per minute charge $0.048
  • The customer interacts with the IVR for 1 minute to set-up the CBiQ
  • Callback completes and customer talk time is 5 minutes
    • $0.0158 telephony charge (outbound UK)
    • $0.018 per minute service charge
    • Total per minute charge $0.0338

Cost for the call with CBiQ = 1 minute of inbound duration + 5 minutes of outbound duration $0.22

The reason why CBiQ is saving money is for 2 reasons. Firstly, the customer is not waiting in queue for 4 minutes, this saves $0.19, then when the agent calls the customer back, this is now being charged at $0.0338 per minute for 5 minutes, saving a further $0.07. Making a total saving of 55%

(Note: As the Agent will call out to the customer, this impacts agent AHT (You need to account for outbound ringing time). The amount depends on if the customer answers the agent on the first attempt. You need to factor this into your own calculations!)

 

Example of cost-increasing

  • Customer calls a UK DDI number
    • $0.004 per minute telephony charge
    • $0.018 per minute service charge
    • Total per minute charge $0.022
  • Customer queues for 5 minutes
  • Customer talk time is 10 minutes

Cost for the call without CBiQ = 10 minutes of inbound duration = $0.33

  • Customer calls a UK DDI number
    • $0.004 per minute telephony charge
    • $0.018 per minute service charge
    • Total per minute charge $0.022
  • Customer interacts with the IVR for 1 minute to set-up the CBiQ
  • Callback completes and Customer talk time is 10 minutes
    • $0.0158 telephony charge (outbound UK)
    • $0.018 per minute service charge
    • Total per minute charge $0.0338

Cost for the call with CBiQ = 1 minute of inbound duration + 5 minutes of outbound duration $0.36

The reason why CBiQ costs money is due to the increase in Telephony charge for outbound calls, compared to inbound calls. In this example our invoking of CBiQ caused an increase in costs. Making a total cost increase of 10%.

(Note: As the Agent will call out to the customer, this impacts agent AHT (You need to account for outbound ringing time). The amount depends on if the customer answers the agent on the first attempt. You need to factor this into your own calculations!)

(Note: Pricing for telephony is here: httpss://aws.amazon.com/connect/pricing/, as always understand your own requirements)

Best practices for implementing CBiQ.

If you decide to implement CBiQ, there are a few things you need to consider.

  • Messaging, this is vital, setting the customer expectations is Job 1!
  • Only offer CBiQ between a certain queue length
  • Only offer CBiQ if you’re going to call them back during the current day
  • Implement a re-dial strategy
  • Allow your operations team to manage turning off CBiQ
  • Decide which number you want to call back the customer on
  • Set expectation again after setting up the CBiQ

Messaging, this is vital, setting the customer expectations is Job 1!

When you have long queues, tell your customer. But do this with a dynamic message that gives them an idea of how long they will need to queue for. With this expectation set, then immediately offer them a callback. “Hey there, we are currently experiencing queues of up to 5 minutes, we can keep your place in the queue and call you back. Would you like us to do this?”

You can choose to use Natural Language or DTMF or Both!

Only offer CBiQ between a certain queue length

If your queue length is less than say 3 minutes, then tell the customer the queue times are up to 2 minutes and then place them into queue.

If your queue lengths are over 3 minutes, then set their expectation and offer them a CBiQ.

You may decide that at a certain time (15/30/60 mins?) that you don’t offer CBiQ and instead prompt other channels (If this is the norm, why not look at automation/self-service capabilities)

Only offer CBiQ if you’re going to call them back during the current day

Only offer a CBiQ if you will actually be able to call the customer back that same day. Therefore you need to monitor 2 items, the time of day and the queue length. If you close at 9pm and the customer calls at 8:45, then I wouldn’t offer them a callback, keep them in queue even if the queue is over the 3 minutes as suggested above. My rule of thumb is to have the CBiQ closed 30 minutes prior to the closure of the Contact Centre/Queue, but this is your choice.

If the customer calls in at 8:15 and the queues are 50 minutes long, then don’t offer a CBiQ, it sounds simple, but you have to plan for this in your Amazon Connect contact flows.

Decide which number you want to call back the customer on

Now that you’ve offered your customer a CBiQ, what number do you want to call them back on? You have 2 choices here:

  1. Offer to call them back on the number they called in on
  2. Offer them to enter a number to be called back in on

Or you can mix and match, my suggestion here is to do something like this: “We can call you back on your phone number ending 1234, or we can call you back on a different number” the customer can be asked to press 1 or use natural language. However playing back the last 4 numbers of the phone number, is a nice touch (note this requires a small amount of lambda code to make this happen).

Note: In all cases the number from the ANI or provided by the caller needs to be checked that it can be dialed from your Amazon Connect instance. This includes restrictions placed by soft limits.

Implement a re-dial strategy

OK, so your customer has accepted, how do you configure the system to dial the customer? this is completed within the ‘Transfer to queue” as seen below:

transferToCBiQ

  • Initial Delay – This is the amount of time you want Connect to wait before placing the callback into the queue.
  • Maximum Attempts – How many times do you want Connect to attempt to connect to the customer (If you get to voice mail, this is deemed connected, train your representative to leave a voicemail)
  • Minimum time between attempts – If you have Maximum attempts greater than 1 then this is the time Amazon Connect will wait before putting the next attempt back into the queue.

Allow your operations team to manage to turn off CBiQ

CBiQ should be controllable, we’ve spoken about how to offer CBiQ and using opening hours to schedule the feature. You should also allow your business operations team to have the ability to over-ride the system and turn off CBiQ. This will not prevent those currently in queue, but it will mean your next callers will not be offered CBiQ. You may want to do this due to a change in call behaviours, maybe due to system issues that drive increased calls and you need to provide a quick message to customers.

As I mentioned in the ‘How much does it cost’ section, when an agent receives a CBiQ offer Connect will then dial out to the customer, this delay increases AHT (If the caller answers in 15s, then maybe your AHT has increased by 20s for that call (allowing 5 seconds for the caller to greet and start the conversation)).

 

Set expectation again after setting up the CBiQ

Once Connect has accepted the CBiQ, the right thing to do is again set the callers expectation on when they should be receiving a callback. This follows the same process as we did in the section earlier when the caller was first offered CBiQ.

QueueTimeFlowExample

 

Reporting considerations

Reporting within the contact centre is very important when implementing CBiQ, you may need to change the way you implement the capability based on the requirements. As such ensure full understanding of the requirements and test any changes prior to rollout.

It is recommended to create specific queues for callbacks, this has 2 benefits:

  1. Reporting, these callback specific queues will show you your queue depth, longest queue, AHT performance etc…
  2. You can be assigned callbacks to certain agents, or have agents that only handle callbacks.

When creating these additional queues, you can call them as you wish, I find that appending ‘:CB’ is a good approach.

queues

Now that you have your callback dedicated queues, when transferring to the queue you need to enable the ‘Set Working Queue’ option as shown below, and then set your working queue.

setCallbackQueueTransfer

Real-time reporting

Now that your Connect instance is set-up correctly, on the real-time and historical reports you’re able to see the queue performance as such:

  • Scheduled, are callbacks are in the system but cannot be answered by an agent. This happens in 2 scenarios, 1) If you set an initial delay, the contact will be in this state for the duration of your initial delay. 2) If the first attempt didn’t result in a connect, then the minimum delay timer starts, during this timer the contact will be in this state.
  • In queue, are callbacks waiting for the next available agent
  • Oldest, is the time the longest callback that has been In queue.

Contact Trace Records

CTRs will likely form of your external reporting requirements. When using CBiQ, you will get multiple, yet linked, CTRs for the contact. For a callback, you will have at least 2 CTRs

  1. First CTR will cover the INBOUND contact from the customer, this will include the IVR journey, and any queue time before being turned into a callback. Once a callback has been generated a second CTR is created.
  2. The second CTR covers the queue time awaiting an agent, and then once connected to the customer the duration.

Note: you may get a 3rd or 4th depending on if the callback was not connected and thus re-attempted at a later date.

How do I prevent duplicate CBiQs?

Great question. Customers will call in, request a CBiQ and then if their expectations are not met, they then call back in again. They will be offered another CBiQ and thus this needs to be prevented.

To do this, once the customer has requested a CBiQ, this event is written to a database, then when the caller calls back in, we tell them upfront, that they are pending a callback and that they need to be patient and that their callback will maintain its place in the queue.

This requires some custom code to implement, here is reference code by AWS: https://aws.amazon.com/blogs/contact-center/preventing-duplicate-callback-requests-in-amazon-connect/

 

Can I stop a CBiQ?

Currently, you cannot. Once a CBiQ has been placed, there is no management ability of those CBiQ’s in flight. They must be sent to an agent for the queue to be drained.

 

Can a customer request a scheduled CBiQ?

This is possible and for another blog 🙂

 

In Conclusion,

Callback in queue is a very powerful feature that needs to be well-considered, making sure it’s right for you as a business and right for the customers is unique to you. Used well it has great benefits and value to all parties. Used incorrectly this can frustrate your agents and customer. As always, we’re here to support so feel free to contact-us.

 

Contact Flow Log Analysis with CloudWatch Insights February 18, 2020 by Joseph Mumford Under: Blog, Business, Technical

So, you have your Amazon Connect Contact Center setup and live.  With the Real-Time and Historical Reports available in the Connect Console, you’re able to see all the calls coming and going, which queues are full or empty, and which agents are busy or available.  Here we can understand your caller’s experience once they have left your IVR and are either waiting or dealing with an Agent.  But what about their experience within the IVR itself?  How often are they following a particular menu option?  How often are they experiencing system errors caused by Lambda functions?  What about their interactions with Lex Bots?  Or entering information with their keypad?

Your Amazon Connect instance can provide you with this data in the form of Contact Flow Logs.  You can use Contact Flow Logs (CFLs) to analyze your caller’s experience in your IVR since each block in your Contact Flow is being processed and logged, both with input parameters and process results.  These logs can then be viewed in the CloudWatch Console by selecting Logs, then Log Group for your Connect Instance.

The more volume your Contact Center handles, however, the more difficult it will be too look through the standard CloudWatch Log Streams.  The CloudWatch console organizes log entries by timestamp, which means that concurrent calls will be all mixed together.  While there is some filtering you can do with the log streams, there is a great tool available to us where we can better search and analyze CFLs using a “purpose-built query language.”

From the CloudWatch Console, you can access the CloudWatch Insights service which provides an interface where you can select one or more Log Groups to search through.  Queries can be added to a CloudWatch Dashboard and Query results can be exported to CSV files.  With this, we can easily search through CFLs regardless of call volume and within any time periods, we desire.

We should note that Contact Flow Logs are not enabled by default.  You must first navigate to your instance in the AWS console, click “Contact Flows” on the left-hand side. 

At the bottom, you will see a checkbox to “Enable Contact flow logs.”

Check this box, click “Apply” and note the destination Log Group for your logs. 

Also, Contact Flows do not log data by default.  For each Contact Flow, you must add the “Set Logging Behavior” block and ensure the value is enabled. 

There are some situations in which you may not want logging enabled, such as a caller entering personal information, so you must be careful when enabling and disabling logging.  This data will be accessible to anyone with CloudWatch dashboard access unless certain IAM permissions are set.[CA1]   Check out [CA2] https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-identity-based-access-control-cw.html to learn more about CloudWatch Console access.

CloudWatch Insights is not a free service, it costs $0.005 per GB of data scanned.  For more information, check out https://aws.amazon.com/cloudwatch/pricing/.

A Quick Look at CloudWatch Insights

Here is the CloudWatch Insights page, which can be found under Logs on the left-hand side menu on the CloudWatch Console home page.

The top drop-down is where you will select the log group(s) you want to query.  For Contact Flow Logs, you’ll choose your Connect Instance, which will have the following format: “/aws/connect/{instance-name}.”  To the right of the log group selection, you will want to specify the date range in which you want to query.  Like with most AWS services, you can select a variety of periods from 5 minutes to 4 weeks or any custom time frame.  Help is also available on the far right of the console.

Below the Log Group, you will see the Query Editor.

This is where you will be able to enter your query to begin analyzing your CFLs.  The editor provides some helpful code completion.  When your query is ready, just hit the “Run query” button and wait.  Depending on the time frame you specified, it may take a few moments to run, the more data that needs to be scanned, the longer the time it takes.  If there is any problem with your query, the editor will let you know before it starts to execute the query.  The results will be populated in the box below the timeline.  The timeline can give you a quick visual indication of how many log messages your query returned in your selected timeframe.  You can also see exactly how many records were returned along with how much data was scanned and the scanning speed below the timeline.

Once you have your results, you can freely expand the logs as needed to get further details and look at the results directly. 

You may also click the “Actions” button to reveal several export options if you want to pull this data into a different program.  You can also add your query to a CloudWatch Dashboard in order to keep everything together in the same place. 

The CloudWatch Insights console is easy to use and understand and makes looking through logs much easier than the standard Log Stream output.  Now let’s learn more about the logs themselves and how we can query them specifically for Amazon Connect.

Contact Flow Log Type

Let’s first look at the structure of CFL.  The following is a real example but with a few details redacted.

There are five standard attributes for all CFLs which I have listed below.  The timestamps are in UNIX format and CloudWatch Insights has helper functions to translate to friendlier formats if needed.

  • @ingestionTime is the timestamp the log was actually received and consumed into CloudWatch.
  • @log is the name of the Log Group.
  • @logStream contains the Log Stream name for that specific period of time.
  • @message contains the unparsed JSON log data.
  • @timestamp contains the event timestamp for when the log was added to CloudWatch. 

Below these standard attributes, you can see that the JSON data contained in the @message is broken out into easily read and searchable fields.

Basic Contact Flow Log Queries

The queries below help address common scenarios in CFL analysis.  Once you get the hang of the commands and syntax, you’ll be writing your own queries with no effort!

Default Query

This query is the default, which appears when you first load the Log Group.  It shows the logs in descending order and limited to the last 20 log messages.  We’ll use this as a starting point for the following queries but remove the limit keyword.  Note that all the syntax commands start with the “|” (UNIX-style pipe character) at the beginning of the line; this is required.  You may also write comments by using “#” at the beginning of the line, which will be ignored by your query.

Get All CFL’s for specific Contact Id

This query will retrieve all CFL’s for the specified Contact Id displayed in order by timestamp.  This is the entire journey of the caller through your Contact Flows up until they are connected to an Agent.

Count Unique Calls

This query will return the number of any call which generated some type of logging.  This will not necessarily return the number of calls to your Connect Instance, only those where logging is enabled.

Find Lambda Errors

This query will return all logs where a Lambda Function Module returned an error.  This will help you identify why a Lambda failed by returning the list of parameters sent.  You can see if it was an isolated incident or a general trend under certain conditions.  The full error message is “The Lambda Function Returned An Error.”

Find all Specific Lambda Invocations

This query will return all logs for a specific Lambda Function.  You can see the Parameters sent to the Lambda Function and the Returned Results for each invocation logged.

Find all Lambda Invocations with Specific Parameter Value

This query will return all logs for the specified Lambda Function where the Parameter is equal to a certain value.  In this example, the Parameter key is “Group” and the value is “Sales.” 

Count Unique Calls hitting Certain Call Flow

This query will return the total number of unique calls that journeyed through the specified Contact Flow.  This is useful if you want to determine the percentage of callers that go to a certain Contact Flow based on Menu Options, for example.

Count how many times a user pressed an option in a Get User Input Block

This query will return the number of times a specific option was selected on a Get User Input Block.  In this example, we want to know how many callers selected option 2.  Get the total number for all other options to compare which option is most popular.  Also, you can swap out “GetUserInput” with “StoreUserInput” since those blocks work in similar way.

Count how many times an attribute was set

This query will return the number of times a specific Contact Attribute was set.  In this example, we want to know how many times callers wanted to check their current account balance in a self-service Contact Flow rather than be directed to an agent.

Contact Flow Module Types

Here is a handy reference for Contact Flow Module Types with their respective Connect Blocks.  Most are obvious but there are a few differences between some of them.  Note that, for example, the SetContactFlow and Transfer module types are used by several different Connect Blocks and actual type is passed a Parameter to the module, available in the CFL details.  When searching for a specific Connect block in your CFLs, use the specified ContactFlowModuleType.

Conclusion

I hope with this information you can start using CloudWatch Insights to quickly analyze your Contact Center experience.  By learning a few commands, you will be able to get valuable information about how your IVR’s are being used by callers and pinpoint any errors or issues that they might be encountering.  This service is a must for Contact Flow development and troubleshooting.

For more information regarding CloudWatch Insights, check out the great documentation at https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html.  There you can learn more about the commands used throughout this post and additional operators and helper functions available.

Please reach out to us and thanks for reading!

Joseph

Amazon Connect Improvements Big and Small February 5, 2020 by John Sawyer Under: Blog, Business, Technical

The release of Amazon Connect in 2017 was revolutionary for contact centers. Since then, AWS has made a steady stream of improvements. One such improvement, made without fanfare, was the speed with which you can iterate on Contact Flows.

Previously, when publishing a change to a Contact Flow, you would need to wait sixty seconds before calling in to test your changes. Now, with the addition of the Published version drop-down, you can click Published until you see the new timestamp. Sometimes it is instantaneous; sometimes, it takes a few clicks.

 

 

While testing whether this is always the case, I found that more significant changes could take a little bit longer. For the test, I used a stopwatch and had my phone unlocked with the number ready to call while checking for the new timestamp. In cases where I added multiple Lambdas and Set Contact Attribute blocks, it took as long as 5 seconds after the new Published version appeared before the changes were reflected in my call. Little changes like the text in a Play Prompt block had no delay.

Building a fully scalable contact center in Amazon Connect was already quick, and this small change makes it even faster.

Significant changes are also on their way. Plug and play machine learning analytics with Contact Lens and the super life-like Neural Polly Voices are both in preview now and will be released later this year.

Amazon Connect Chat January 16, 2020 by Dylan Allen Under: Blog, Business, Technical

AWS announced Chat for Amazon Connect just before re:Invent 2019. This is an exciting new channel that integrates seamlessly with the Connect ecosystem. This update includes a new CCP that allows agents to manage both phone calls and chat sessions from the same CCP interface. Chat flows can be designed in the same way that you design call flows in Connect. This allows you to collect information with integrated Lex bots and make routing decisions based on that information before routing to an agent. VoiceFoundry has developed a demo experience that leverages the benefits of this new channel while adding custom integrations into our client side website and agent CCP.

VoiceFoundry Connect Chat Demo

We built a custom client side chat widget using the AmazonConnect Chatjs library, and a custom agent CCP wrapper using the connect streams API. In our example, the user is logged into our website, and we are able to pass user data to the chat session when initialized. The initial interaction is with a Lex bot designed to handle a few intents.

Lex Integration

The first Lex intent demonstrated in the video is payment information, which will send the user’s recent payment info back when triggered. Next is a new claim intent. When this intent is triggered, the chat flow moves to a new Lex bot that gather’s information about the incident, and then walks the user through uploading images of the incident. Once this is complete, the user is transferred to an agent.

Agent Experience

When the agent accepts the chat, the information gathered by the Lex bots is visible in the custom CCP that VoiceFoundry developed, along with the images uploaded through the website. This gives the agent the opportunity to review and validate the info or gather more info.

 

Contact Flows & Metrics

Connect chat flows are designed through the same UI as call flows, and there are new blocks added for the chat experience such as wait and set disconnect flow. The other blocks have been updated to work with chat as well. Chat transcripts can be saved to S3, and the CTR records can be streamed Kinesis for external data storage and analysis. The chat channel also records metrics which are available in the Connect UI and through the aws-sdk.

You can read more information on configuring Chat in your Connect instance in this AWS article on Reaching More Customers with Web and Mobile Chat on Amazon Connect.

Recap – A Look Back at Recent Amazon Connect Announcements January 14, 2020 by Daniel Bloy Under: Blog, Business, Technical

The last few months in the Amazon Connect world have really been a whirlwind. We had Salesforce’s annual conference Dreamforce in November, quickly followed by AWS’s own annual conference re:Invent in December. And Amazon Connect appeared in both keynotes by each respective company’s CEO. This is truly an incredible journey for a Contact Center platform that will celebrate its 3rd birthday this year!

In this blog we’re going to touch on 3 stand-out announcements, starting with the news that Salesforce+Amazon Connect are set to drive AI powered agent assistance and continuing with information about Amazon Connect Chat and Amazon Connect Contact Lens. There were many, many more announcements and I’ll provide links to them at the end of this blog.

TIP: Sign up for our free 1 hour virtual webinar where we will demonstrate Amazon Connect and Contact Lens.

Dreamforce – Salesforce + Amazon Connect

Salesforce is a powerhouse in the CRM arena and with over *19% of the market, they are continuously driving innovation and solving problems on a global scale. The Dreamforce keynote was a marvel of vision and strategy coming together to drive real business and customer value. And one of the announcements from the keynote was about Service Cloud Voice, powered by Amazon Connect.

The product brings Salesforce and Amazon Connect together in ways never seen before. It provides real-time translation of the voice conversation between the customer and the agent, takes that transcription and using natural language processing, drives AI powered suggestions to the agent.

Stephanie Buscemi got the honors of announcing this **new offering, but not before Marc Benioff had these words…

And now this incredible AI powered case generation, we’re going to see something incredible…

Marc Benioff – Dreamforce keynote 2019

To really bring this to life, watch this 5 minute section from the keynote.

*Source: https://www.gartner.com/en/newsroom/press-releases/2019-06-17-gartner-says-worldwide-customer-experience-and-relati

**Available Summer 2020

Amazon Connect Chat

Chat is by far the most requested feature I see from customers and here at VoiceFoundry we are super excited to see this feature land. Amazon Connect Chat is the second communication channel that is natively supported by Amazon Connect.

Amazon Connect Chat uses the same routing engine, customer experience flows and reporting as Voice. This means your have a true omnichannel contact center, with all the intelligent routing capabilities that is provided by Voice. An agent can take Voice and/or Chat contacts all through the same browser based softphone application.

GIF showing the softphone for Voice and Chat

Amazon Connect Chat can be hosted on your own Website or Mobile App, providing both Synchronous and Asynchronous Chat. You can configure your customer with the ability to self-service by using Amazon LEX. This lets NLU understanding comprehend the customers request and allow self service.

If your bots are not able to handle the customer’s query then you can route the customer to one of your agents.

Reporting for Chat contacts seamlessly integrates with the existing reporting capabilities of Amazon Connect, along with the transcription.

Sample transcript

Amazon Connect Contact Lens

Another keynote, another ground breaking announcement, this time related to Amazon Connect Contact Lens. It was the turn of Andy Jassy during his keynote at re:Invent 2019 in December to share the news.

Contact Lens for Amazon Connect is a set of machine learning (ML) capabilities integrated into Amazon Connect. With Contact Lens for Amazon Connect, contact center supervisors can better understand the sentiment, trends, and compliance risks of customer conversations to effectively train agents, replicate successful interactions, and identify crucial company and product feedback.

https://aws.amazon.com/connect/contact-lens/

Contact Lens is an out of the box feature of Amazon Connect. You choose which calls you want to run the advanced analytics on, and the system will automatically transcribe the conversation between your customers and agents. Running those transcriptions through Amazon Comprehend to provide sentiment analysis (Positive, Neutral or Negative) then allows you to quickly and easily run advanced searching on those transcriptions.

See the section of the keynote by Andy Jassy

Do you want to find all calls where the customer sentiment is very positive and they mention your competitor? Or search for all calls where the agent sentiment was negative – and so was the customers when talking about a product/service of yours? Contact Lens allows you to do this with ease!

Automated Transcription

If you want to know more, register for our free 1 hour Webinar happening later this month where we’re going to focus on Contact Lens.

Encore

The last 2 months of 2019 saw a flurry of announcements. We will look at the 3 mentioned above with even more detail on a later Blog and will also examine some of the important news shown in the list below.

Conclusion

Amazon Connect celebrates its 3rd birthday in 2020! 2019 was an incredible year for Connect and 2020 is shaping up to be just as special. Here at VoiceFoundry we live and breathe Amazon Connect – it’s our passion. No project is too small or too big so please feel free to get in-touch with us.

Dan

VoiceFoundry Achieves AWS Public Safety & Disaster Response Competency December 4, 2019 by Kimberley Drobny Under: Blog, Business

As we close out 2019, we can look back at some of the year’s most extensive disasters, from tornadoes touching down in the Midwest to fires on the West Coast to some of the most powerful hurricanes along the Eastern seaboard. It seems there is no shortage of tragedies that test our resilience.  For those that must respond in a disaster situation, the ability to communicate is critical.  Communication systems can be tested and pushed to the limit and contact centers can quickly become overwhelmed as they attempt to meet the needs of callers. 

VoiceFoundry is focused on disaster response services, ensuring the availability of mission-critical contact center functions.  With the scalable, flexible and comprehensive capabilities of Amazon Connect, businesses can be assured that in the event of a natural disaster or human-error-related outage, it is still “business as usual” for customers.  This approach qualified VoiceFoundry to recently achieve the Amazon Web Services (AWS) Public Safety and Disaster Response Competency. 

With a comprehensive disaster response practice, VoiceFoundry is dedicated to supporting efforts to prepare and respond in the event of a disaster or unavoidable set of circumstances that might affect contact centers.  We are uniquely focused around customer experience, customer facing and contact center assets that leverage Amazon Connect and AWS services to ensure mission-critical support.  Our practice includes architecture planning, design, deployment and operational management of Amazon Connect and AWS services in support of a disaster response situation.  Our process includes a broad analysis of hundreds of impacting elements including integrations, global scale, human asset engagement, speed for conversion and economic impact.

AWS Competency Programs highlight AWS Partner Network (APN) partners who have demonstrated either a technical or proven customer success in key critical solution areas.  The achievement of the AWS Public Safety & Disaster Response Competency certification differentiates VoiceFoundry as an APN member that demonstrates technical proficiency and proven customer success implementing workloads focused on Disaster & Public Safety Operational Tools. To receive this designation, APN associates must possess deep AWS expertise and deliver solutions seamlessly on AWS.

VoiceFoundry is proud to be part of this newly launched competency in support of our customers that may require a quick approach to disaster response in order to ensure public safety.   Our business is driven to ensure the best customer experience in a contact center environment that leverages Amazon Connect and AWS services to ensure mission-critical support.  With over 100+ years of cumulative experience delivering exceptional contact center solutions and a rapidly expanding global presence, VoiceFoundry makes it easy for customers to quickly and effectively deploy or migrate to Amazon Connect for their contact center.  Click here for more information on VoiceFoundry’s Disaster Response Services.

Powerful Partnership Creates Powerful Customer and Agent Experiences November 19, 2019 by Kimberley Drobny Under: Blog, Business

There are many familiar and powerful partnerships – Batman and Robin, peanut butter and jelly; each partnership brings to mind the reasons why we love to see them together. The affiliations represent power, strength and the ability to solve a major problem the world might be facing.  In this case,  the newly announced partnership between Salesforce and Amazon Web Services is absolutely a match made to drive transformation in the contact center marketplace.

This partnership creates the ultimate in customer experience and promises to cause a disruption in the contact center market, the likes of which we have not seen in years. This combination is forcing a dramatic shift in the contact center landscape allowing the delivery of friction-less customer experiences.  Tight integration of Amazon Connect with Salesforce Service Cloud Voice allows customers to quickly integrate these two major services in order to meet the demands for a simple, unified and intelligent service experience.  The approach for a more unified customer and agent experience places phone, digital channels and CRM data in one central console.  From customer to agent interactions and all that is in between, the power of these technologies coming together in a more effective way sets the stage for a new approach to customer experience.

Why is this so important to us here at VoiceFoundry?  It’s simple.  We are one of the very few organizations in the world that has partnered with both Salesforce and Amazon Connect as a premier integrator.  The team at VoiceFoundry is passionate about the customer experience and our business is built on the design and delivery of solutions leveraging Amazon Connect and its many related services to drive a new level of customer engagement.  We look forward to working with this dynamic team in order to help customers create the next generation contact centers.

To find out more about how VoiceFoundry can help you take advantage of this powerful partnership, Contact Us today or check out our Salesforce CTI Integration page for more details.

To read more about the Salesforce and Amazon Web Services strategic partnership, click here.

Distance Makes the Heart Grow Fonder…But It’s Bad for Your Customer Experience! October 15, 2019 by Daniel Bloy Under: Blog, Technical

In an earlier Blog post we discussed the Architecture of Amazon Connect in some detail.  We concluded that a contact center does not have to be big and complex or take years and lots of dollars to create.  But what we didn’t talk about is where you should build your Amazon Connect Instance.

Just in case you’re new to Amazon Web Services (AWS), let me introduce some basic concepts before we move on.

Availability Zone (AZ)

Availability Zones (AZ) give customers the ability to operate production applications and databases that are more highly available, fault tolerant, and scalable than would be possible from a single data center.  Currently, AWS maintains 69 Availability Zones around the world – and they continue to be added at a fast pace.

Regions

Regions are made up of 2 or more AZs.  With this arrangement, AWS can provide “as a service” applications such as S3 (simple storage service) and Amazon Connect at a higher level of resilience. And you’re able to run your servers across 2 AZs, load balanced and highly resilient.

As the map below shows, regions are located across the world.

AWS Region Map Oct2019
AWS Region Map Oct 2019

With AWS you’re able to use services in any region. The typical approach is to use a location closest to your customers so you can provide the best experience.

Amazon Connect is provided “as a service” within the following regions as of October 2019:

  • N.Virginia
  • Oregon
  • Tokyo
  • Sydney
  • Frankfurt

The impact on voice quality

Moving data around the world is a vast and complex topic that I certainly take for granted. There are many elements that can impact voice quality such as:  headset, computer, local network (wireless/firewall etc.).  The distance between your agents and your customers also has an influence.

Distance typically means more latency. Latency is the time between when your customer says something to when your agent heard it.

Latency targets

When using online chat, SMS or social media, latency has minimal impact.  If it takes 1 second for a chat message to get to an agent, it’s not even noticed. However, 1 second in the voice world creates a very bad experience. 150ms (milliseconds) is the magic number for voice (or 300ms RTT).

For more information on latency, visit: https://www.itu.int/rec/T-REC-G.114-200305-I/en

Impact of high latency

With 150ms being the upper boundary for high-quality conversation, 250ms is the upper boundary before we start experiencing significant quality impacts. This manifests itself in cross-talk. We have all likely experienced this when you talk over one another as you’re not sure if the other person has finished their sentence.

This leads to a bad experience and a frustrating conversation.

What can you do?

Plan, plan, plan and test, test, test.

In this Blog we’re only covering the placement of an Amazon Connect Instance.  However, the other factors involving the headset, computer, local network mentioned earlier are equally as important.

You should fully understand where your customers are located as well as where your agents are. I like to put the Amazon Connect Instance closest to where customers are found, however, there are many factors that may impact this decision.

Some Latency stats

You can get WebRTC stats by using the built-in Chrome tools. Place a phone call to your agent and navigate to chrome://webrtc-internals/ in a new tab. From my office WIFI in the UK, the images below show some test latency graphs (round trip times):

ConnectLatencySamples
ConnectLatencySamples

The example shows that from my UK office, on WIFI to Amazon Connect in Frankfurt, I was getting an RTT of 60ms, thus a one-way latency of around 30ms.

Customer Location

Customer location needs to be taken into consideration. You may have edge cases where customers will be traveling on the other side of the world. The latency is going to be higher for these edge cases than your norm. Factor this into your decision/testing.

Where to install Amazon Connect

Use Case 1

Customer Location: UK

Agents Locations: UK

Chosen Region: Frankfurt

Reasoning: This is the local region for EMEA.

Use Case 2

Customer Location: US

Agent Locations: US/UK

Chosen Region: North Virginia

Reasoning: Latency between US and UK regions is around 75ms allowing us to use a single Instance.

Use Case 3

Customer Location: AUS / UK

Agent Locations: AUS / UK

Chosen Region: Sydney and Frankfurt

Reasoning: The latency for a UK Customer to talk to a UK agent via Sydney is too great. Having 2 instances will require planning at the telephony layer and potentially data amalgamation in the back-end.

Other considerations

Some services such as LEX, Transcribe and Comprehend may form part of your solution, however, these may not be available within your chosen region.

Tools to help you

AWS Region Map: https://infrastructure.aws/

Connect Latency Checker: https://s3.amazonaws.com/connectivitytest/checkConnectivity.html

Troubleshooting guide: https://docs.aws.amazon.com/connect/latest/adminguide/troubleshooting.html#common-ccp-issues 

Inter-Region Latency: https://www.cloudping.co 

Know your customer and agent demographic!

In conclusion

The global infrastructure of AWS provides many great choices for deploying Amazon Connect. With the ability to create an Amazon Connect Instance within a few minutes you are able to rapidly test & learn, with almost zero cost. With a few upfront checks, you can set up your deployment for success.

Cloud Migration – Build on the Opportunities October 10, 2019 by Donna Penwell Under: Blog, Business

While creating the vision for your Contact Center in the cloud, businesses have an opportunity to consider other elements that can be added to improve the customer experience. Evaluating applications and services that can add value to the way customers interact with your company will keep them satisfied and ultimately, impact the company’s bottom line.

(more…)

Cognitive CX -AI Powered Insights and Amazon Connect September 23, 2019 by VoiceFoundry Under: Blog, Business

VoiceFoundry’s Luke McNamara has previously written a Blog about the power of using AWS Lambda to access customer data. It’s one of a number of cloud services that make up Amazon’s Cognitive CX suite.  Luke continues his examination of the advances being made in the traditional contact center technologies, utilizing his 20 years in the industry to view the move from basic call centers to omnichannel customer experience platforms.

In this Blog Luke asks:  what would you do if your contact center could easily query your customer data?  For him, Cognitive CX it is about being able to easily access customer and operational data and use it to provide smart customer experiences.  It’s what marketers are constantly striving to achieve – providing a one-to-one personalized experience for each customer.

Continue to read his insightful thoughts on Cognitive CX here.

Contact Center Agent Notification – Secondary Ringtone August 20, 2019 by Joseph Mumford Under: Blog, Business, Technical

What happens when a Contact Center agent has their headset plugged in but steps away from their computer and then receives a call?  Or if the agent misses the browser notification that pops up at the bottom of their screen?  Wouldn’t it be nice to enable an additional notification ringtone that plays through a different audio source like your computer’s speakers?  If you are already utilizing a custom Contract Control Panel (CCP), the changes needed are minimal and don’t require altering how the CCP works.  Read on to see how!

Pre-requisites

  1. You will need to have a Custom CCP script that can easily be made by following the instructions at https://github.com/aws/amazon-connect-streams.
  2. Ensure your Custom CCP script is utilizing the Event Subscription method connect.contact(function(contact) { … });
  3. At least one new audio file that will be the secondary ringtone for your CCP. Since this will not affect the CCP, it can be any audio format and any length that is supported by your browser.

Adding an audio element

The first step is to add a new audio element to your HTML page.  Something like below:

Notification

 

 

 

 

 

This will display the audio controls useful for testing and seeing the play in action, you can hide this afterwards.  Change the file name on the “src” tag as needed, as well as the type of audio.

Check out https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio for more information about the audio element.

Specifying Audio Output

To specify the audio output device, see the code example below:

HTML

Notification

 

 

JavaScript

Notification

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

In this example, we simply created an HTML button that calls changeAudioDevice() when clicked, looping through the list of audio devices and displaying the current selection on a “p” tag.  The important part of this function is await audio.setSinkId(audioDevices[deviceOption].deviceId);  This actually sets the audio output source for that audio element.  There are many other ways you could implement this function so feel free to change how you cycle through the list and set the audio.

Below you can see a new audio output source after clicking “Set Audio Output” a few times.

Notification

CCP Integration

So we can now get an audio file on a page and select the output source.  Integrating with the CCP at this point is simple, we just need to invoke the PlayNotificationAudio and StopNotificationAudio functions within a few functions from the Connect Streams API

Once you have Connect Streams API included and can display the CCP, you’ll need to add our audio notification functions to the Event Subscription method connect.contact().

The Connect Streams API has several methods that are invoked during several state changes with the CCP.

Notification

 

 

 

 

 

 

Notification

That’s all you need to do to implement this basic feature.  OnEnded() is needed in case the agent misses the call, this function is called when the contact is destroyed and so it will stop the ringtone until the agent goes available again.

Next Steps

This is a simplified implementation of adding additional audio with a custom CCP and there is a lot more we could do to create a better experience for the agent.  See below for a few ideas to get started with.

  • Toggle switch to enable/disable secondary notification ringtone.
  • Use a dropdown to select the desired audio output source instead of a button to loop through them.
  • Save audio output selection as a user configuration so it becomes the default when using the CCP.
  • Allow agent to upload ringtones to an S3 Bucket or other hosting service for custom, unique ringtones for each agent.
  • Use a variety of ringtones and set a different ringtone for known contact phone numbers so agent is aware of who is calling before accepting.

Notes

Audio not playing – If your audio file is not playing on an incoming call, check the developer tools in the browser.  You may encounter “Uncaught (in promise) DOMException” when trying to play the audio file.  There is a feature of browsers meant to prevent auto-playing audio and video in new tabs and pop-ups.  The user must click or interact with the page first before the call to audio.play() is invoked.  Check out https://developers.google.com/web/updates/2017/09/autoplay-policy-changes for more information.  This could be solved by including a toggle for the notification sound forcing the agent to interact with the page first.

You can view the full source code used in this post at https://github.com/waterfield-tech/Custom-CCP-AgentNotification.

Thanks for reading! — Joseph

 

 

 

 

 

 

 

 

 

 

 

Voicemail for Amazon Connect July 12, 2019 by VoiceFoundry Under: Blog, Business

Voicemail still holds a great deal of relevance within the modern contact center and is often fundamental to acceptable customer communication. VoiceFoundry delivers Voicemail for Amazon Connect as a vital element for our customers’ contact center operations. This solution provides both agents and supervisors the ability to access voicemail messages on the fly, from any device. Whether it’s desk phone, email, mobile device or desktop application, Voicemail for Amazon Connect can be received. Notifications are also sent to the AWS Connect custom control panel (CCP) or via email as soon as a customer leaves a message.

The Benefits

Voicemail
Receive email with transcribed voicemail message within your email client.

Although some might consider voicemail to be an old fashioned feature, it is still used as an integral tool in many contact centers.  VoiceFoundry’s Voicemail for Amazon Connect allows contact center agents and supervisors to either listen to or read a record of the message left by a customer. Each message is quickly and automatically transcribed to text and delivered by email or sent to the CCP with the audio file. Agents can then have the choice of reading the message rather than listening to it, allowing a more discreet method of assisting the customer.

How does Voicemail work?

VoiceFoundry Voicemail for Amazon Connect leverages a blend of AWS services including Kinesis Video Streaming (KVS), Transcribe, Lambda and DynamoDB to record, transcribe and deliver the message. The application records the message, stores the captured message in a designated S3 bucket and converts the record to text, which is then delivered via email, webpage or through a custom call control panel (CCP) within Amazon Connect.

Features
  • Message recording based on real time audio streaming
  • Agent or queue based custom voicemail greeting can be recorded using recorded audio or Polly TTS
  • Voicemail notification via email or SMS
  • Manage messages with a simple web interface with the ability to delete, forward and even initiate a call back from the email
    message
  • Email integration to receive a transcribed, text based rendering of customer voicemails
  • Simple deployment via serverless framework /CloudFormation
  • Combines a rich user interface for message retrieval
  • Extends integration capabilities with other standard email clients
Packaged Offering

VoiceFoundry’s Voicemail for Amazon Connect is offered as a stand-alone package that may belicensed and purchased on a per seat basis, or as a fully managed service. Both offerings include ongoing support subscriptions for future updates, bug fixes and compliance with AWS service changes.  For additional information Contact Us.

Setting up Contact Trace Records for Analysis with Amazon Athena June 21, 2019 by Joseph Mumford Under: Blog, Technical

Amazon Connect has excellent reporting features, both for real-time and historical analysis. Contact Trace Records (CTRs) are the primary source of data that Connect collects for every call that occurs within your contact center and are used for reporting and analysis.  These records are only stored for 24 months after creation, so they don’t last forever.

CTRs contain a lot of details about the call and one of the most important parts are Contact Attributes.  While these are not a necessary feature of CTRs, using them within your contact flows can yield a lot of useful data concerning the customer experience and record important events and details that occur during a call.  Amazon Connect does not support searching and reporting based on these Contact Attributes, however.  They can only be viewed when looking at the details of an individual CTR.

So how can we store permanently store CTRs and make them available for analysis with other AWS Services?  Keep reading to understand what services are needed and how to set them up to use with Connect.

AWS Services Overview

Amazon Athena

Amazon Connect

Amazon Kinesis Data Firehose

  • Amazon Kinesis Data Firehose is a managed data streaming service that will transport our CTRs from Connect to Amazon S3.

Amazon S3

  • With unlimited capacity and scalability, Amazon S3 is the best choice for storing our CTRs and it easily integrates with all the other services we need.

AWS Glue

  • AWS Glue is another managed service which stores the metadata and database definitions as a Data Catalog (database table schema) that we will use with Amazon Athena, based on our CTR data structure.

Amazon Athena

  • Amazon Athena gives us the power to run SQL queries on our CTRs in S3, using the Data Catalog from AWS Glue.

Implementation Guide

Note: Some configuration settings are not fully supported through CloudFormation so we’ll be setting up everything manually through the AWS Console.

AWS S3

If you already have an S3 bucket setup that you wish to use to store CTRs, just take note of the bucket name.  You can also use the S3 bucket that is used by your Connect instance to store call recordings and exported reports.  Otherwise, you will need to create a new S3 bucket.

  1. Navigate to the S3 Service Console in AWS.
  2. Click on the Create Bucket button.
  3. Enter a unique name for your bucket. Remember this must be a unique name world-wide.
  4. Click Create as the default settings are enough, the bucket will already be private.

AWS Glue

The next service we are going to set up is AWS Glue.

Amazon Athena
  1. Navigate to the AWS Glue Service Console in AWS.
  2. Start by selecting Databases in the Data catalog section and Add database.
  3. Enter the desired name for your database, and optionally, the location and description.
  4. Click on your newly created database. From here you can update the optional information if needed.
  5. When you click on Tables from the left-hand side, you will see all tables in that region. By clicking on your Database and then View tables, the console will automatically filter the tables to show only those for the selected database.

There are a couple of ways to create definitions for your table: manually, or with a crawler.  With the manual option, you can specify the table schema yourself.  With a crawler, you can schedule or run an on demand a job that can go through your data to attempt to determine the schema for you.  In this case, we will go through both options; we will setup the initial table manually, then add additional definitions using a crawler.

  1. Click on Add tables, then Add table manually.
  2. Enter your table name and select the database you want it to belong to.
  3. On the next page, select the S3 bucket to use as your Data Store. This will be the bucket that you wish to use to store your CTRs.
  4. For the Data format, choose Parquet. You then need to Define a schema by clicking on the Add Column.  Add the following columns and data types:
Column Name Type
1 awsaccountid string
2 awscontacttracerecordformatversion string
3 agent string
4 agentconnectionattempts string
5 attributes string
6 channel string
7 connectedtosystemtimestamp string
8 contactid string
9 customerendpoint string
10 disconnecttimestamp string
11 initialcontactid string
12 initiationmethod string
13 initiationtimestamp string
14 instancearn string
15 lastupdatetimestamp string
16 mediastreams string
17 nextcontactid string
18 previouscontactid string
19 queue string
20 recording string
21 systemendpoint string
22 transfercompletedtimestamp string
23 transferredtoendpoint string

Now you have a table that resembles the data from our Contact Trace Records.  Review and finalize your table configuration.  We’ll come back to Glue in a little bit.

Amazon Kinesis Data Firehose

The next service we will create is an Amazon Kinesis Data Firehose.  This will deliver the CTRs from Connect to S3.

  1. Navigate to the Amazon Kinesis Dashboard in AWS.
  2. Select Create delivery stream under Kinesis Firehose delivery streams.
  3. Enter your desired stream name.
  4. Choose the source of data, in this case, select Direct PUT or other sources. The other option is to get data from Kinesis Data Streams which is useful if you have other needs with the CTRs but in our case it’s not necessary.  Click Next.
  5. Under Process records, keep Record transformation disabled. Here you can invoke a lambda function to transform your data records prior to delivering to S3.
  6. We do want to enable Record format conversion. Select Apache Parquet.
  7. Next, we will integrate our new Glue database. Select your AWS Glue region, the Glue database and table we created earlier.  Select Latest for table version.
  8. Next, choose Destination. Due to enabling format conversion, S3 is the default and only option.  So, we’ll need to select the bucket we created earlier.
  9. For the prefix, you can leave this blank.  Firehose automatically distributes records using the following folder structure “YYYY/MM/DD/HH.” You can alter this if needed but that structure format will work for us.
  10. It is good to set an error prefix, such as “error/”. With this option, any records with delivery errors will get sent to this folder, isolated from other records.
  11. You can also specify a S3 backup destination which will store untransformed records. We’ll keep this disabled for now.
  12. Keep the default buffer size of 128 MB and set the buffer interval to 60 seconds.
  13. You can set S3 compression, encryption, error logging, and tags if desired.
  14. The final step is to create or choose an IAM role for Firehose to access S3 and any other needed services. Clicking the link will open a new page to create or choose a role. The default role is good enough, just change the Role name as needed.  Click Apply.
  15. Review your Firehose configuration and finish creating. It will take a minute or two to create.

Amazon Connect

Next, we need to configure Connect to send CTRs to your new Kinesis Data Firehose.

  1. Navigate to your Connect Instance in the AWS Console.
  2. Select Data streaming from the left-hand side.
  3. Click the checkbox “Enable data streaming” if not already enabled. This will display options for Contact Trace Records and Agent Events.  Under Contact Trace Records, Select Kinesis Firehose and select the Firehose we just created.
  4. Click Save and AWS Connect will update the instance and its own IAM role to access the selected Firehose.

We’ve now created all the Services we need; the only thing left is data.  If your Connect instance is already live, just wait a bit for new CTR’s to be generated otherwise, start making some test calls.  After you’ve got some new CTRs, check out the Amazon Kinesis Firehose in the Console.  Select your Firehose and click on the Monitoring tab.  You should start seeing some metrics pop up.

If it’s been more than five or so minutes with no metrics, you might want to check permissions as this is the most likely issue.  If you see data in DeliveryToS3Records, you are good to go.

Amazon Athena

Navigate to the Amazon Athena Console.  You don’t need to set anything up in Athena.  Athena automatically looks at your Glue Data Catalog and shows your available Databases you can query.  You should see your database in the drop down and tables underneath.  You can simply click the three vertical dots to open a small menu and select Preview table to run a simple query.  Or enter in the query tab:

SELECT * FROM "<your-database>"."<your-table>" limit 10;

Click Run query.  You should see your CTRs pop up in the results window below.  In the Results window, you can export your results as CSV.  Your CTR data can now be queried using SQL.  You’ll notice that currently, some columns have JSON strings in them.  Athena allows you to query keys within the JSON using json_extract() like this:

SELECT json_extract(attributes, '$.<attribute-key>') AS "<attribute-key>"
FROM "<your-database>"."<your-table>";

Visit https://docs.aws.amazon.com/athena/latest/ug/querying-athena-tables.html for more information on Querying Data with Athena.
Going back to AWS Glue for a moment, we can now create a Crawler since we have data in our S3 bucket.  There are few more columns we can easily add to our table which will help speed up our queries as our data set gets larger and larger.

  1. Navigate back to the AWS Glue Dashboard.
  2. Select Crawlers from the left-hand side.
  3. Click on Add crawler.
  4. Enter desired name, tags and description are optional.
  5. Next, select Data stores as the Crawler source type. Choose your S3 bucket as the Data store.  You can add additional data stores on the next page, but we don’t need one.
  6. You’ll then need to create an IAM role. You can create a new IAM role directly on this page which is convenient.
  7. Next, you will need to create a schedule for the crawler. Since the structure of the CTR is unlikely to change, you can just choose Run on demand.  This will prevent the crawler from running unnecessarily and increasing costs.
  8. Now choose the database the crawler will write to. There are several options to choose from but for now, just select “Add new columns only” and “Mark the table as deprecated in the data catalog.”
  9. Review and finish.

Using the default configuration in setting up our table and crawler, there will be a small issue if you run the crawler first.  In our initial setup, the ‘compressionType’ will be ‘null’ on the database table and ‘none’ for our Crawler.  This will cause an error and the crawler will be unable to merge any new columns with the table.  To fix this issue, you will need to edit our table and add the tag ‘compressionType’ as none.

  1. Select your table and then select Edit table details.
  2. Scroll down to the Table properties and add the following key-value pair: ‘compressionType’, none.
  1. If we run the crawler now, we should have no issues and we should see that it updated our table. Click Run crawler.
  1. Look at the table properties now and you should see four new columns at the end, partition_0 – partition_3. This is not CTR data but a reference to the folder structure in S3.
  2. Edit these columns as Year, Month, Day, and Hour. Be aware of the type that the column is set to, the default will be ‘string’ but in this case you could also select ‘int,’ which is reflected with the following query.
SELECT "contactid", "year" FROM "<your-database>"."<your-table>" WHERE "year" = 2019;

Although not noticeable with small data sets, once we are querying our data lake with millions of records, the ability to filter by these partitions will greatly speed up our queries and reduce costs since Athena charges by data scanned.  In our case, this partitioning is built-in with Firehose and meets our needs, but you may have different requirements.

Check out https://docs.aws.amazon.com/athena/latest/ug/work-with-data.html for more information on working with source data and partitioning.

Conclusion

Amazon Connect has some great features to help you run a cloud-based contact center.  It is designed to enable you to get started as quickly as possible and manage your contact center with minimal effort.  Being a part of the AWS ecosystem, however, lets you leverage many other services so that you can get even more functionality from your contact center.

In a later post, we will dive further into data transformations and more complex table schemas.  The next phase would be to transform this data prior to S3 delivery where you can change these JSON objects to more structured and easily queried data.

Thanks for reading!  For further information on this topic or others, please Contact Us.

– Joseph

Architecture of Amazon Connect from 1 to 10,000 Agents…It Grows With You! June 4, 2019 by Daniel Bloy Under: Blog, Technical

Contact Centers have the reputation of being big and complex systems that take years to complete from the creation of the architecture to deployment.  The thinking is that only the wealthy can afford the fancy market-leading features.  Well, it’s certainly not true anymore.  Amazon is breaking the trend with Amazon Connect, where, in fact, you can get a basic Contact Center working in minutes and for less than you think!

But don’t imagine that this is some kind of second class version.  This is the same solution that the Enterprises use!

Simple Architecture

Simple Architecture

Here you can see what this looks like from an Architecture point of view… pretty simple right?  But don’t think of this as some sort of an inferior solution.  This has the same features that an Enterprise level business runs with but it uses the highly available AWS Infrastructure that scales on-demand and allows to pay only for what you use!  You get Telephony (Toll Free and DDIs numbers) along with IVR Menus, Call Queues, Reporting etc…and best of all you can add features as you grow.

 

This Amazon Connect solution is perfect for:

  • Small production contact centers (IT Helpdesk / HR etc.)
  • Organizations that are wanting to test and learn at pace.

Basic Architecture

Once you learn and grow with the Amazon Connect solution you’ll find more use cases for even greater features.  You may end up with something like this:

 

Basic Architecture

 

Ok, so we’ve added a few extra components here, but you’ll get some pretty impressive features:

S3: This is used to Store Call Recordings.  You have the option to Record Customer/ Agent or both and store these indefinitely. Audio is recorded in an Open format (WAV) so you can add tools later to analyze the information or just simply listen to them via playback which is available directly from the Amazon Connect UI.

S3: You also use S3 to save Call Reports, and, like the call recordings, you can save as many reports as you want for as long as you like. And using an AWS service called Athena, you’re able to query these flat files on demand at any time.

Lambda is a special service I highly recommend you learn about. Lambda allows code to be executed on demand and what the code does is up to the developer building it. In this scenario, we can use the data returned from the Lambda to affect the Customer Journey, provide information to the caller or provide the text for the messaging prompts. And it can integrate into other AWS Services, 3rd Party APIs or your own existing services.

DynamoDB: This is a NoSQL database from Amazon. You can store your customer orders, account information, have an administration database to affect special routing and more.  When used in the Architecture above, we are able to use the Callers ANI (Phone Number) which is sent from Amazon Connect to Lambda, which looks the callers order up in the database and provides the caller with personalized information! (Self Service) The information is Dynamic and Amazon Connect can handle it with its built-in Text to Speech Engine (so no need for complicated IVR messaging). You can also provide the caller some options to update the information and Lambda can update that in DynamoDB for you.

 

More Advanced Architecture

 

The great thing here is you get to see the value on a rapid development cycle.

 

Ok, by now you can see how you can start small and build on your investment. The great thing here is that you get to see the value on a rapid development cycle and you’ll start to drive your own wish-list as you see more value opportunities. So lets up the ante just a little…

 

Advanced Architecture

 

While this looks like a significant advancement, it’s still fairly contained. So let’s build on the previous model some more.

S3: This time we add a custom Administration Portal for your ‘Ops Team’ so that they can affect the routing via toggle buttons, close routing ad-hoc, play special messages (that they type into the portal) and respond to increasing demands etc..

Lambda: As shown previously, however, this time we also connect to SNS, Simple Notification Service. This allows us to send Mobile Notification, SMS, E-Mails etc.  This can be completed DURING or AFTER the contact.

LEX: This is the AI engine that drives Alexa. You’re able to provide natural conversational interactions for the whole journey or just parts of the journey.  Think about when your customer connects with you and the first thing they hear/see is:

Welcome back Donna.  I see your flight has been cancelled, would you like to reschedule?

Note I say hear/see… this is because LEX is a Voice AND Text Chatbot service.  You only need to code once and you can reuse that Chatbot within Amazon Connect (even export it to Alexa) and integrate it with your website / Slack etc…

Kinesis Streams: This provides the real-time streaming of all the Contact Trace Records (CTRs) data from Amazon Connect.  These are the results of the contacts from Amazon Connect. The data sits in streams waiting for a consumer, in our case the Lambda, to do something with it.

Lambda: As explained above, this provides post-processing of the records and can perform actions, like a post-contact survey, and sends the data onto Firehose.

Kinesis Firehose: Firehose is a variant on Streams which is more for batch type data movement, and is needed to feed Redshift.

Redshift: This is Amazon’s Enterprise Data Warehouse solution where you’re able to run queries on massive amounts of data and where your data scientists will live.

In conclusion

As you can see, a contact center does not have to be big and complex or take years and lots of dollars to create. With Amazon Connect:

  • You’re able to start small and grow.
  • No two implementations need to be the same;  you can create a solution just for you!

 

Note: Out of the box Amazon Connect has Service Limits, so make sure you’re aware of them.  Monitor for and increase as required.

For some customers, building and supporting the technology yourself doesn’t make sense. This is where VoiceFoundry can help, our Migration and Managed Service Offerings can ensure that you take full advantage of the Amazon Connect features and pricing without needing the in-house talent.

 

 

Doing a Cold Transfer with the Amazon Connect Streams API May 30, 2019 by Ivan Bliskavka Under: Blog, Technical

The Amazon Connect Streams API allows you to create custom interfaces for the soft-phone and provides many functions for interacting with the current connection. It is a powerful set of tools but some of the more sophisticated functions may not be so obvious. This blog post describes how to implement a cold transfer using the plain Streams API.

(more…)

Amazon Connect Data Sources – Part 1 May 20, 2019 by VoiceFoundry Under: Blog, Business, Technical
In this Blog post, we’re going to take a look at the kinds of Data generated by Amazon Connect.  This will be the first of a 3 part series that takes a deep dive into this important element – Data. In Part 1 we’ll look at the 7 different types of Data generated by Amazon Connect and how you can assist in its creation. Part 2 will show how to get access to this Data in real-time via event-driven processes as well as how to use that data in real-time to trigger other processes. In Part 3 we’ll look at options on how to store this Data for analytics and reporting.
Why this is so important
Data within the contact center is a rich source of information. It can provide you with insight into why customers are calling, the performance of your IVR, repeat callers, customer sentiment and troubleshooting, to name just a few. Knowing what information can be generated by Amazon Connect is critical in helping you understand the architecture you require and how to design your contact flows and processes. So let’s get right into it.
Amazon Connect CTI Adapter for Salesforce – What’s New & Different? May 2, 2019 by VoiceFoundry Under: Blog, Technical
SalesforceVoiceFoundry Salesforce Capability

Before we jump into discussing the features of the newest release of the Amazon Connect CTI Adapter for Salesforce, we’d like to mention a little bit about how we might help your organization with Salesforce. Alongside AWS, we have helped to add significant amounts of functionality to the Amazon Connect CTI package. In short, we know it well. While the package is full-featured, your business may want or need something different. We have a deep understanding of the Salesforce platform and have dedicated, certified, Salesforce team members to help with everything from consulting and guidance to building a complete Salesforce solution for you. From custom screen pops to IVR-integrated workflows to Lightning and Visualforce application development, we have your Salesforce needs covered.

(more…)

Get Insight from Your Call Recordings with Amazon Transcribe April 11, 2019 by VoiceFoundry Under: Blog, Technical

Amazon TranscriptionOne of the many things that makes Amazon Connect so powerful is the way it can integrate with other AWS services which then provide a rich baseline for our business applications. Amazon Transcribe is one of the newer services offered (it will be 1 on April 4th) and it adds an intriguing augmentation to the Amazon Connect Contact Center.

Rather than monitoring customer interactions by listening to audio files, Amazon Transcribe provides us with an opportunity to take the first step into Machine Learning and data analytics. These transcriptions can be further processed by other AWS services such as Amazon Comprehend or stored as part of an Elasticsearch cluster.

(more…)