Category: Technical Managers

Amazon Connect Campaign Dialer: Why Clean Lists Mean More Connections

Posted on by DrVoIP

Amazon Connect Campaign Dialer: Why Clean Lists Mean More Connections

The Hidden Challenge Behind Every Dialer Deployment

When organizations launch Amazon Connect V2 Campaign Dialer, the excitement is all about automation, scalability, and speed. But here’s the quiet truth our DrVoIP engineers have learned: the biggest obstacle to a successful campaign isn’t the dialer — it’s the list hygiene.

Most outbound lists are stitched together from CRMs, help desks, and third-party data brokers. Before you know it, your “target audience” includes duplicates, missing data, and invalid numbers. Bad lists lead to failed calls, frustrated agents, and compliance headaches. Clean lists lead to productivity, precision, and profit.

Data Hygiene Is Not a One-Time Event

Keeping your campaign lists clean isn’t something you do once — it’s an ongoing process. It mirrors the machine learning lifecycle: collect, clean, validate, and repeat. Yet this critical task often lands on the IT team instead of the call center management where it belongs.

That’s why DrVoIP has been exploring AWS tools to automate and simplify this workflow. Our goal: let your team focus on connecting with customers, not cleaning CSV files.

Testing the Tools: From SageMaker Data Wrangler to Glue DataBrew

We first tried AWS SageMaker Data Wrangler — a world-class solution for preparing large datasets used in machine learning. It worked beautifully but was too expensive and too complex for everyday dialer list management.

Then we discovered AWS Glue DataBrew — a cost-effective, no-code tool for cleaning, normalizing, and validating data stored in Amazon S3. Think of it as a “data washing machine” that removes duplicates, fixes missing information, and standardizes phone numbers to the required E.164 format.

Essential Steps for Campaign List Hygiene

Regardless of which AWS tool you use, these hygiene steps should always happen before uploading a list into your Campaign Dialer:

  • Normalize Phone Numbers: Convert all numbers to E.164 format (+1 for US, etc.) to avoid rejection or failed calls.
  • Validate Every Number: Use Amazon Pinpoint’s phone number validation API to confirm if a number is valid and identify whether it’s mobile, landline, or VoIP.
  • Scrub Against DNC Lists: Stay compliant by checking both national and internal Do-Not-Call registries. Pinpoint or your third-party DNC provider can help here.
  • Infer Time Zones: Campaign Dialer can determine a contact’s time zone from their address or phone number — if that data is accurate. Validate and fill missing fields.
  • Encrypt and Protect Data: Always store contact data in encrypted S3 buckets with AWS KMS for compliance and security.

How It All Fits Together

At DrVoIP, we’ve built a simple, repeatable architecture that keeps list hygiene both affordable and automated:

Amazon S3 (Raw List) → Glue DataBrew (clean & format) → Lambda Function (Pinpoint validation & filtering) → DNC Scrub → Amazon S3 (Cleaned List) → Amazon Connect Campaign Dialer.

This keeps costs low, reduces manual labor, and ensures every dialable number in your list is verified, compliant, and ready for use.

The DrVoIP Bottom Line

For machine learning projects, SageMaker Data Wrangler is a great fit. But for day-to-day Amazon Connect V2 campaigns, Glue DataBrew + Lambda + Pinpoint delivers the perfect balance of cost, simplicity, and scalability. It’s a practical solution that keeps your campaigns compliant and your agents productive.

In short, clean lists create confident dialing — and confident dialing drives conversions. Treat list hygiene as your competitive advantage, not a cleanup chore.

Ready to automate your list hygiene process? Contact Grace@DrVoIP.com and learn how DrVoIP can help you build a data-driven campaign workflow powered by AWS.

AWS AI or Google AI?

Posted on by DrVoIP


Amazon Bedrock vs Google Vertex AI — Who’s Winning the AI Race?

AI is no longer a buzzword — it’s the new business backbone. Whether you’re automating a contact center, building customer analytics, or integrating natural language chat into your apps, the question is no longer “Should we use AI?” but “Which cloud AI platform should we trust?”

