Client and sector
A UK contact-centre operation handling customer service for a consumer product, running on a contact-centre platform that had been in place for many years alongside separate line-of-business systems.
The operational problem
The platform did its core job. The problem was everything around it. Information captured in a call had to be re-keyed into the line-of-business system. Follow-up actions were tracked in email. Reporting meant exporting from two systems and reconciling them.
The business had looked at replacing the platform and, sensibly, concluded that a full replacement was a large, risky programme it did not want to run under pressure.
Why the existing process wasn't working
- The platform's integration options were dated, and the available interfaces were poorly documented.
- Previous attempts at integration had been point solutions built by individuals who had since left.
- Workarounds had become process: macros, spreadsheets and shared inboxes that only worked if everyone remembered the steps.
- Any change to the workflow was expensive, because it touched several fragile pieces at once.
What was designed
We took the position that the platform should be treated as a data source and a channel, not as the place where the workflow lives.
A small set of integration services was designed to sit in front of the legacy systems and expose the operations the workflows actually needed: look up a customer, log an interaction, create a follow-up, update a status. Everything else was left alone.
The routine hand-offs were then automated against those services, so that a completed call produces the right record and the right follow-up task without an agent re-keying anything.
Technology used
- Microsoft Azure for hosting the integration services and the automation.
- Integration services wrapping the platform's older interfaces behind documented REST APIs.
- Automation for the hand-offs between call outcome, line-of-business update and follow-up task.
- Monitoring and alerting so that a failure in the legacy interface surfaces immediately rather than as a missing record days later.
Integration architecture
The integration layer is deliberately thin. Each service does one thing against the legacy system and exposes it in a modern, versioned API. Workflows call those APIs and never talk to the legacy interfaces directly.
This has two effects. First, the workflow is no longer coupled to how the old platform happens to work. Second, when the platform is eventually replaced, the services are re-pointed at the new system and the workflows carry on.
Human and process considerations
- Agents were part of defining which hand-offs mattered most; the first automations targeted the steps they found most tedious.
- The workarounds were retired one at a time, each after its replacement had run reliably for a period.
- Ownership of the integration layer was agreed with the internal IT team, including documentation and runbooks.
Outcome
Re-keying has been removed from the main call workflows and follow-ups are created by the system. The business has a documented, monitored integration layer it owns, and platform replacement is now a decision it can make on its own timetable rather than a prerequisite for fixing the workflow.
What happened next
The same integration layer is being used to introduce Activ SMS for post-call confirmations, and to evaluate Activ Agent for routine inbound calls, without any further change to the legacy platform.