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 Amazon Connect
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 uma central de atendimento na nuvem usando o Amazon Connect.
Normalmente, as equipes de negócios desejam adicionar funcionalidades e recursos e, ao mesmo tempo, tornar a experiência de autoatendimento mais personalizada. Arquitetos técnicos e desenvolvedores 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 melhores práticas que eles podem usar para criar o design básico de seu aplicativo 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 Amazon Connect. O Amazon Lex, que permite adicionar recursos de linguagem natural (NL) ao seu aplicativo de IVR, está fora do escopo.
Visão geral
Os métodos tradicionais de design 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). Freqüentemente, eles confiam no talento de voz humana para criar solicitações, que são então enviadas e referenciadas em scripts codificados. Isso complica o processo de fazer alterações e atualizações, especialmente em tempo real para emergências ou anúncios urgentes. Quando os aplicativos são separados 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 back-end com bancos de dados, soluções de gerenciamento de relacionamento com o cliente (CRM) ou outros sistemas de terceiros geralmente são codificadas, o que significa que as alterações precisam ser replicadas manualmente em vários aplicativos.
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, as experiências comerciais aumentaram o tempo de resposta das atualizações típicas. Uma arquitetura complicada que envolve esses ciclos de desenvolvimento complexos e demorados resulta em aumento de custos.
Este guia se concentra em uma arquitetura fundamental para um aplicativo de IVR que ajuda a eliminar redundâncias e simplifica o processo de gerenciamento de mudanças. Essa arquitetura facilita a manutenção e a inovação dos desenvolvedores, além de fornecer às empresas a agilidade de que precisam.
Índice