At DrVoIP, we work deep inside the Amazon Web Services (AWS) ecosystem — deploying Amazon Connect contact centers, AI chatbots, and voice automation. But every so often, clients ask, “What about Google AI?” So let’s take a friendly, informative look at how these two giants stack up for developers and business professionals.

AWS AI Services – Built for Builders

Amazon Bedrock and SageMaker form the backbone of AWS AI strategy. Bedrock gives you access to multiple foundation models — Anthropic Claude, Meta Llama, Mistral, Amazon Titan — through a single API. That means developers can experiment and scale without retraining or rebuilding pipelines.

SageMaker powers the entire machine learning lifecycle — from data prep to deployment. Add services like Lex for conversational bots, Comprehend for sentiment analysis, and Kendra for document search, and AWS becomes a full AI ecosystem ready for enterprise workloads.

For business leaders, the key advantage is integration. AI connects seamlessly into AWS’s vast toolkit — S3, DynamoDB, Redshift, Connect — all secured under the same IAM policy framework.

Google AI Services – Designed for Discovery

Google Vertex AI and the new Gemini API represent Google’s unified approach to machine learning and generative AI. Vertex brings together model training, evaluation, deployment, and monitoring under one interface — ideal for data scientists and AI researchers.

Google’s strength is creativity and speed. Vertex AI integrates beautifully with BigQuery, Cloud Storage, Firestore, and Colab notebooks. Developers can test, fine-tune, and deploy models in hours — not days. And the Gemini family models (successor to PaLM and Bard) deliver world-class text and multimodal capabilities for summarization, image reasoning, and code generation.

Head-to-Head Summary

Category AWS AI (Bedrock & SageMaker) Google AI (Vertex & Gemini)
Model Variety Multi-model (Titan, Anthropic, Meta, Mistral) Gemini family + open-source (Gemma, Mistral)
Ease of Use Strong for developers, steeper for business users Very accessible with notebooks and UI tools
Ecosystem Deep enterprise integrations (S3, Connect, Lex) Tight analytics stack (BigQuery, Search, Colab)
Security Enterprise-grade IAM, compliance focus Fine-grained IAM, research-oriented flexibility
Deployment Serverless, multi-model endpoints Edge and cloud endpoints, rapid prototyping

The DrVoIP Takeaway

For production-scale enterprise AI deployments — especially where security, governance, and integration matter — AWS Bedrock and SageMaker are the clear choice. They’re built for scale, built for control, and built to integrate into your existing AWS architecture.

For fast prototyping, experimentation, and data-driven innovation, Google Vertex AI shines. If you’re already running on Google Workspace or BigQuery, Vertex offers the shortest path from concept to prototype.

Our Recommendation

Most organizations don’t need to pick a side. The smartest strategy is multi-cloud AI: use AWS Bedrock for enterprise workloads and Google Vertex for innovation labs. The two can complement each other beautifully when designed with the right architecture.

Need help navigating AI services for your contact center or enterprise app? DrVoIP can help you design, deploy, and manage a secure, cost-effective AI strategy on AWS — complete with proof-of-concept, data pipeline, and integration guidance.

Contact us today: Grace@DrVoIP.com

DrVoIP — Delivering Amazon Connect, AI, and voice automation on time, on budget, with the highest customer satisfaction.

2025 DrVoIP Contact Center Planning Guide!

Posted on by DrVoIP

Rethinking Your Amazon Connect Contact Center: Start with the Experience, Not the Technology

When planning a new Amazon Connect contact center, the temptation is to jump straight into the technology — menus, routing profiles, integrations. But the truth is, great contact centers start with the caller’s journey, not the IVR script.

If your plan is to copy the same call tree you built a decade ago, you’re missing the opportunity to create a modern, frictionless customer experience. Today’s customers expect faster resolutions, smarter routing, and a personal touch — not endless menu options.

That’s where the DrVoIP Amazon Connect Planning Guide comes in. It walks you through the critical questions that must be answered before a single line of code is written or a design spec is handed to the implementation engineers. Questions about:

  • How will calls, chats, and messages be routed based on customer needs?
  • What self-service options make sense — and where should live agents step in?
  • How will you measure success from day one?

As an Amazon Certified Delivery Partner, DrVoIP brings the expertise to turn your vision into a contact center that’s on time, on budget, and delivering the highest customer satisfaction scores.



Want the full Planning Guide? We’re offering the DrVoIP Amazon Connect Planning Guide free of charge.

Just contact Grace@DrVoIP.com, call, or textto get your copy.

Amazon Connect Pick a Caller from Queue?

Posted on by DrVoIP

Would You Let Agents “Cherry Pick” Callers from the Queue?

Not everyone agrees with the idea—but in some situations, allowing agents to “cherry pick” callers can save time and improve the customer experience.

By default, Amazon Connect routes callers to the next available agent. It does not ring all agents simultaneously, and it certainly doesn’t allow agents to choose who they want to speak with.

But what if they could?

A Real-World Use Case

Imagine you’re a technician supporting a customer base using your company’s High-Tech Shiny Gadget. Most callers aren’t very technical. You do your best to walk them through a solution, but sometimes, they need to go back and do “homework”—check which cable is plugged in, see which light is blinking, etc.

They hang up, go do the homework, and call back. But now they’re speaking with a different technician, who has to start from scratch—even if you’re using Amazon Connect Cases or another ticket system.

This is inefficient. It frustrates the customer and wastes valuable technical support time.

Enter “Cherry Picking”

What if the original technician could see that the customer is calling back and simply pluck them from the queue? No rerouting, no retelling the story—just seamless, contextual support.

While you might have a way to route calls by extension number, most contact centers aren’t set up that way. That’s where cherry picking comes in.

Watch the Demo

In the video below (Part 9 of our Amazon Connect 2025 Refresh Series), we walk through:

  • How to configure cherry picking in Amazon Connect
  • What resources are required
  • Key recommendations and potential pitfalls
  • A full demonstration of the solution in action

If you’re curious how this could work in your call center—or you want help building it—contact us at DrVoIP.

Enable Callers to Dial an Agent Direct?

Posted on by DrVoIP

Direct Dial and Agent?

Not every contact center wants callers to be able to dial a specific agent directly.  In fact, more times than not, it is discourage entirely.  Certain enterprises however find it a real necessity.   Customer service operations, technical support and telemedicine are good examples of service centers that would benefit by this feature.   Often in these use cases, the agent assigns some “homework” that requires the caller to hang up and go check something and call back.   We all know how frustrating it is to call into a contact center and be treated like this is the first call!  Enabling a customer to reach the same representative that they worked with in the last call is a real time saver and improves both the efficiency of the call center and satisfaction of the client!

Not a native feature for Amazon Connect

As is the case in most features in this AWS service, you will have to configure it yourself.   The provided tutorial will walk you through how to build this out (clearly we are in the business of helping you do this)!  The key components of this solution are a number of AWS services and some contact flows that support the feature:

  • Not required by helpful for voice mail,  VoiceMail Express application
  • S3 to support static website used for userAdministration
  • Cognito to protect access to the admin website
  • API Gateway to facilitate connectivity between the website and the lambda back end
  • DynamoDB to list and maintain agent extension numbers
  • Lambda functions to update and maintain user extension list
  • Clearly and Amazon Connect Contact Center!

Configuration Overview

The front end contact flow prompts the caller to enter the extension number of the representative. This is usually just an add on to your existing greeting.  For example: ” Thanks for calling our company, if you know your representatives extension number you can enter it now, or press 1 for sales or 2 for support”.   The caller will be routed through contact flows to the representatives queue and if available, directly connected. If the representative is on the phone, the caller is offered a choice to try another team member, or continue to hold.  If the representative is logged out, the caller is offered the option to try another team member of leave a voice message.

Back End Configuration

