View a markdown version of this page

Melhores práticas para criar a base de uma experiência de IVR dinâmica e modular no Connect Customer - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Melhores práticas para criar a base de uma experiência de IVR dinâmica e modular no Connect Customer

Ayesha Borker e Nicholas Pung, Amazon Web Services (AWS)

Agosto de 2023 (histórico do documento)

Arquitetos técnicos, desenvolvedores e equipes de negócios têm a oportunidade de reimaginar as experiências automatizadas de autoatendimento que oferecem aos clientes quando migram para um contact center baseado em nuvem usando o Connect Customer.

Normalmente, as equipes de negócios desejam adicionar funcionalidades e recursos e, ao mesmo tempo, tornar a experiência de autoatendimento mais personalizada. Desenvolvedores e arquitetos técnicos se concentram principalmente em como reduzir a redundância, permitir mudanças e flexibilidade rápidas, modularizar processos repetidos e diminuir a sobrecarga de manutenção.

Este guia fornece aos arquitetos técnicos um conjunto de práticas recomendadas que eles podem usar para criar o design básico de sua aplicação de resposta de voz interativa (IVR) de forma modular e dinâmica. Ele fornece exemplos de sistemas IVR (ou seja, tecnologias de voz). No entanto, você pode estender os mesmos conceitos para qualquer outro canal. O guia se concentra na criação de um design de IVR modular e escalável usando fluxos e módulos do Connect Customer. O Amazon Lex, que permite adicionar recursos de linguagem natural (NL) à sua aplicação de IVR, está fora do escopo.

Visão geral do

Os métodos tradicionais de um projeto de experiência de IVR podem ser estáticos e complexos. As organizações geralmente gerenciam experiências separadas para diferentes idiomas, ambientes de implantação (como desenvolvimento, teste e produção), países e linhas de negócios (LOBs). Frequentemente, elas contam com o talento de voz humana para criar prompts, que são então enviados e referenciados em scripts com codificação rígida. Isso complica o processo de fazer alterações e atualizações, especialmente em tempo real para emergências ou anúncios urgentes. Quando as aplicações são separadas dessa maneira, geralmente observamos que casos de uso comuns se repetem e são gerenciados de forma redundante. Exemplos comuns incluem a entrada de pagamentos em um sistema IVR ou o envio de um SMS pós-transação. As integrações de backend com bancos de dados, soluções de gerenciamento de relacionamento com o cliente (CRM) ou outros sistemas de terceiros geralmente têm codificação rígida, o que significa que as alterações precisam ser replicadas manualmente em várias aplicações.

Esse tipo de projeto de arquitetura monolítica leva a processos administrativos excessivos e sobrecarga de gerenciamento, além de impedir a inovação. Os desenvolvedores passam mais tempo implementando pequenas mudanças em várias dependências, o que dificulta o acompanhamento de processos ágeis. Muitas vezes, essa complexidade se torna onerosa e as empresas precisam contar com organizações de serviços profissionais ou consultores externos para ajudar a gerenciar essas mudanças. Como resultado, a empresa enfrenta um aumento no tempo de resposta para atualizações rotineiras. Uma arquitetura complicada que envolve esses ciclos de desenvolvimento complexos e demorados resulta em aumento de custos.

Este guia se concentra em uma arquitetura de base para uma aplicação de IVR que ajuda a eliminar redundâncias e otimiza o processo de gerenciamento de mudanças. Essa arquitetura facilita a manutenção e a inovação para os desenvolvedores, além de fornecer às empresas a agilidade de que precisam.

Índice