Migrating custom IVR handlers to Architect Data Actions

Cross-Platform Migrations
1

When migrating custom IVR handlers from PureConnect to GC Architect Data Actions, the biggest challenge is mapping the IC handler’s database queries.

In PureConnect, custom handlers could directly query SQL Server databases. In GC, every external data fetch must go through a Data Action that calls a REST API. If your legacy IVR had 50 SQL queries, you need 50 REST API endpoints built by your backend team first.

2

From a gamification perspective, the migration of IVR handlers affects our self-service containment metrics.

If the legacy IVR resolved 60% of calls via custom handlers (bill payments, order status), and the new Architect flow can only resolve 40% because the Data Actions aren’t built yet, our containment-based KPIs will drop. Agents will get flooded with calls the IVR should have handled.

3

For the NLU-based handlers, you can convert the legacy DTMF-only menus to Architect Bot Flows.

Instead of ‘Press 1 for billing’, the bot can accept natural language: ‘I want to check my bill’. The intent mapping in the Bot Flow JSON looks like:

{
  "intent": "check_bill",
  "utterances": ["check my bill", "billing inquiry", "how much do I owe"],
  "slots": [{"name": "accountNumber", "type": "builtIn:number"}]
}
4

This is a prime opportunity to implement Agent Assist alongside the IVR migration.

If the customer interacts with the bot flow and then transfers to an agent, Agent Assist can surface the exact knowledge article relevant to the customer’s stated intent. The ROI of migrating handlers + deploying Agent Assist simultaneously is significantly higher than doing them sequentially.

5

If you manage multiple orgs (prod/dev/staging), deploy the Data Actions to dev first and validate the response mappings before promoting to production.

We had a Data Action that worked in dev but failed in prod because the backend API URL was hardcoded to the dev environment. Use Terraform variables or CX as Code substitutions to parameterize the endpoint URLs per environment.

6

For a structured migration of IVR handlers, I recommend the following phased approach as documented in our PS engagement template:

  • Phase 1: Identify all custom handlers and categorize by complexity (simple lookup, transactional, multi-step).
  • Phase 2: Build REST API endpoints for each handler’s data source.
  • Phase 3: Create Data Actions and test in sandbox.
  • Phase 4: Build Architect flows that call the Data Actions.
  • Phase 5: UAT with production data (read-only).
7

For our APAC deployment, the Data Action latency to backend APIs is the critical path.

Our legacy IVR handlers queried a local SQL Server in the same data center with sub-10ms latency. The new Data Actions call REST APIs hosted in US-East, adding 200ms round-trip. For an IVR menu with 3 sequential Data Actions, the customer hears a 600ms delay before the response. We had to relocate the API endpoints to the Sydney region.