The website enables system administrators to add extension numbers to the agents defined in the contact center.   The supporting lambda functions draw form both the user database in the Amazon Connect instance and the DynamoDB table you create to provide extension number to those agents.   Cognito is recommended as a security front end to the website enabling only credentialed administrators to log in!

You can find the sample contact flows and lambda functions and HTML/Javascript for this tutorial  in the DrVoIP store!

 

Voice Mail Express for Amazon Connect!

Posted on by DrVoIP

Voice Mail solution for Amazon Connect

for the last few years AWS has made a voice messaging solution available for Amazon Connect deployments available for download from Github.   This was a feature rich solution offering a needed feature.   The solution enabled a caller to leave a voice message for an Agent and with a bit of configuration magic, you could also leave a message for a queue.  The voice message could be delivered as an email or text message.  The message could be transcribed and encrypted.  We regularly deployed this solution and customized it to enable direct extention dialing for callers to reach specific agents and other external users.

Missing some features

In 2024 AWS dropped support for this application.  The upgrades to Node and Java were most likely the reason support was dropped.  As we enter 2025 AWS has replaced the older voice mail solution with “Voice Mail Express” version 3, also available on Github.   The solution does a better job of enabling voice messages for both agents and queues, but lacks support of SMS message delivery.   Additionally, the core voice message handler is a Module in Amazon Connect, which makes it especially challenging for use as a bail out option in a queue hold flow.  This is because, you can not invoke a module from this type of contact flow.

There is a Youtube video covering this material!

We have been implementing this solution and have begun to explore customization possibilities.   For example, being able to directly dial an agent and to offer SMS message delivery.  The configuration is not intuitive for non technical personnel, so we created configuration guide.  If we can help wiht customiztion and integration efforts, just click or call DrVoIP, we know the drill! – DrVoIP

How can an Agent Originate an SMS message in Amazon Connect ! – Part 2 Routing the Return Message

Posted on by DrVoIP

SMS Return Message Routing

In part 1 of this blog we looked at three options that enable an Agent to make originate an SMS message:

  • Option 1 – User a TASK Template
  • Option 2 – Create an HTML Form (DrVoIP favors this approach)
  • Option 3 – Create an Email to SMS solution

The key flows in any of these solutions, is to write the Send_TO_Number, smsMessageContent, AgentID (extension number, login, username), and timeStamp to a dynamodb table when originating and outbound SMS.  This is possible with all three solutions, but we like option 2 the best.  Option 1, with all of its strangeness has the advantage of being an action taken within the contact center, making a historical record more practical.  The other two options, start outside the call center and the origination event is not noted for historical records in the out of box archive methodology of the Amazon Connect Instance.

Option 1 Task Template launches Contact Flow

The TASK solution gets the Origination SMS job done and works just fine.  The Contact Flow the TASK points to contains an invoke Lambda that sends the messageContent and phoneNumber on to Pinpoint SMS.  There is no real way however, to capture the Agent that initialized the Task.   We tried writing the phoneNumber and TaskID along with a timestamp to a dynamoDB table, then invoking another lambda to look up the phoneNumber it in an inbound contact flow, but it was just ugly and did not identify the agent that originated the outbound SMS.  You need someway to ID the Agent so you can “set working queue” by agent and get the incoming return message routed accordingly.   Given that custom fields (as of this blog) can not be passed as a contact attribute, there was not way to add the Agent ID to the Task Template.

Another major challenge is that the CHAT API used by SMS (and chat for that matter) does not, in general,  support Contact Attributes.   Let us assume you want to ask the customer to enter the order number so you can look up the status.  They might provide that number, but there is no way to extract that data and assign it to a Contact Attribute for further processing later in the contact flow.

Enter Option 2 (Static website to launch HTML form)

The benefit of popping an HTML form is that you can prompt the Agent to enter something to identify themselves.  This would enable you to invoke a lambda function to  write the phoneNumber, AgentId and timestamp and even the smsMessgeContent to a dynamoDB table for later processing.   That function would also include the SDK that enables you to find the agents unique ID and also route that to the database.  The entire DB item would include:

