Month / May 2018

by dmacias

Amazon Connect CCP (Agent Desktop) Walkthrough

I was talking to a few people about Connect and we were focusing on the agent desktop. For someone who is coming from Cisco Finesse, CCP is a big departure and I couldn’t find a good resource which showed all the out of the box functionality in a concise way. So, here it is. Everything you need to know about straight out of the box CCP.

CCP Highlights

  • 100% web-based.
  • Uses WebRTC and Opus audio codec.

Login Screen

  • Can be integrated to SSO.
  • Allows for password self-service.

image

Initial Screen

  • Will set you to whatever state you last had before you logged off or killed the client.
  • Transfer buttons are semi context aware (more on this later).
  • Agent status/state menu.
  • Log out is not a state, but a separate button.
  • Ability to get calls via a hard phone/PSTN instead of over the web.
  • Ability to download agent side logs (JSON format) from first login to right now.
  • Multi-lingual support 8 languages.

imageimageimageimageimage

Call Screen

  • Agent whisper of queue name.
  • ANI of caller.
  • Transfer numbers based on queue name.
  • Can transfer to another queue, another agent, or external. Can even transfer to yourself which makes no sense.
  • Multi line support.
  • Can make outbound calls manually.

12

image3image

~david

by dmacias

Continuous deployment to Amazon Lambda using Bitbucket Pipeline

I’m not a developer (more of a hack) so I’m always looking for way to figure out efficiencies in my process when playing around with code as I’m a very slow coder. One of those efficiencies found is around deploying my code to Amazon Lambda.

First, let’s talk about your options when deploying code to Lambda. The easiest way is to just do your development using Amazon’s IDE. The benefit here is that you can manually run some tests to validate what you’re writing, however if you’re using any dependencies the IDE has a size restriction and at some point it’s no longer available to you.

image

The next method is doing local development and creating a zip file of all your code and dependencies. Then manually upload your code. You can then run the same manual tests as before on your code, but the process of zipping and uploading the file is tedious specially when working on large code bases.

image

Next process involves the very good Amazon CLI. Using the CLI you’ll be able to save the manual process of uploading the zip file. Below you’ll find the Windows scripts I use one for small code bases (without dependencies) and one for larger ones.


echo on

del index.zip

echo Deleted index.zip

"c:\Program Files\7-Zip\7z.exe" a index.zip index.js

aws lambda update-function-code --function-name mySmallLambdaFunction --zip-file fileb://index.zip

echo done

[/sourcode]</blockquote>
<blockquote>[sourcecode language="bash"]

echo on

del myZip.zip

echo Deleted myZip.zip

"c:\Program Files\7-Zip\7z.exe" a myZip.zip index.js node_modules

echo Zipped myZip.zip

aws lambda update-function-code --function-name myLargeLambdaFunction --zip-file fileb://myZip.zip

echo done

Finally, the process I’ve come to enjoy the most is deploying from git. The main reason being that it forces you have a bit of a process around using git which is pretty much the standard when collaborating with multiple developers. So if you’re dragging your feet around using git take the plunge it’s worth the learning. My favorite, mainly because they have a very generous free offering is Bitbucket. Besides having private repositories they also give you 50 free build minutes which is where our deployment to Lambda from Bitbucket comes in. To get started you first need to setup a few environmental variables. Go to your repository > settings > environment variables. You’ll need these named exactly this way.

image

The next step can be done in two ways. You can commit a bitbucket-pipelines.yml file to your repository or you can go to your repository > pipelines to have Bitbucket commit one for you. What the original yml file looks like doesn’t matter we’re going to change it specifically for Lambda deployment. Here’s what my file looks like with inline comments.


#I like to use the same version of Node as the Lambda function I’m using.

image: node:6.10

pipelines:

default:

- step:

script: # Modify the commands below to build your repository.

- apt-get update

- apt-get install -y zip

- python –version #From here to there is all to enable the AWS CLI installation

- apt-get install -y python-dev

- apt-get install -y python-pip

- pip install awscli #there

- zip index.zip index.js #this is for a Lambda with a small code base. For something large you can use “zip myZip.zip index.js privatekey.json -r node_modules” notice the –r parameter to zip up folders.

- aws lambda update-function-code --function-name botValidationScheduleMeeting --zip-file fileb://index.zip

Assuming you’ve done everything right you should see something like this under Pipelines.

imageThe last 3 commits were successfully built (sent to Lambda). You can click on the commit and see detailed information on the results of every command in your yml file. You’re done, you’ve developed some code locally, committed to git, and pushed it to Lambda all with a few clicks.

~david

by dmacias

Bringing Amazon Lex into your Amazon Connect flows

In this blog we’ll continue our discussion around Amazon Lex. Talk about a few things to keep in mind when integrating your Amazon Lex bot with your Amazon Connect flow. In my particular use case I wanted to use Amazon Lex to look at my Gmail calendar and book a meeting if I’m available. If you want to skip to the very end you can see the end result via video. You’ll see one video of the voice interaction and one of the Facebook Messenger interaction.

First, you might want to reference my previous post around Lex validation. Now let’s talk about our use case:

  • Lex easily allows you to build a bot which understand both voice and text, so our bot needs to handle calls into our call center as well as Facebook Messenger interactions.
  • Bot needs to to ask a few question in order to find out what time the user would like to meet.
  • Bot should only schedule calls between Monday-Friday and 10 AM – 4 PM Easter Time
  • Bot (using Lambda) should schedule a meeting and if slot already taken then suggest an alternate time to meet.

Second, let’s take a quick look at the Lex screen. The bot I created is very simple and it follows closely the Flowers example provided by Amazon. These are the slots I’m requiring my bot to confirm.

image

I used two different Lambda functions. One for validation and one for fulfillment. While most examples seem to focus on using the same function for both, for me it was easier to have different code bases for each with the added benefit of keeping the code manageable. As it is both validation and fulfillment both came in at around 250 lines of code, but fulfillment had around 9 megabytes of dependencies.

image

Finally, here are sample utterances I used for the main intent.

image

What this gets us is the following. The first video is the voice interaction. I went about it the long way to show some of the validation rules being set by the bot, such as no weekend meetings and no meetings too early in the day. At the end of the video you see I refresh the Gmail calendar to show the new appointment has been saved.

In the second video I go through the same Lex bot using Facebook Messenger and then show the calendar to prove that the appointment was saved.

Ultimately, Amazon makes it extremely easy to create a mutli channel bot, however the integration to back end systems is the tricky part. This bot needs a lot of tuning to make it more natural, but for just a few hours of work there’s very little out there that can get your call center to have some bot integration for self service.

~david