Armakuni Contact us
← All case studies

Their move to Amazon Connect was stuck behind 2,500 call scripts.
So we built the thing that converts them.

A contact-center outsourcer serving more than 300 organizations was paying for two platforms while its migration stalled. We steadied its biggest client's launch, automated the script conversion and rebuilt every greeting and menu. AWS funded the work, so it cost the client nothing.

Before

Paying for two platforms while the move stalled.

After
2,200+audio files converted and live
2,500+call scripts with an engine to convert them
4shared contact flows instead of hundreds

Paying for two platforms while the move stalled

The outsourcer runs phones, SMS, email and chat for more than 300 organizations. Every one of them has its own greeting, menu, script and rules for what happens next.

It had committed to moving the whole operation onto Amazon Connect, and the move had stopped. Until it finished, the business paid for the old platform and the new one, plus the people needed to run both. Every month without a cutover cost more, and none of it moved the cutover closer.

A call script is a small program

The reason was the scripts. On a screen, a call script looks like text for the person on the call to read. Underneath, it's a workflow. It branches on the caller's answers and checks them. It looks people up in a directory, sends emails and texts, dispatches someone on call, and changes its behavior after hours.

Copy the words across and all of that is lost. So the team was rebuilding 2,500 scripts by hand, one at a time, and after months there was still no end in sight.

A major client was already live on a setup that wasn't ready

Meanwhile, one of the platform's most important clients, a major energy company, was already running on Amazon Connect in a state that wasn't ready for production, and every other client would have heard about a failure there.

How we built it

5 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. First, the client that could sink the rest
  2. Read the scripts before converting any
  3. Converting what each script does, so one flow serves them all
  4. Four contact flows instead of hundreds
  5. The right script, the moment the call connects

First, the client that could sink the rest

Built withConnect
The riskiest client firstThen the rest
The engineering

A stalled migration tempts you to start on the backlog. We started with the energy client, because a failure there would have cost more than any delay. Our engineers reviewed its Amazon Connect setup: the contact flows, the integrations and the release process. Hands-on flow remediation and structured functional testing brought the deployment to a stable, production-ready state.

The fixes weren't enough by themselves. A deployment that anyone can still change by hand doesn't stay stable, so release-process improvements put every later change through the same governed path. Real-time observability let the operations team see platform health while calls were running, rather than hearing about it from a customer. In a business that sells reliability to 300 clients, one visible failure costs more than a month of delay.

Read the scripts before converting any

Built withConnect
2,500 scripts, read first Branching1Validation2Lookups3Fan-outs4 then build the converter
The engineering

Before building anything to convert 2,500 scripts, we needed to know what was in them. We mapped the structure and logic of all 2,500+ against the Amazon Connect contact flow model. We documented each client's CRM and API dependencies, and captured the compliance rules that travel with the calls: call-recording policies and data retention requirements.

The assessment produced a multi-tenant target architecture for one Amazon Connect deployment shared by every client, a prioritized migration roadmap across all client programs, a preliminary cost estimate and the scope for the next phase. That's the plan the rest of the work followed.

Converting what each script does, so one flow serves them all

Built withConnect
Multi-page flowsDirectory lookupsDispatch logic Its behaviour
The engineering

There were two ways to move the scripts. One was to rebuild each as its own Amazon Connect contact flow, by hand, which is what had stalled, and which would have left 2,500 flows to test on every release afterwards. The other was to treat the scripts as data. We chose data.

We built a parsing and conversion engine that reads each legacy script and translates it into structured data, which a new application renders inside Amazon Connect at run time. So the contact flows stay few, and the scripts become content. The engine carries across everything that made a script a workflow:

  • Multi-page call flows, conditional branching, validation steps and shared modules
  • Directory lookups, and email and SMS fan-outs to several recipients
  • Complex dispatch logic, business-hours and after-hours conditional rendering, and on-call dial-outs

At this scale a converter can't be trusted on its word. Validation gates sit between each stage of the pipeline, and a script can't advance until it passes every check, so a broken conversion stops at a gate rather than on a live call.

Converted scripts open in a web-based visual editor, where the operations team can review, edit and duplicate them without writing code, and the editor keeps the original logic intact. The people who know each client own its script, without an engineer in the way.

Four contact flows instead of hundreds

Built withConnect
FlowFlowFlow… hundreds Four flows 2,200+ client audio files in production
The engineering

Callers hear a greeting, and often a menu, before anyone answers, and both layers had to be rebuilt on Amazon Connect for every client. The obvious build is a contact flow for each client: more than 300 flows, each one another thing to change and to test.

Instead, four shared contact flows are driven entirely by client configuration data, which selects each client's greeting and menu behavior. About 40% of the platform's numbers run a menu, and each option can route to a different client subaccount while keeping its own script and billing identity. Adding a client, updating a greeting or restructuring a menu is a configuration change rather than a contact-flow build.

Why: every flow built for one client is one more flow to retest on every release.