customerNumber – this would become the partition key in your dynamodb table;
smsMessageContent – the text of the outbound SMS message content;
agentID – obtained by using the Agent username and the SDK to get the agentId a unique value for each agent.
timeStamp – date and time of the item creation.

The inbound contact flow handler we could grab the Customer Number, invoke a lambda function to request the agentId so that the chat session (i.e. SMS) could be routed to the agent that originated the outbound message using the “Set Working Queue by Agent” step in the contact flow associated with the SMS number.  We would also invoke a lambda function to retrieve the smsMessageContent from the stored item and assign it to a contact attribute for later use.  (Developer Note: It would be possible to retrieve both the agentId and the smsMessageContent in one invocation, but parsing a JSON object in a contact flow is not worth the trouble, it is easier to make two invocations).

When the agent accepted the incoming chat, the ongoing back and forth of the chat transcript (i.e. SMS) would be captured and stored.   How would the agent know what the original outbound message contained?  We need a strategy for presenting that to the agent and adding it to the transcript for historical reporting, or additional processing by LENS etc.     Using the Agent whisper function, we would use the contact attribute created for smsMessageContent to satisfy this requirement.

This option, in our opinion, is the optimal solution for originating an outbound SMS message and routing the return message to the agent who created the message in the first instance.  It captures all the activity, makes it available to the agent and other features of the Amazon Connecct instance.

Enter option 3 Email to SMS

In this option we want to use email to launch the SMS handler using the configuration provided in Part 1.   The thinking here was to use SNS rather to trigger a Lambda rather than Invoking  Lambda from inside a contact flow triggered by the Chat API.  Do not connect the SMS phone number direct;y to the Instance.  We created two SMS handlers: one inbound Lambda to handle either an SMS that did not ordinate by an Agent.  it could also handle a return message originated by an Agent.

Email Outbound

Using the email client we were able to launch an outbound lambda that would be able to parse the message and write the From (i.e. Agent ID), Subject (i.e. target recipient phone number)and a times stamp  to a dynamoDB table.  No need to log the message content, we would pass all the variables off to the Pinpoint SMS number.

SMS Inbound

The inbound SMS triggered the lambda which would use the phone number to index the dynamoDB table and bring back the AgentId.  It might be necessary to use the AgentId to look up the Agent Name or ARN, but the result was much cleaner and seemed to work just fine!   With the AgentId we were  If there was no matching number in the database then the message was treated as a new incoming SMS and routed to the default workgroup set in the contact flow.

TTL

We needed a ‘garbage collector’ that could go into Dynamodb and clean out any entries that had a time stamp that exceeded whatever we set as the Time To Live (TTL) value.

How can an Agent Originate an SMS message in Amazon Connect !

Posted on by DrVoIP

Pinpoint SMS

For some time now, you have been able to channel SMS messages through the Amazon Connect CHAT API, using Pinpoint services.  Typically, you would create a new project, enable SMS and then use SNS to trigger a lambda function to handle your SMS conversation.  Most recently, AWS has created Pinpoint SMS, a dashboard that enables you to directly integrate SMS services into your Amazon Connect instance, appearing like any other phone number.   This enables you to capture an SMS event directly to a contact flow eliminating the need to use SNS.

How to Originate an SMS in Amazon Connect?

Getting an inbound SMS message into the call center and routed to the next available agent in a specific queue has been a feature for some time.  As high lighed above, it is now even less complex as we can eliminate the use of SNS, enabling a contact flow to trigger the  lambda function that would handle the SMS session.   The real trick, however,  is how can an Agent originate an SMS message?   If an agent could originate an outbound SMS message, how would the return message be routed back to the agent who originally sent it?

Origination Options?

In this blog we will consider three different strategies that enable an Amazon Connect Agent the ability to ORIGINATE an outbound SMS message.  As noted above, responding to an inbound text message is well documented but originating an SMS message is a real challenge!  (Figuring out how to route the return message to the Agent that originated the message, is yet another challenge! )

  • Option 1 – User a TASK Template
  • Option 2 – Create an HTML Form
  • Option 3 – Create an Email to SMS solution

Each option is successively more complex to configure, each requiring additional AWS services including Lambda and ultimately DynamoDB tables.    Lets take these options one at a time and hopefully learn something as we attempt these different solutions and learn how to configure them.

Can an Agent Launch a Contact flow?

In order for an Agent to originate an SMS message, we needed to find away for an Agent to launch a Contact flow.   The contact flow can string together the steps we need to generate an outbound SMS.  We can turn on logging, trigger a lambda function, pass in the target phone number and message content and hand the message off to Pinpoint SMS for processing.   How can a agent launch a contact flow?  First we considered using a quick connect in which we could modify one of the default handlers to form the contact flow steps we required.  Unfortunately, with the exception of the External quick connect which had no call flow associated with it, the others required the Agent to have an active call before they could trigger the quick connect.  Drat! Foiled again!

Option 1 – Enter the TASK template!

We discovered that TASK templates might be a solution!  Creating a TASK template we found that we could add custom fields!  Yeah! So lets add a field for a phone number and one for message content! Also we might want to know which agent originated the message so we could route the return message back to that agent.   This started to feel like a real solution and but hen reality set in.  The good news was that you could assign the TASK to a contact flow!  This was very powerful, enabling the Agent to enter the phone and message and then send the TASK to the contact flow where we could invoke Lambda to handle the rest.   That is when the bad news surfaced!  There is no way to pass a custom field as a parameter that you could take advantage of in a “Set Contact Attribute” step.  Ah Snap!

Digging through the documentation we did find that there are only three variables (at the time of this bog) that can be passed as contact attributes.  These are the TASKid, the Name of the Task and the Description of the TASK.  So to solve our problem, we had to play with words such that NAME would now = phoneNumber and Description would now =the  messageContent.   This worked remarkably well and has become our current solution for enabling Agents to originate an outbound SMS message.

Click for Video on the DrVoIP channel!

The advantage of this solution is that you do not need to write any code other than the Lambda handler that your contact flow will invoke to send the outbound SMS through Pinpoint.  The entire solution uses existing Amazon Connect resources: Tasks, Contact Flows and the CHAT API behind the scenes.  The downside is the user interface is not intuitive and agents need to remember which field it the real phoneNumber and messageContent field.  It is not a workable solution if you are concerned about routing a return message to the Agent that originated the message.  If those are not concerns, then this is an effective and easy solution to implement.

Option 2 – Use an HTML form

Given the challenges of launching a contact flow, it might be easier to create a pop up HTML form.  When the Agent wants to originate an SMS message, they click a link that presents an HTML form.  The form has a field for the phone number of the recipient,  the message content.  The form also has a field for the Agent ID, which we will discuss further in part 2.    To enable this configuration we need to string together several AWS services:

  • Pinpoint SMS, which we assume you already have setup and handling inbound SMS to your call center instance!
  • We need to build a static website to host our HTML form.   The website will be built in an S3 bucket, in the same region and account as the Amazon Connect instance.
  • The HTML form needs to POST the form contents to an API Gateway.
  • Lastly, the Gateway needs to launch a lambda function to process the  request and provide a hand off to Pinpoint 2 way SMS.  Putting the api-gateway behind CloudFront as a subdomain defined in Route 53, can assure website security if you couple it with a cognito user group for authentication.

Option 3 – Create an Email to SMS solution

This is the most sophisticated of the three options, but is also the most powerful.  It also is the best solution for enabling a return message to be routed to the Agent that originated the message.   The configuration will require configuring a number of AWS services:

  • You will need access to your DNS records, or you will need to create a new domain in Route53, the AWS DNS service.
  • We will be creating a subdomain.  As our domain is DrVoIP.com our new subdomain will be SMS.DrVoIP.Com.
  • This subdomain will add a MX record in the appropriate DNS.   The MX record will point to an SMTP service, in this case using AWS Simple Email Services (SES).
  • SES will have an email receiving rule that will route any incoming email to this subdomain, to an SNS topic.
  • The SNS topic will trigger a Lambda function.
  • We need a Lambda function that will process the event and parse the recipient phone number, message content and the FROM field of the incoming email.  We will discuss the FROM field part 2 of this blog.

