Posted on 21 Jun 18 by Kiernan McColl - Senior Full-stack Developer
This is part 1 of a 3 part series
We’ve recently moved our company phone number to Amazon’s Connect service, which allows you to define your own interactive voice response (IVR), menu call routing logic, and other functions commonly used in companies of every size, from basic reception functions to the more complex requirements of a global call centre.
It provides a lot of great building blocks that can be used to build solutions with a wide range of requirements, but unfortunately, we found it lacking a built-in voicemail feature, offering only an automated call-back function. After searching for a solution to this and not finding any built purely with AWS services, we decided to try and do it ourselves.
Our goal is simple: at certain points in our IVR flow, we want to ask callers leave a voice message, then be notified about the new message via email with a link to download the voice recording.
This series of posts will show various ways we tried implementing this, before finally arriving at a (fairly hacky) solution, then improving it to the point we were comfortable enough to use it to handle our calls out of hours.
Amazon Connect allows call recordings to be saved to Amazon’s simple storage service (S3). So could we simply turn on call recording storage, enable it for our call, then find some way of cutting the resulting audio file down to the relevant part? We could use a loop or long prompt message to tell the caller when to start leaving their message.
It might look something like this:
We could use the call start time, and the ‘voicemailStart’ entry from our contact flow logs to determine how many seconds of audio we need to trim from the start of the file.
Let’s give this set-up a try. We’ll call our contact flow’s number, leave a message when asked, then check our S3 bucket to find the recording we’ll need to process…
Whoops. It doesn’t look like Amazon Connect actually records the call while it’s still making its way through the steps defined in our contact flows.
Amazon Connect might only decide a call is worth recording once it’s connected to a human. There must be some way we can automate the human on our side of the conversation. After all, that’s why we’re implementing an IVR in the first place.
Let’s try setting up a second phone number to transfer the caller to, and link it to a new contact flow whose only job is to answer the call so that the transfer goes through. We’ll also have it ask whoever calls it to leave a message, and wait for a while for them to speak.
We’ve set up our original contact flow which handles incoming calls to transfer the call to this new number:
Instead of going to a real person, that number routes to another contact flow:
This ‘Answer voicemail calls’ contact flow has some of the steps from our first attempt. Its only purpose is to answer the call, so the original contact flow thinks it’s a call to a human agent and records it for us.
Let’s try it now…
Doh. The bucket’s still not getting anything. Amazon Connect hasn’t recorded the call even though we’ve transferred it to a person for all it knows. We’re guessing it hands the call off completely rather than using a conferencing-type feature, so is unable to record it after that point.
Ok, it must only record calls when it’s been connected through to an ‘Agent’ as you would do in a traditional call centre scenario. Instead of transferring the call out to an external number, let’s try transferring it to a queue for an agent to answer.
We’ll create a new queue called ‘Voicemail’:
Then create a routing profile that handles the queue:
Now the important part. We’ll create a new user to be our voicemail agent, and assign it to handle the voicemail queue via the routing profile. But for their ‘Desk Phone Number’ we’ll specify the same number that gets routed to our ‘Answer Voicemail Messages’ contact flow:
Finally, we’ll update our main contact flow to transfer the call to our new voicemail queue:
No, not just yet. If we were to test the system out now we’d get transferred, then put on hold indefinitely. Although we’ve assigned an agent to the queue, and specified a desk-phone number for the agent, Amazon Connect won’t actually pass any calls through to the agent unless they’re set as ‘Available’ in the agent’s Contact Control Panel (or CCP). The agent login URL isn’t linked from the console, but will be: https://<your instance alias>.awsapps.com/connect/ccp
So we’ll try that. We’ll login with the username and password we created earlier:
Then hit the ‘Set to Available’ button:
Now when we try, the call gets transferred to the voicemail queue, then our agent will answer it, following the steps in our ‘Answer Voice-mail Calls’ contact flow to ask us to leave a message.
Most importantly, this time when we check our S3 bucket, we should now see that a call recording was captured!
This should now give us the basic pieces we need to set up a basic voicemail system. If you don’t mind checking the S3 bucket for messages occasionally and making sure the voicemail agent is logged in and available, you might call it day.
Here’s how the whole thing looks from a high level at this point:
In our next post, we’ll set things up to automatically notify us of new messages by publishing them to a Simple Notification Service (SNS) topic after using AWS’s Transcribe service to the message into a readable form. We’ll also provide a pre-authenticated link to download the full recording in case Transcribe couldn’t understand enough of the message for the transcription to make sense to us.