

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á.

# Criar a arquitetura de base
<a name="create-architecture"></a>

Depois de definir as metas da sua organização e delinear a jornada de contato com o cliente, você pode usar essas informações para definir uma arquitetura de base para o sistema IVR. Esses pontos de dados são essenciais para criar uma arquitetura de IVR que seja modular e escalável. Os princípios fundamentais para criar uma boa estrutura fundamental são:
+ Eliminar o design estático
+ Identificar processos repetíveis

## Eliminar o design estático
<a name="static-design"></a>

Um erro comum que os desenvolvedores cometem ao projetar um sistema IVR é introduzir informações estáticas ou lógica com codificação rígida no fluxo. Essas informações estáticas incluem mensagens de prompts, a definição do próximo fluxo a ser seguido ou o grupo de especialistas para o qual a chamada será roteada. Também pode ser o endereço dos endpoints da API que são invocados de um IVR ou as variáveis retornadas, que são então usadas para a lógica de ramificação no sistema IVR.

O uso de valores estáticos no sistema IVR dificulta o rastreamento e a alteração em tempo real e introduz redundâncias no fluxo. A melhor prática é ter um design dinâmico sempre que possível. Vejamos um exemplo de como projetar um sistema de IVR multilíngue para entender isso melhor.

**Abordagem estática:**

Normalmente, ao projetar um sistema IVR em vários idiomas, os desenvolvedores identificam o idioma preferiencial do cliente e, em seguida, criam duas versões do mesmo fluxo. A primeira versão tem mensagens de prompts com codificação rígida no Idioma A, e a segunda versão pode ter mensagens com codificação rígida no Idioma B, conforme ilustra o diagrama a seguir.

 Essa abordagem é difícil de escalar porque os desenvolvedores precisam manter versões diferentes do mesmo fluxo. Eles também precisam criar uma nova versão do fluxo toda vez que adicionam um novo idioma.

![Abordagem estática no projeto de um sistema IVR](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/ivr-design-on-connect/images/static.png)


Além disso, todas as alterações feitas na lógica de negócios em um fluxo devem ser replicadas manualmente nas outras versões. Isso torna o projeto do IVR confuso e não modular, além de aumentar o tempo de lançamento da inovação no mercado.

**Abordagem dinâmica:**

A abordagem recomendada para resolver esse problema é atribuir mensagens de prompts a variáveis em vez de usar valores estáticos nos blocos de prompts do designer de IVR. Com base na escolha do idioma do cliente, invoque os valores dos prompts de um banco de dados externo e preencha as variáveis para reproduzir essas mensagens, conforme mostrado no fluxograma a seguir. Ao usar essa abordagem, você pode manter um único fluxo de IVR e escalar facilmente para um número *n* de idiomas. Como desenvolvedor, você adiciona prompts de idioma ao banco de dados externo e os invoca (usando uma API) com base na seleção do cliente no sistema IVR ou nos dados retornados de uma consulta de CRM. Isso também protege o sistema IVR de qualquer alteração na lógica de negócios. Ao usar esse modelo, certifique-se de ter uma ramificação padrão com um conjunto mínimo de mensagens estáticas que possam ser usadas no caso de falhas no banco de dados ou na consulta.



![Abordagem dinâmica na concepção de um sistema IVR](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/ivr-design-on-connect/images/dynamic.png)


## Identificação de processos repetíveis
<a name="repeatable-processes"></a>

Identificação de padrões repetíveis na experiência do cliente pode ajudar a eliminar componentes redundantes em seu sistema IVR. Você pode criar lógica ou módulos reutilizáveis para casos de uso repetidos e invocá-los conforme necessário em vários fluxos de chamadas. Por exemplo, se as equipes de vendas e de suporte precisarem enviar uma notificação por SMS dentro do sistema IVR, você poderá criar um único módulo de *envio de SMS* reutilizável que possa ser usado em ambas as linhas de negócios. Ao usar essa abordagem, você pode manter um único fluxo, e todas as atualizações desse módulo serão refletidas em todos os LOBs de forma otimizada. Alguns outros exemplos comuns de processos repetíveis são:
+ Atribuição da seleção de idioma ao fluxo de IVR com base nas informações do cliente.
+ Implementação do processamento de pagamentos no sistema IVR.
+ Lógica de autenticação do chamador.
+ Identificação de um cliente usando uma pesquisa de CRM. Ao modularizar o módulo de pesquisa de clientes em seu CRM, você pode transformar conexões específicas, que geralmente usam linguagens proprietárias, em blocos de IVR simples. Qualquer pessoa que desenvolva experiências de clientes pode então acessar e usar esses blocos de IVR.
+ Execução do roteamento de mensagens de emergência.