How to get the return message back to the originating Agent?

The next challenge was getting the return SMS message routed back to the Agent who originated the message to begin with.  As noted above, the CHAT stream does not provide a way of extracting attributes.   For example, lets assume your chat conversation asks the visitor (keyboard or SMS) what is the order number they are enquiring about?   We can overcome this with some clever event management and we will discuss this option in Part 2.

Routing a return SMS message to the Agent that originated the message, is a subject we will explore in Part 2 of this blog on Amazon Connect SMS channel management!

 

Configuring Amazon Connect Voice Mail

Posted on by DrVoIP

Configuring Amazon Connect Voice Mail

For several years we have been deploying a modified version of the Amazon Connect Voice Mail solution as published by the AWS team to GitHub!   When Amazon Connect first hit the market in 2017, it was without a voice mail solution.  Actually it was without lots of features that most call center folks would expect!  However, as time unfolds in its petty pace, new features are regularly being added.  Today, Amazon Connect continues to lead the way in call center technology.   The voice mail solution, has changed over the last few years, and though in January of 2024, AWS archived the application and no longer supports it, the solution is still quite useable with a few tweaks.   AWS indicates they are rewriting the solution, but they have not published a target release date.

Dial Agent Direct Option

We have modified the solution in a variety of ways.  For example, many folks want a caller to be able to dial an extension number to reach an agent directly.   We created contact flows to do just that and we rely heavily on the published solution.   You can dial an extension, if the Agent is not available, you can leave a message or transfer off to another agent or customer service queue.  Messages can be transcribed and sent via email or as an SMS message.    Given that you can not “transfer to flow” from within a customer queue hold flow, we build the voice processing option into the hold flow.  In this way you can offer your customers waiting for an agent to become available options that include leave a voice mail.   The voice mail, taken in a customer service queue, can be routed like a phone call to the next available agent as a task.

The voice messaging framework opens up a range of new functionality for the Amazon Connect instance!   Let us know if we can help, just email drvop@drvoip.com and we will get you pointed in the right direction.  There is a YouTube video on this configuration:

 

 

 

 

“Do it yourself” kit for deploying an advanced Amazon Connect Instance!

Posted on by DrVoIP

Dynamic Call Centers?

We can dynamically reconfigure our contact flows, the experience a caller has when calling our contact center.   To do this, we us DNIS (i.e. dialed number information services) essentially using the number the caller dialed, to index a configuration database and return all of the options we need to route an care for the call.   Rather than “cut and paste” contact flows, modified for each queue, why not just use one contact flow that can be reconfigured on the fly?  DNIS is a system attribute in Amazon Connect, it can be passed to the contact flows as such and used to route the caller.   In this solution we provide everything you need to quickly implement a very advanced, flexible and scaleable voice only contact center.

We provide a complete “Do It Yourself” Amazon Connect Contact Center

Core features of this solution include the ability to reconfigure greetings, menus and options based on the DNIS, the number the caller dialed ot reach your call center.   Other features include the option to Directly Dial an Agent, or to have IVR option menus.   Queue hold options include “call back”, leave a voice message for follow up that is queue specific.   Contact flows check staffing, hours of operation and  include after hours call handlers.

What is in the DIY Kit?

In addition to several video tutorials to help the non-engineering professional build out the contact center, we provide all the contact flows ready for you to import!  We provide the lambda functions used to index the configuration database and the dynamodb table descriptions. Each contact flow is heavily commented to enable easy modifications of options and prompts.  Tech Tip videos for installing the voice mail system;  custom agent dashboard and  instructions on how to configure other AWS services that the contact center requires.  Finally, we throw in an hour of technical support to answer your questions!   You will find the package in the DrVoIP.com store!