The audio was its own problem. Clients had sent their recordings in every format there is: studio files, recordings made in the office, audio exported from their last provider. Telephone networks need a narrow, specific audio format, and almost none of it could be used as delivered. So we built a conversion process that resamples each file to the telephone format, normalizes levels so volume is consistent across clients, and splits combined recordings into individual menu prompts. We verified each result on a live call. More than 2,200 client audio files are now in production.

The right script, the moment the call connects

Built withConnect
The call connectsThe client's script appearsThe agent reads it
The engineering

A converted script is no use if the person on the call has to go and find it. We built the application that renders the scripts and embedded it in the Amazon Connect agent workspace, beside the softphone.

When a call arrives, the application identifies the signed-in agent, pulls the caller and call information from the live workspace and loads that client's script automatically. For the first time, each client's own workflow is on screen at the moment the call connects, next to the call controls, with no lookup in a separate system.

One call, end to end

Put together, a call into one of the 300+ clients now runs like this:

  1. The number answers on one of four shared contact flows. The flow reads that client's configuration data to pick its greeting.
  2. The greeting plays, in the telephone format, at the same volume as every other client's, from audio we converted and checked on a live call.
  3. About 40% of numbers then offer a menu. The option the caller picks routes to the right client subaccount, carrying its own script and billing identity.
  4. The call reaches a person. In the Amazon Connect agent workspace, beside the softphone, the application has already identified the signed-in agent, read the caller and call information and opened the client's script.
  5. The script runs as a workflow, not a page. It branches on the answers, checks them, looks people up in the directory, sends the email and SMS fan-outs and, after hours, dials whoever is on call.
  6. Behind it, every script got there through validation gates, and every change to the platform goes through the governed release process, with real-time observability watching it in service.

What we'd tell another CTO

1Steady the client everyone is watching before you scale anything; the migration's credibility rested on the energy client.
2When the same work has to be done 2,500 times, build the machine and gate it. Rebuilding by hand was what had stalled, and the validation gates mean a broken conversion stops before a caller ever hears it.
3A script turned into data is a workflow written down, which is the starting point AI agents need.

What else changed

  • The energy client is stable, on tested contact flows, with monitoring and a proper release process.
  • One screen for the people taking calls, with each client's script loaded as the call connects.
  • A migration plan across all 300+ clients, based on what the assessment found in the scripts.
  • No cost to the client: AWS funded the work.

What comes next

The roadmap's last step is the full cutover and legacy-platform retirement, which is what ends the dual-platform cost. The conversion engine and the plan give the business a way to finish it.

We've also assessed what the converted scripts make possible. Now that each script is structured data, the workflow is written down in a form AI agents can follow, and that assessment gives the leadership team a concrete view of AI handling calls in the next phase.

How we'd do it today

This project came before our current accelerators. Here's how we'd approach the same work now.

Today the move would start with FlowShift, which reads the old platform's setup and rebuilds it for Amazon Connect after a dry run that gives every item a verdict and a confidence score. For a typical Genesys Cloud setup, our estimate is that 75–80% converts automatically, ready to import; it runs automatically for Genesys Cloud today, and Avaya starts with a validation phase. Then comes the Compliant Connect Accelerator, an eight-step wizard that builds Amazon Connect in the business's own AWS account, unattended, in about 25 to 45 minutes, with AWS KMS keys, Amazon S3 storage, AWS CloudTrail logging, and Amazon GuardDuty and AWS Security Hub monitoring, and every control mapped to its rule (HIPAA, PCI DSS, GDPR, TCPA). Amazon Connect gives a tool 30 seconds to answer, so slow systems would get a faster path. For AI agents following the converted scripts, AK AI Factory would give each client's AI agent its own identity and only that client's tools, so one client's AI agent can't reach another's systems, and a per-client golden set of real conversations would gate every change. Sonic would score every call from 0 to 100, from eight ratings, with the calls worth a coaching conversation picked each night, and ComplianceGen would turn each client's compliance documents into cited rules on screen during the call.

Amazon Connect Modernize with AI AK AI Factory

More work like this

  1. Amazon ConnectProvedA U.S. benefits technology companyan AI agent on Amazon Connect can carry the 10–15-minute enrollment callIn enrollment season, they turned customers away. There weren't enough counselors to take the calls.100,000+ enrollment calls a year10–15 minutes for each of those callsOn AWS Connect · Nova Sonic · Lambda · DynamoDB
  2. Amazon Connect4 weeksA Medicare enrollment contact centerto the first honest baseline of the contact centerIts own leaders rated the platform 4 out of 10. Medicare enrollment season was coming anyway.600 people on a steadier platform3 Medicare Advantage health-plan clientsOn AWS Connect · Contact Lens · Lambda · DynamoDB
  3. Amazon Connect$500K+A U.S. benefits platforma year saved, as reportedThey asked for a new phone system. The real problem was everything after the call.70% faster document processing40% more consistent eligibility checksOn AWS Connect · Bedrock · Textract · Nova Sonic

All case studies →

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop