A primeira etapa na transição para o é garantir uma conectividade confiável e segura com a Internet entre a rede local e a nuvem.

Como a maioria das organizações se conecta à Internet por meio de um ou mais firewalls ou dispositivos de segurança, é essencial validar se os fluxos de tráfego necessários são suportados.

Os administradores de rede e segurança devem entender esses fluxos em termos de:

• Direção (entrada versus saída)

• Protocolos (exemplo - SIP TLS, SRTP, HTTPS)

• Intervalos de endereços IP usados pelos serviços

• Números de porta que devem ser abertos ou permitidos.

Isso garante que firewalls corporativos, dispositivos NAT e outras infraestruturas de rede sejam configurados adequadamente para acomodar o tráfego e, ao mesmo tempo, manter as políticas de segurança da empresa.

Para obter informações sobre os fluxos necessários, incluindo endereço IP, portas e protocolos, consulte Informações de referência de portas para Webex Calling. Use essas informações para configurar o firewall, os proxies e outras infraestruturas de rede na implantação existente para ativar fluxos de rede.

O acesso descentralizado à Internet a partir de cada filial ou site é a abordagem recomendada para serviços de colaboração em nuvem, como. Ao permitir que o tráfego saia localmente, esse modelo:

• Reduz o atraso de ida e volta e a instabilidade, melhorando a qualidade geral das chamadas

• Dimensiona de forma eficiente à medida que mais usuários e sites fazem a transição para

• Funciona perfeitamente com a SD-WAN, que pode rotear sessões dinamicamente para o ponto de entrada de nuvem mais próximo para otimizar o desempenho

• Permite rastrear a localização do usuário com base em seu endereço IP público, o que ajuda na análise do caminho de mídia e na solução de problemas.

Além disso, as organizações devem garantir uma largura de banda de internet adequada em cada site. A largura de banda deve ser dimensionada com base no número esperado de chamadas simultâneas, no codec selecionado (por exemplo, Opus ou G.711), além da sobrecarga de sinalização, retransmissão e crescimento. Isso se alinha à fase de preparação do ciclo de vida do PPDIO e estabelece uma base sólida para a migração.

A subseção de configuração inicial na fase de implementação da implantação é fundamental para estabelecer um ambiente de chamadas na nuvem bem estruturado e gerenciável. Esse estágio engloba tarefas críticas, como configurar a organização, adquirir e atribuir licenças e verificar e reivindicar os domínios da sua empresa para garantir o gerenciamento e a segurança adequados dos usuários. Além disso, inclui o provisionamento de modelos de licença para automatizar as atribuições de licenças de usuários, configurar o Single Sign-On (SSO) para simplificar a autenticação do usuário e aprimorar a segurança e ajustar as configurações do serviço e do cliente para se alinharem às políticas organizacionais e às necessidades do usuário. A conclusão dessas atividades de configuração inicial garante que o ambiente seja configurado adequadamente para escalabilidade, segurança e experiência perfeita do usuário, preparando o cenário para as fases operacionais e de implantação subsequentes.

Durante a fase de implementação, a execução de uma migração piloto representa um marco crítico na validação da transição de para. Esse piloto envolve o provisionamento de um subconjunto representativo de usuários em um ou mais locais na plataforma, garantindo que a população selecionada reflita diversos casos de uso e funções organizacionais. Paralelamente à migração de usuários, os serviços essenciais de colaboração, incluindo correio de voz, atendedores automáticos, filas de chamadas e grupos de busca, devem ser transferidos para seus equivalentes para manter a continuidade dos negócios e a funcionalidade do serviço.

A migração piloto deve aproveitar a mesma combinação de ferramentas fornecidas pela Cisco e utilitários de migração de terceiros planejados para a implantação organizacional mais ampla, garantindo que os processos, fluxos de trabalho de automação e pontos de integração sejam totalmente validados sob condições representativas.

Os principais objetivos dessa implantação piloto são dois: primeiro, validar e refinar os processos de transição de ponta a ponta, incluindo fluxos de trabalho de provisionamento de usuários, procedimentos de migração de dados e configurações de terminais; e segundo, verificar de forma abrangente a funcionalidade dos serviços migrados em condições operacionais reais.

Essa abordagem em fases permite que a equipe do projeto identifique e corrija quaisquer problemas técnicos ou processuais em um ambiente controlado, colete feedback dos usuários sobre a nova experiência da plataforma, avalie a eficácia das ferramentas de migração selecionadas e estabeleça confiança na metodologia de migração antes de prosseguir com uma implantação organizacional mais ampla.

Os insights obtidos durante essa fase piloto são fundamentais para otimizar as ondas de migração subsequentes e garantir uma transição suave e com redução de riscos para toda a empresa.

Para adquirir serviços PSTN para, primeiro selecione uma opção de conectividade PSTN no.

Se uma organização planeja manter o controle híbrido de chamadas duplas (fase 1 na figura Transição de chamadas em fases: híbrida e nuvem) temporária ou indefinidamente, ela precisará implantar um ou mais gateways locais para PSTN local para permitir chamadas entre terminais e terminais.

Se uma transição completa (fase 2) para a nuvem for o objetivo final, incluindo a PSTN, será necessário um plano de chamadas da Cisco ou uma opção Cloud Connect for para a PSTN.

Trabalhe com o provedor escolhido para solicitar e transferir números de telefone antes de configurá-los. Solicitar números de telefone ou iniciar pedidos de portas só é necessário/possível para o PSTN local e o Cloud Connect for. Para os planos de chamadas da Cisco, o pedido e a portabilidade são iniciados no Control Hub assim que o local é criado e em países onde o Cisco Calling Plan está disponível. Para obter mais informações sobre os planos do Cisco Calling, consulte Introdução aos planos da Cisco.

Como parte da implementação da PSTN, certifique-se de que seu provedor tenha habilitado os serviços de PSTN de entrada e saída para sua localização. Além disso, realize chamadas de teste para verificar se as chamadas estão sendo roteadas corretamente por meio da conexão PSTN escolhida.

Antes de adicionar usuários e dispositivos, você deve provisionar locais de chamada. Para cada local, um endereço válido deve ser inserido. Nos EUA e no Canadá, esse endereço é validado e usado pela plataforma para enviar informações de localização do PIDF-LO para chamadas de emergência.

Ao configurar locais que usam PSTN local, você precisa configurar os gateways locais adequadamente. Em, um tronco e um grupo de rotas devem ser criados para cada gateway local, e o grupo de rotas é então atribuído como a escolha de PSTN para o local. A Cisco recomenda sempre selecionar um grupo de rotas como opção de PSTN, pois essa abordagem permite que você adicione facilmente troncos adicionais no futuro, suportando tanto a escalabilidade quanto a redundância. A Cisco também recomenda ativar o suporte de identidade dupla e P-Charge-Info em cada tronco PSTN, pois isso simplifica a identificação da parte cobrável para chamadas diretas ou desviadas de saída. Se seu provedor de PSTN usar um cabeçalho diferente para cobrança, você poderá copiar as informações do cabeçalho P-Charge-Info no gateway local para o cabeçalho de cobrança necessário.

Para locais que usam o Cloud Connect for ou o Cisco Calling Plan como opção de PSTN, basta selecionar a respectiva opção de PSTN para o local durante a configuração. Se o local usar o Cloud Connect for ou o PSTN local, você precisará adicionar os números de telefone que foram pedidos na etapa anterior. Os números podem ser adicionados como inativos se você não quiser que eles sejam incluídos imediatamente no roteamento de chamadas; você pode ativar esses números posteriormente, quando forem atribuídos a usuários ou recursos.

É importante sempre definir o número principal de cada local. O número principal pode ser atribuído a um usuário ou a um recurso, como um atendedor automático. Para ativar o correio de voz no local, certifique-se de definir o número piloto do correio de voz, também conhecido como número do portal de voz.

As configurações adicionais para locais de chamada incluem a configuração de detalhes de chamadas de emergência, como número de retorno de chamada de emergência, opções de notificação e recursos aprimorados de chamadas de emergência. Você também deve revisar e ajustar as configurações de gravação, as preferências de idioma e as configurações do dispositivo conforme necessário para cada local. Se sua organização usa discagem na rede abreviada entre sites com números corporativos significativos, lembre-se de configurar um código de site exclusivo para o local nas configurações de discagem interna. Finalmente, se a discagem externa exigir um dígito de discagem externa, certifique-se de defini-lo nas configurações de discagem externa. Quando um dígito de discagem externa é configurado, a Cisco recomenda ativar a imposição de dígitos de discagem externa para garantir a consistência.

Para se integrar ao controle de chamadas local, é necessário configurar troncos, grupos de rotas, planos de discagem corporativos e configurações globais e de localização. Comece configurando os troncos e os gateways locais destinados à interconexão com o sistema de controle de chamadas local; essa etapa só é necessária se forem necessários troncos dedicados. Se os troncos e grupos de rotas existentes forem suficientes para sua implantação, eles poderão ser reutilizados para a interconexão local sem configuração adicional.

Depois que os troncos e os grupos de rotas forem estabelecidos, continue criando os planos de discagem corporativos e atribua o grupo de rotas apropriado como destino para cada plano de discagem. Quando a integração envolve vários sistemas de controle de chamadas locais conectados por meio de diferentes troncos, vários planos de discagem serão necessários. É importante garantir que esses planos de discagem contenham somente os padrões necessários para rotear chamadas para destinos locais.

Se sua implantação exigir suporte para roteamento de extensões desconhecidas, esse recurso deverá ser ativado no nível do local. Além disso, quando o roteamento de ramais desconhecidos é ativado, você deve especificar o tamanho máximo do ramal desconhecido na seção Roteamento de chamadas entre e locais das configurações de serviços de chamada em. Isso garante o roteamento perfeito de chamadas e o tratamento adequado de cenários de discagem com base em ramais em seu ambiente integrado.

Ao migrar usuários de para, talvez você não consiga mover todos os usuários ao mesmo tempo. Isso pode ser devido a vários motivos, incluindo, mas não se limitando ao número de sites ou usuários, quanto tempo leva para fazer a transição de um site e/ou grupo de usuários ao mesmo tempo, recursos limitados de TI ou do site para dar suporte à janela de mudança, duração da janela de alteração, complexidade da mudança etc.

Quando você migra usuários em fases, é fundamental identificar quais usuários precisam migrar juntos no mesmo lote. O objetivo principal é migrar usuários que dependem uns dos outros em seus serviços e recursos de chamada. Você deseja garantir que todos os recursos de chamada (por exemplo, filas de chamadas) estejam totalmente funcionais como estavam antes da transição.

Mesmo que você implemente a interconexão de chamadas entre e com os gateways locais, não é possível dividir serviços ou recursos compartilhados nessa conexão. Portanto, você precisa identificar as dependências entre os usuários analisando recursos como:

• Monitorando outros usuários usando BLFs

• Na mesma caça, piloto, fila de chamadas, etc.

• Linhas compartilhadas

• Usando o atendimento de chamadas

• Usando os mesmos números do call park

• Intercomunicador

• Executivo/Administrador.

Um exemplo seria um usuário que faz parte de um Grupo de Busca para o qual está sendo transferido. Esse usuário fará a transição para o Grupo de Caçada e com todos os outros membros do Grupo de Caçada. Portanto, após a transição, o Hunt Group e seus membros podem atender chamadas com sucesso na nova plataforma.

Isso se torna mais desafiador quando os usuários estão conectados a diferentes grupos de usuários para diferentes serviços e recursos de chamada. Isso exigirá a transição de mais de um grupo de usuários e um serviço de chamadas ao mesmo tempo.

Use a saída da ferramenta Migration Insights ou da ferramenta de terceiros que você usou na fase de preparação para determinar quais usuários e recursos devem ser agrupados. Essa saída deve ter sido usada para desenvolver seu plano de migração e fornecerá informações sobre como você agrupará usuários e recursos que precisam fazer a transição juntos.

As principais etapas ao fazer a transição de um lote de usuários são:

• Identificação de usuários para migrarem juntos

• Verifique se todos os usuários estão conectados

• Verifique se todos os TNs dos usuários existem em

• Verifique o formato correto do número de telefone no diretório

• Certifique-se de que o licenciamento e o modelo de configurações para os grupos de usuários estejam configurados corretamente

• Verificar ou configurar todos os serviços e recursos de chamada para o grupo de usuários (antes ou durante a transição, conforme apropriado)

• No diretório corporativo, adicione usuários a um grupo de usuários habilitados para fazer chamadas.

• Ferramentas de alavancagem — ferramentas de migração de usuários e recursos e/ou ferramentas de terceiros

• Desative/exclua o número do diretório de usuário/dispositivo e os recursos/serviços de chamada após a transição.

Após a migração de um grupo de usuários, teste um subconjunto dos usuários para validar se todos os recursos e serviços de chamada estão funcionando corretamente. Se recursos de chamada, como fila de chamadas, grupos de busca etc. forem transferidos com o grupo de usuários, teste esses serviços de chamada para verificar a funcionalidade adequada .

Em, um espaço de trabalho se refere a um local compartilhado (como uma sala de conferência, espaço de reunião ou mesa ativa) ao qual podem ser atribuídos dispositivos, extensões e usuários. Ao contrário dos telefones Unified CM tradicionais, os espaços de trabalho são:

• Centrado na localização: vinculado a espaços físicos.

• Dispositivo flexível: pode ter um ou mais dispositivos (telefones de mesa, placas, etc.).

Depois que os espaços de trabalho forem identificados como parte da transição para, eles poderão ser adicionados em Dispositivos. Cada espaço de trabalho precisa ser atribuído a um dispositivo e, se já estiver instaladoUnified CM, precisará ser redefinido ou reprovisionado. recursos como correio de voz, encaminhamento de chamadas e atendimento de chamadas podem ser ativados ou desativados, e as políticas podem ser aplicadas para videochamadas, estacionamento de chamadas e mobilidade, conforme necessário. Teste cada espaço de trabalho fazendo chamadas internas e externas, testando recursos de vídeo, conferência e mobilidade . Por fim, informe os usuários sobre quaisquer processos aplicáveis aos dispositivos e reservas do espaço de trabalho.

Para obter mais informações sobre espaços de trabalho em, consulte Espaços de trabalho.

Os telefones atualmente registrados precisarão ser migrados como parte da transição para a nuvem. Para tornar a migração o mais simples possível com o mínimo de chance de falha, a Cisco recomenda migrar sites ou departamentos físicos ao mesmo tempo. No entanto, talvez seja necessário migrar usuários em lotes devido às dependências de recursos. Consulte a seção Migrar usuários em lotes para obter mais detalhes .

Todos os telefones compatíveis dos quais você precise fazer a transição precisarão ser configurados como usuário ou espaço de trabalho, e o telefone físico precisará ser reconfigurado para se registrar. Além disso, os telefones das séries 7800 e 8800 precisam que seu firmware seja atualizado do firmware corporativo para o firmware do telefone multiplataforma (MPP). Esse processo inclui carregar o firmware de transição antes de carregar o firmware MPP necessário para o registro. Também requer a licença de migração apropriada. A Cisco aprimorou esse processo nos últimos anos para facilitar a atualização de seus telefones com firmware corporativo para o firmware MPP. Para obter mais informações sobre as etapas para concluir a atualização do firmware, consulte Converter telefones IP das séries Cisco 7800 e 8800 entre o firmware Enterprise e MPP.

Além das etapas descritas neste artigo, tem uma ferramenta embutida, Migrate your phone toWebex Calling, que você pode usar para ajudar a migrar seus telefones 7800 e 8800 do firmware Enterprise para o MPP. Essa ferramenta também permite adicionar os telefones e atribuí-los aos usuários ou espaços de trabalho apropriados. Para obter mais informações sobre o uso da ferramenta, consulte Migrar seu telefone.

Para qualquer telefone da série 9800 registrado com o requisito de migração de firmware acima não se aplica. Esses telefones executam o PhoneOS, que é compatível com e. Para fazer a transição desses telefones para você, você precisará adicioná-losWebex Calling, atribuí-los a um usuário ou espaço de trabalho e, em seguida, redefinir os telefones para as configurações de fábrica. A sequência de inicialização do PhoneOS para registro, a figura abaixo mostra a sequência de inicialização do PhoneOS e como o telefone será registrado depois de adicionado, mesmo que o telefone ainda esteja provisionado e/ou as opções DHCP (exemplo - 150) estejam em uso.

suporta a redefinição de fábrica de dispositivos PhoneOS para permitir a integração Zero-Touch ao. os administradores podem redefinir remotamente as configurações de fábrica dos telefones 9800 e 8875 por meio das páginas de administração do CUCM, o que elimina a necessidade de acesso físico aos telefones para integrar os telefones. Esse recurso é compatível com os pacotes de dispositivos a partir de 9 de setembro de 2025:

• CUCM v15 - Versão 15 do Unified Communications Manager

• CUCM v14 - Versão 14 do Unified Communications Manager.

Para obter mais informações sobre o processo de registro da série 9800, consulte Processo de registro.

Além dos telefones IP Cisco, pode ser necessário o provisionamento de outros dispositivos, como adaptadores telefônicos analógicos (ATAs), telefones sem fio (Wi-Fi, DECT), dispositivos de vídeo, gateways de voz e dispositivos e telefones de ^terceiros. Muitos desses dispositivos não têm um caminho de atualização de firmware, como os telefones IP, para fazer a transição do firmware corporativo para o firmware na nuvem. Portanto, você provisionará cada um desses dispositivos no Control Hub. Alguns deles não podem ser transferidos e o modelo equivalente precisará substituí-los (por exemplo. ATA 191/192) e outros exigirão reconfiguração manual e/ou alterações de software.

• Gateways de voz - Para migrar seu gateway local, consulte Migrar gateway local.

  Para obter mais informações sobre como configurar seu gateway de voz VG400, VG410 ou VG420 no Control Hub, consulte Gateway local

• Adaptador de telefone analógico (ATA) - Para começar a usar o Cisco ATA 191 e 192, consulte Cisco ATA.

• Telefone sem fio Wi-Fi - Para integrar o telefone sem fio 840 e 860, consulte Integrar o telefone sem fio Webex .

• Telefones sem fio DECT - Para começar a usar sua nova série Cisco IP DECT 6800, consulte Cisco IP DECT.

  Para criar e gerenciar a rede DECT digital no Control Hub, consulte Gerenciar rede DECT

  Para obter mais informações sobre o Cisco IP DECT 6800, consulte o guia de implantação

• Dispositivos e telefones de ^{terceiros - trabalhe com fornecedores terceirizados sobre os requisitos de dispositivo/telefone e o processo para migrá-los ou substituí-los pelo suporte.}

Todos os recursos de chamada necessários precisam ser provisionados antes ou durante a transição. Conforme discutido na seção Migrar usuários em lotes, os recursos de chamada precisam ser configurados e transferidos quando os usuários que os estão usando são transferidos.

Para obter detalhes sobre como configurar cada um dos recursos, consulte os artigos de ajuda de configuração correspondentes.

• Atendedores automáticos - Para gerenciar atendedores automáticos, consulte Atendedores automáticos

• Parque de chamadas - Para gerenciar o parque de chamadas, consulte Parque de chamadas

• Captação de chamadas - Para configurar o grupo de coleta de chamadas, consulte Captação de chamadas

• Filas de chamadas - Para configurar a fila de chamadas, consulte Fila de chamadas

• Grupos de caça - Para gerenciar grupos de busca, consulte Gerenciar grupo de busca

• Modos operacionais - Para roteamento de chamadas com base nos modos operacionais, consulte Roteamento de chamadas com base nos modos operacionais

• Grupos de paginação - Para configurar um grupo de paginação, consulte Configurar um grupo de paginação

• Gravações - Para gerenciar a gravação de chamadas, consulte Gerenciar gravações

• Alcance de número único - Para configurar o alcance de um único número (escritório em qualquer lugar), consulte Configurar número único

• Grupo de correio de voz - Para gerenciar um correio de voz compartilhado e uma caixa de fax de entrada para, consulte Gerenciar correio de voz.

O teste de aceitação garante que o ambiente migrado atenda aos requisitos funcionais, opere conforme o esperado e ofereça uma experiência de usuário perfeita em todos os fluxos de trabalho de comunicação. Esse processo de validação é multifacetado, abrangendo tudo, desde o aprovisionamento de usuários e atribuições de números até o desempenho operacional de recursos avançados de chamada.

Esta seção fornece exemplos e destaca os principais aspectos a serem considerados durante o teste de aceitação; no entanto, não se destina a servir como uma lista de verificação exaustiva ou abrangente.

Provisionamento de usuários e atribuição de números

Um aspecto fundamental do teste de aceitação envolve verificar se todos os usuários estão provisionados de forma precisa e completa. Isso requer uma comparação completa entre o diretório source () e a base de usuários recém-estabelecida para garantir que todas as contas de usuário, juntamente com os atributos associados, como números de ramais e atribuições de discagem interna direta (DID), tenham sido migradas corretamente. A integridade do provisionamento é essencial não apenas para a operabilidade do primeiro dia, mas também para a administração e o suporte contínuos.

A validação da atribuição de números inclui a confirmação de que cada usuário recebeu o ramal e o número externo corretos e que esses números são roteados corretamente nos fluxos de chamadas internos (na rede) e externos (PSTN). É essencial verificar se há sobreposições, atribuições ausentes ou configurações incorretas que possam causar erros de roteamento de chamadas ou interrupções no serviço.

Fluxos de chamadas PSTN e apresentação do identificador de chamadas

Um procedimento robusto de teste de aceitação deve abranger a validação de ponta a ponta dos fluxos de chamadas da PSTN. Isso inclui cenários de chamadas de entrada e saída. Para chamadas PSTN recebidas, a equipe de teste deve confirmar se as chamadas são entregues aos endpoints pretendidos, sejam eles usuários individuais, filas de chamadas, grupos de busca ou atendedores automáticos. As chamadas PSTN de saída devem ser feitas com sucesso, com especial atenção à entrega e apresentação corretas das informações de identificação de chamadas. Isso envolve garantir que o nome e o número corretos do chamador sejam exibidos para destinatários externos, de acordo com as políticas organizacionais e os requisitos normativos.

Os testes também devem abordar cenários de failover, como o tratamento de endpoints inacessíveis ou interrupções na rede. Isso ajuda a confirmar se os mecanismos de fallback e o roteamento alternativo estão funcionando adequadamente, mantendo a continuidade e a confiabilidade do serviço.

Fluxos de chamadas na rede

Os fluxos de chamadas internos ou na rede formam a espinha dorsal da comunicação corporativa . O teste de aceitação nessa área verifica se as chamadas entre usuários dentro da organização são roteadas corretamente, com recursos como transferência, espera, encaminhamento e conferência de chamadas operando conforme o esperado. A integridade dos planos de discagem, a conectividade de extensão a ramal e o suporte às políticas organizacionais de chamadas devem ser confirmados.

Tratamento de chamadas do usuário e validação de recursos

Um aspecto importante do teste de aceitação envolve a validação de como os usuários lidam com as chamadas usando os telefones de mesa compatíveis. Esse processo se concentra em confirmar que os fluxos de trabalho de chamadas do dia a dia são intuitivos e confiáveis e que os usuários têm acesso contínuo aos principais recursos necessários para suas funções. Os testes devem avaliar a facilidade com que os usuários podem fazer e receber chamadas, gerenciar funções de espera e retomada e realizar transferências cegas e consultivas. Também é essencial verificar se o encaminhamento de chamadas, a conferência e outros recursos avançados, como estacionar e recuperar chamadas ou ativar o recurso Não perturbe, estão prontamente disponíveis e funcionam sem problemas.

A experiência deve ser avaliada quanto à clareza e capacidade de resposta, considerando como os usuários interagem com o histórico de chamadas, o correio de voz e os diretórios integrados. Atenção adicional deve ser dada à capacidade de mover chamadas ativas entre dispositivos e usar controles de chamada de forma eficaz no aplicativo ou em telefones físicos. O objetivo final é garantir que a experiência do usuário final seja consistente, eficiente e atenda totalmente às necessidades de comunicação da organização após a migração.

Filas de chamadas: experiência de agente e supervisor

As filas de chamadas são frequentemente usadas para lidar com cenários de chamadas recebidas de alto volume. O teste de aceitação aqui se concentra em várias dimensões. Primeiro, deve-se verificar se as chamadas são distribuídas aos agentes de acordo com a lógica de fila configurada, como round robin, modo inativo mais longo ou anel simultâneo. A apresentação das chamadas em fila nos desktops dos agentes deve ser examinada para maior clareza e facilidade de uso, garantindo que os agentes possam aceitar, reter e transferir chamadas com eficiência.

Para os supervisores, a experiência de desktop deve ser avaliada em relação a recursos como monitoramento em tempo real, interferência de chamadas e análises ou insights sobre o desempenho da fila. Isso inclui, mas não se limita à validação de painéis e ferramentas de relatórios que fornecem dados acionáveis sobre distribuição de chamadas, atividade do agente e métricas de filas.

Grupos de caça: distribuição de chamadas

Os grupos de busca são um mecanismo fundamental para distribuir chamadas para conjuntos predefinidos de usuários. O teste de aceitação precisa confirmar se as chamadas são roteadas para os membros do grupo com base no algoritmo de busca configurado e se os cenários de estouro, encaminhamento e sem resposta são tratados de acordo com o design. Garantir que a associação ao grupo e os comportamentos de roteamento de chamadas correspondam aos previamente estabelecidos é essencial para a consistência operacional e a satisfação do usuário.

Atendedores automáticos: anúncios e operações de menu

Os atendedores automáticos representam a linha de frente do tratamento automatizado de chamadas. Os testes devem abranger a reprodução de anúncios, a precisão das saudações gravadas e a operação correta das árvores de menu. As seleções de menu devem encaminhar os chamadores de forma confiável para os departamentos, indivíduos ou números externos apropriados. Os testes também devem incluir cenários inválidos ou de tempo limite para confirmar que os chamadores recebem orientações claras ou são redirecionados conforme o esperado.

Operação de correio de voz

Finalmente, a funcionalidade do correio de voz é fundamental para a experiência do usuário. Os testes de aceitação devem verificar se as caixas de correio de voz estão corretamente atribuídas e acessíveis, tanto de dentro da organização quanto remotamente. A capacidade de gravar, recuperar e gerenciar mensagens deve ser confirmada, junto com a entrega da notificação.

A primeira etapa na transição para o é garantir uma conectividade confiável e segura com a Internet entre a rede local e a nuvem.

Como a maioria das organizações se conecta à Internet por meio de um ou mais firewalls ou dispositivos de segurança, é essencial validar se os fluxos de tráfego necessários são suportados.

Os administradores de rede e segurança devem entender esses fluxos em termos de:

• Direção (entrada versus saída)

• Protocolos (exemplo - SIP TLS, SRTP, HTTPS)

• Intervalos de endereços IP usados pelos serviços

• Números de porta que devem ser abertos ou permitidos.

Isso garante que firewalls corporativos, dispositivos NAT e outras infraestruturas de rede sejam configurados adequadamente para acomodar o tráfego e, ao mesmo tempo, manter as políticas de segurança da empresa.

Para obter informações sobre os fluxos necessários, incluindo endereço IP, portas e protocolos, consulte Informações de referência de portas para Webex Calling. Use essas informações para configurar o firewall, os proxies e outras infraestruturas de rede na implantação existente para ativar fluxos de rede.

O acesso descentralizado à Internet a partir de cada filial ou site é a abordagem recomendada para serviços de colaboração em nuvem, como. Ao permitir que o tráfego saia localmente, esse modelo:

• Reduz o atraso de ida e volta e a instabilidade, melhorando a qualidade geral das chamadas

• Dimensiona de forma eficiente à medida que mais usuários e sites fazem a transição para

• Funciona perfeitamente com a SD-WAN, que pode rotear sessões dinamicamente para o ponto de entrada de nuvem mais próximo para otimizar o desempenho

• Permite rastrear a localização do usuário com base em seu endereço IP público, o que ajuda na análise do caminho de mídia e na solução de problemas.

Além disso, as organizações devem garantir uma largura de banda de internet adequada em cada site. A largura de banda deve ser dimensionada com base no número esperado de chamadas simultâneas, no codec selecionado (por exemplo, Opus ou G.711), além da sobrecarga de sinalização, retransmissão e crescimento. Isso se alinha à fase de preparação do ciclo de vida do PPDIO e estabelece uma base sólida para a migração.

A subseção de configuração inicial na fase de implementação da implantação é fundamental para estabelecer um ambiente de chamadas na nuvem bem estruturado e gerenciável. Esse estágio engloba tarefas críticas, como configurar a organização, adquirir e atribuir licenças e verificar e reivindicar os domínios da sua empresa para garantir o gerenciamento e a segurança adequados dos usuários. Além disso, inclui o provisionamento de modelos de licença para automatizar as atribuições de licenças de usuários, configurar o Single Sign-On (SSO) para simplificar a autenticação do usuário e aprimorar a segurança e ajustar as configurações do serviço e do cliente para se alinharem às políticas organizacionais e às necessidades do usuário. A conclusão dessas atividades de configuração inicial garante que o ambiente seja configurado adequadamente para escalabilidade, segurança e experiência perfeita do usuário, preparando o cenário para as fases operacionais e de implantação subsequentes.

Durante a fase de implementação, a execução de uma migração piloto representa um marco crítico na validação da transição de para. Esse piloto envolve o provisionamento de um subconjunto representativo de usuários em um ou mais locais na plataforma, garantindo que a população selecionada reflita diversos casos de uso e funções organizacionais. Paralelamente à migração de usuários, os serviços essenciais de colaboração, incluindo correio de voz, atendedores automáticos, filas de chamadas e grupos de busca, devem ser transferidos para seus equivalentes para manter a continuidade dos negócios e a funcionalidade do serviço.

A migração piloto deve aproveitar a mesma combinação de ferramentas fornecidas pela Cisco e utilitários de migração de terceiros planejados para a implantação organizacional mais ampla, garantindo que os processos, fluxos de trabalho de automação e pontos de integração sejam totalmente validados sob condições representativas.

Os principais objetivos dessa implantação piloto são dois: primeiro, validar e refinar os processos de transição de ponta a ponta, incluindo fluxos de trabalho de provisionamento de usuários, procedimentos de migração de dados e configurações de terminais; e segundo, verificar de forma abrangente a funcionalidade dos serviços migrados em condições operacionais reais.

Essa abordagem em fases permite que a equipe do projeto identifique e corrija quaisquer problemas técnicos ou processuais em um ambiente controlado, colete feedback dos usuários sobre a nova experiência da plataforma, avalie a eficácia das ferramentas de migração selecionadas e estabeleça confiança na metodologia de migração antes de prosseguir com uma implantação organizacional mais ampla.

Os insights obtidos durante essa fase piloto são fundamentais para otimizar as ondas de migração subsequentes e garantir uma transição suave e com redução de riscos para toda a empresa.

Para adquirir serviços PSTN para, primeiro selecione uma opção de conectividade PSTN no.

Se uma organização planeja manter o controle híbrido de chamadas duplas (fase 1 na figura Transição de chamadas em fases: híbrida e nuvem) temporária ou indefinidamente, ela precisará implantar um ou mais gateways locais para PSTN local para permitir chamadas entre terminais e terminais.

Se uma transição completa (fase 2) para a nuvem for o objetivo final, incluindo a PSTN, será necessário um plano de chamadas da Cisco ou uma opção Cloud Connect for para a PSTN.

Trabalhe com o provedor escolhido para solicitar e transferir números de telefone antes de configurá-los. Solicitar números de telefone ou iniciar pedidos de portas só é necessário/possível para o PSTN local e o Cloud Connect for. Para os planos de chamadas da Cisco, o pedido e a portabilidade são iniciados no Control Hub assim que o local é criado e em países onde o Cisco Calling Plan está disponível. Para obter mais informações sobre os planos do Cisco Calling, consulte Introdução aos planos da Cisco.

Como parte da implementação da PSTN, certifique-se de que seu provedor tenha habilitado os serviços de PSTN de entrada e saída para sua localização. Além disso, realize chamadas de teste para verificar se as chamadas estão sendo roteadas corretamente por meio da conexão PSTN escolhida.

Antes de adicionar usuários e dispositivos, você deve provisionar locais de chamada. Para cada local, um endereço válido deve ser inserido. Nos EUA e no Canadá, esse endereço é validado e usado pela plataforma para enviar informações de localização do PIDF-LO para chamadas de emergência.

Ao configurar locais que usam PSTN local, você precisa configurar os gateways locais adequadamente. Em, um tronco e um grupo de rotas devem ser criados para cada gateway local, e o grupo de rotas é então atribuído como a escolha de PSTN para o local. A Cisco recomenda sempre selecionar um grupo de rotas como opção de PSTN, pois essa abordagem permite que você adicione facilmente troncos adicionais no futuro, suportando tanto a escalabilidade quanto a redundância. A Cisco também recomenda ativar o suporte de identidade dupla e P-Charge-Info em cada tronco PSTN, pois isso simplifica a identificação da parte cobrável para chamadas diretas ou desviadas de saída. Se seu provedor de PSTN usar um cabeçalho diferente para cobrança, você poderá copiar as informações do cabeçalho P-Charge-Info no gateway local para o cabeçalho de cobrança necessário.

Para locais que usam o Cloud Connect for ou o Cisco Calling Plan como opção de PSTN, basta selecionar a respectiva opção de PSTN para o local durante a configuração. Se o local usar o Cloud Connect for ou o PSTN local, você precisará adicionar os números de telefone que foram pedidos na etapa anterior. Os números podem ser adicionados como inativos se você não quiser que eles sejam incluídos imediatamente no roteamento de chamadas; você pode ativar esses números posteriormente, quando forem atribuídos a usuários ou recursos.

É importante sempre definir o número principal de cada local. O número principal pode ser atribuído a um usuário ou a um recurso, como um atendedor automático. Para ativar o correio de voz no local, certifique-se de definir o número piloto do correio de voz, também conhecido como número do portal de voz.

As configurações adicionais para locais de chamada incluem a configuração de detalhes de chamadas de emergência, como número de retorno de chamada de emergência, opções de notificação e recursos aprimorados de chamadas de emergência. Você também deve revisar e ajustar as configurações de gravação, as preferências de idioma e as configurações do dispositivo conforme necessário para cada local. Se sua organização usa discagem na rede abreviada entre sites com números corporativos significativos, lembre-se de configurar um código de site exclusivo para o local nas configurações de discagem interna. Finalmente, se a discagem externa exigir um dígito de discagem externa, certifique-se de defini-lo nas configurações de discagem externa. Quando um dígito de discagem externa é configurado, a Cisco recomenda ativar a imposição de dígitos de discagem externa para garantir a consistência.

Para se integrar ao controle de chamadas local, é necessário configurar troncos, grupos de rotas, planos de discagem corporativos e configurações globais e de localização. Comece configurando os troncos e os gateways locais destinados à interconexão com o sistema de controle de chamadas local; essa etapa só é necessária se forem necessários troncos dedicados. Se os troncos e grupos de rotas existentes forem suficientes para sua implantação, eles poderão ser reutilizados para a interconexão local sem configuração adicional.

Depois que os troncos e os grupos de rotas forem estabelecidos, continue criando os planos de discagem corporativos e atribua o grupo de rotas apropriado como destino para cada plano de discagem. Quando a integração envolve vários sistemas de controle de chamadas locais conectados por meio de diferentes troncos, vários planos de discagem serão necessários. É importante garantir que esses planos de discagem contenham somente os padrões necessários para rotear chamadas para destinos locais.

Se sua implantação exigir suporte para roteamento de extensões desconhecidas, esse recurso deverá ser ativado no nível do local. Além disso, quando o roteamento de ramais desconhecidos é ativado, você deve especificar o tamanho máximo do ramal desconhecido na seção Roteamento de chamadas entre e locais das configurações de serviços de chamada em. Isso garante o roteamento perfeito de chamadas e o tratamento adequado de cenários de discagem com base em ramais em seu ambiente integrado.

Ao migrar usuários de para, talvez você não consiga mover todos os usuários ao mesmo tempo. Isso pode ser devido a vários motivos, incluindo, mas não se limitando ao número de sites ou usuários, quanto tempo leva para fazer a transição de um site e/ou grupo de usuários ao mesmo tempo, recursos limitados de TI ou do site para dar suporte à janela de mudança, duração da janela de alteração, complexidade da mudança etc.

Quando você migra usuários em fases, é fundamental identificar quais usuários precisam migrar juntos no mesmo lote. O objetivo principal é migrar usuários que dependem uns dos outros em seus serviços e recursos de chamada. Você deseja garantir que todos os recursos de chamada (por exemplo, filas de chamadas) estejam totalmente funcionais como estavam antes da transição.

Mesmo que você implemente a interconexão de chamadas entre e com os gateways locais, não é possível dividir serviços ou recursos compartilhados nessa conexão. Portanto, você precisa identificar as dependências entre os usuários analisando recursos como:

• Monitorando outros usuários usando BLFs

• Na mesma caça, piloto, fila de chamadas, etc.

• Linhas compartilhadas

• Usando o atendimento de chamadas

• Usando os mesmos números do call park

• Intercomunicador

• Executivo/Administrador.

Um exemplo seria um usuário que faz parte de um Grupo de Busca para o qual está sendo transferido. Esse usuário fará a transição para o Grupo de Caçada e com todos os outros membros do Grupo de Caçada. Portanto, após a transição, o Hunt Group e seus membros podem atender chamadas com sucesso na nova plataforma.

Isso se torna mais desafiador quando os usuários estão conectados a diferentes grupos de usuários para diferentes serviços e recursos de chamada. Isso exigirá a transição de mais de um grupo de usuários e um serviço de chamadas ao mesmo tempo.

Use a saída da ferramenta Migration Insights ou da ferramenta de terceiros que você usou na fase de preparação para determinar quais usuários e recursos devem ser agrupados. Essa saída deve ter sido usada para desenvolver seu plano de migração e fornecerá informações sobre como você agrupará usuários e recursos que precisam fazer a transição juntos.

As principais etapas ao fazer a transição de um lote de usuários são:

• Identificação de usuários para migrarem juntos

• Verifique se todos os usuários estão conectados

• Verifique se todos os TNs dos usuários existem em

• Verifique o formato correto do número de telefone no diretório

• Certifique-se de que o licenciamento e o modelo de configurações para os grupos de usuários estejam configurados corretamente

• Verificar ou configurar todos os serviços e recursos de chamada para o grupo de usuários (antes ou durante a transição, conforme apropriado)

• No diretório corporativo, adicione usuários a um grupo de usuários habilitados para fazer chamadas.

• Ferramentas de alavancagem — ferramentas de migração de usuários e recursos e/ou ferramentas de terceiros

• Desative/exclua o número do diretório de usuário/dispositivo e os recursos/serviços de chamada após a transição.

Após a migração de um grupo de usuários, teste um subconjunto dos usuários para validar se todos os recursos e serviços de chamada estão funcionando corretamente. Se recursos de chamada, como fila de chamadas, grupos de busca etc. forem transferidos com o grupo de usuários, teste esses serviços de chamada para verificar a funcionalidade adequada .

Em, um espaço de trabalho se refere a um local compartilhado (como uma sala de conferência, espaço de reunião ou mesa ativa) ao qual podem ser atribuídos dispositivos, extensões e usuários. Ao contrário dos telefones Unified CM tradicionais, os espaços de trabalho são:

• Centrado na localização: vinculado a espaços físicos.

• Dispositivo flexível: pode ter um ou mais dispositivos (telefones de mesa, placas, etc.).

Depois que os espaços de trabalho forem identificados como parte da transição para, eles poderão ser adicionados em Dispositivos. Cada espaço de trabalho precisa ser atribuído a um dispositivo e, se já estiver instaladoUnified CM, precisará ser redefinido ou reprovisionado. recursos como correio de voz, encaminhamento de chamadas e atendimento de chamadas podem ser ativados ou desativados, e as políticas podem ser aplicadas para videochamadas, estacionamento de chamadas e mobilidade, conforme necessário. Teste cada espaço de trabalho fazendo chamadas internas e externas, testando recursos de vídeo, conferência e mobilidade . Por fim, informe os usuários sobre quaisquer processos aplicáveis aos dispositivos e reservas do espaço de trabalho.

Para obter mais informações sobre espaços de trabalho em, consulte Espaços de trabalho.

Os telefones atualmente registrados precisarão ser migrados como parte da transição para a nuvem. Para tornar a migração o mais simples possível com o mínimo de chance de falha, a Cisco recomenda migrar sites ou departamentos físicos ao mesmo tempo. No entanto, talvez seja necessário migrar usuários em lotes devido às dependências de recursos. Consulte a seção Migrar usuários em lotes para obter mais detalhes .

Todos os telefones compatíveis dos quais você precise fazer a transição precisarão ser configurados como usuário ou espaço de trabalho, e o telefone físico precisará ser reconfigurado para se registrar. Além disso, os telefones das séries 7800 e 8800 precisam que seu firmware seja atualizado do firmware corporativo para o firmware do telefone multiplataforma (MPP). Esse processo inclui carregar o firmware de transição antes de carregar o firmware MPP necessário para o registro. Também requer a licença de migração apropriada. A Cisco aprimorou esse processo nos últimos anos para facilitar a atualização de seus telefones com firmware corporativo para o firmware MPP. Para obter mais informações sobre as etapas para concluir a atualização do firmware, consulte Converter telefones IP das séries Cisco 7800 e 8800 entre o firmware Enterprise e MPP.

Além das etapas descritas neste artigo, tem uma ferramenta embutida, Migrate your phone toWebex Calling, que você pode usar para ajudar a migrar seus telefones 7800 e 8800 do firmware Enterprise para o MPP. Essa ferramenta também permite adicionar os telefones e atribuí-los aos usuários ou espaços de trabalho apropriados. Para obter mais informações sobre o uso da ferramenta, consulte Migrar seu telefone.

Para qualquer telefone da série 9800 registrado com o requisito de migração de firmware acima não se aplica. Esses telefones executam o PhoneOS, que é compatível com e. Para fazer a transição desses telefones para você, você precisará adicioná-losWebex Calling, atribuí-los a um usuário ou espaço de trabalho e, em seguida, redefinir os telefones para as configurações de fábrica. A sequência de inicialização do PhoneOS para registro, a figura abaixo mostra a sequência de inicialização do PhoneOS e como o telefone será registrado depois de adicionado, mesmo que o telefone ainda esteja provisionado e/ou as opções DHCP (exemplo - 150) estejam em uso.

suporta a redefinição de fábrica de dispositivos PhoneOS para permitir a integração Zero-Touch ao. os administradores podem redefinir remotamente as configurações de fábrica dos telefones 9800 e 8875 por meio das páginas de administração do CUCM, o que elimina a necessidade de acesso físico aos telefones para integrar os telefones. Esse recurso é compatível com os pacotes de dispositivos a partir de 9 de setembro de 2025:

• CUCM v15 - Versão 15 do Unified Communications Manager

• CUCM v14 - Versão 14 do Unified Communications Manager.

Para obter mais informações sobre o processo de registro da série 9800, consulte Processo de registro.

Além dos telefones IP Cisco, pode ser necessário o provisionamento de outros dispositivos, como adaptadores telefônicos analógicos (ATAs), telefones sem fio (Wi-Fi, DECT), dispositivos de vídeo, gateways de voz e dispositivos e telefones de ^terceiros. Muitos desses dispositivos não têm um caminho de atualização de firmware, como os telefones IP, para fazer a transição do firmware corporativo para o firmware na nuvem. Portanto, você provisionará cada um desses dispositivos no Control Hub. Alguns deles não podem ser transferidos e o modelo equivalente precisará substituí-los (por exemplo. ATA 191/192) e outros exigirão reconfiguração manual e/ou alterações de software.

• Gateways de voz - Para migrar seu gateway local, consulte Migrar gateway local.

  Para obter mais informações sobre como configurar seu gateway de voz VG400, VG410 ou VG420 no Control Hub, consulte Gateway local

• Adaptador de telefone analógico (ATA) - Para começar a usar o Cisco ATA 191 e 192, consulte Cisco ATA.

• Telefone sem fio Wi-Fi - Para integrar o telefone sem fio 840 e 860, consulte Integrar o telefone sem fio Webex .

• Telefones sem fio DECT - Para começar a usar sua nova série Cisco IP DECT 6800, consulte Cisco IP DECT.

  Para criar e gerenciar a rede DECT digital no Control Hub, consulte Gerenciar rede DECT

  Para obter mais informações sobre o Cisco IP DECT 6800, consulte o guia de implantação

• Dispositivos e telefones de ^{terceiros - trabalhe com fornecedores terceirizados sobre os requisitos de dispositivo/telefone e o processo para migrá-los ou substituí-los pelo suporte.}

Todos os recursos de chamada necessários precisam ser provisionados antes ou durante a transição. Conforme discutido na seção Migrar usuários em lotes, os recursos de chamada precisam ser configurados e transferidos quando os usuários que os estão usando são transferidos.

Para obter detalhes sobre como configurar cada um dos recursos, consulte os artigos de ajuda de configuração correspondentes.

• Atendedores automáticos - Para gerenciar atendedores automáticos, consulte Atendedores automáticos

• Parque de chamadas - Para gerenciar o parque de chamadas, consulte Parque de chamadas

• Captação de chamadas - Para configurar o grupo de coleta de chamadas, consulte Captação de chamadas

• Filas de chamadas - Para configurar a fila de chamadas, consulte Fila de chamadas

• Grupos de caça - Para gerenciar grupos de busca, consulte Gerenciar grupo de busca

• Modos operacionais - Para roteamento de chamadas com base nos modos operacionais, consulte Roteamento de chamadas com base nos modos operacionais

• Grupos de paginação - Para configurar um grupo de paginação, consulte Configurar um grupo de paginação

• Gravações - Para gerenciar a gravação de chamadas, consulte Gerenciar gravações

• Alcance de número único - Para configurar o alcance de um único número (escritório em qualquer lugar), consulte Configurar número único

• Grupo de correio de voz - Para gerenciar um correio de voz compartilhado e uma caixa de fax de entrada para, consulte Gerenciar correio de voz.

O teste de aceitação garante que o ambiente migrado atenda aos requisitos funcionais, opere conforme o esperado e ofereça uma experiência de usuário perfeita em todos os fluxos de trabalho de comunicação. Esse processo de validação é multifacetado, abrangendo tudo, desde o aprovisionamento de usuários e atribuições de números até o desempenho operacional de recursos avançados de chamada.

Esta seção fornece exemplos e destaca os principais aspectos a serem considerados durante o teste de aceitação; no entanto, não se destina a servir como uma lista de verificação exaustiva ou abrangente.

Provisionamento de usuários e atribuição de números

Um aspecto fundamental do teste de aceitação envolve verificar se todos os usuários estão provisionados de forma precisa e completa. Isso requer uma comparação completa entre o diretório source () e a base de usuários recém-estabelecida para garantir que todas as contas de usuário, juntamente com os atributos associados, como números de ramais e atribuições de discagem interna direta (DID), tenham sido migradas corretamente. A integridade do provisionamento é essencial não apenas para a operabilidade do primeiro dia, mas também para a administração e o suporte contínuos.

A validação da atribuição de números inclui a confirmação de que cada usuário recebeu o ramal e o número externo corretos e que esses números são roteados corretamente nos fluxos de chamadas internos (na rede) e externos (PSTN). É essencial verificar se há sobreposições, atribuições ausentes ou configurações incorretas que possam causar erros de roteamento de chamadas ou interrupções no serviço.

Fluxos de chamadas PSTN e apresentação do identificador de chamadas

Um procedimento robusto de teste de aceitação deve abranger a validação de ponta a ponta dos fluxos de chamadas da PSTN. Isso inclui cenários de chamadas de entrada e saída. Para chamadas PSTN recebidas, a equipe de teste deve confirmar se as chamadas são entregues aos endpoints pretendidos, sejam eles usuários individuais, filas de chamadas, grupos de busca ou atendedores automáticos. As chamadas PSTN de saída devem ser feitas com sucesso, com especial atenção à entrega e apresentação corretas das informações de identificação de chamadas. Isso envolve garantir que o nome e o número corretos do chamador sejam exibidos para destinatários externos, de acordo com as políticas organizacionais e os requisitos normativos.

Os testes também devem abordar cenários de failover, como o tratamento de endpoints inacessíveis ou interrupções na rede. Isso ajuda a confirmar se os mecanismos de fallback e o roteamento alternativo estão funcionando adequadamente, mantendo a continuidade e a confiabilidade do serviço.

Fluxos de chamadas na rede

Os fluxos de chamadas internos ou na rede formam a espinha dorsal da comunicação corporativa . O teste de aceitação nessa área verifica se as chamadas entre usuários dentro da organização são roteadas corretamente, com recursos como transferência, espera, encaminhamento e conferência de chamadas operando conforme o esperado. A integridade dos planos de discagem, a conectividade de extensão a ramal e o suporte às políticas organizacionais de chamadas devem ser confirmados.

Tratamento de chamadas do usuário e validação de recursos

Um aspecto importante do teste de aceitação envolve a validação de como os usuários lidam com as chamadas usando os telefones de mesa compatíveis. Esse processo se concentra em confirmar que os fluxos de trabalho de chamadas do dia a dia são intuitivos e confiáveis e que os usuários têm acesso contínuo aos principais recursos necessários para suas funções. Os testes devem avaliar a facilidade com que os usuários podem fazer e receber chamadas, gerenciar funções de espera e retomada e realizar transferências cegas e consultivas. Também é essencial verificar se o encaminhamento de chamadas, a conferência e outros recursos avançados, como estacionar e recuperar chamadas ou ativar o recurso Não perturbe, estão prontamente disponíveis e funcionam sem problemas.

A experiência deve ser avaliada quanto à clareza e capacidade de resposta, considerando como os usuários interagem com o histórico de chamadas, o correio de voz e os diretórios integrados. Atenção adicional deve ser dada à capacidade de mover chamadas ativas entre dispositivos e usar controles de chamada de forma eficaz no aplicativo ou em telefones físicos. O objetivo final é garantir que a experiência do usuário final seja consistente, eficiente e atenda totalmente às necessidades de comunicação da organização após a migração.

Filas de chamadas: experiência de agente e supervisor

As filas de chamadas são frequentemente usadas para lidar com cenários de chamadas recebidas de alto volume. O teste de aceitação aqui se concentra em várias dimensões. Primeiro, deve-se verificar se as chamadas são distribuídas aos agentes de acordo com a lógica de fila configurada, como round robin, modo inativo mais longo ou anel simultâneo. A apresentação das chamadas em fila nos desktops dos agentes deve ser examinada para maior clareza e facilidade de uso, garantindo que os agentes possam aceitar, reter e transferir chamadas com eficiência.

Para os supervisores, a experiência de desktop deve ser avaliada em relação a recursos como monitoramento em tempo real, interferência de chamadas e análises ou insights sobre o desempenho da fila. Isso inclui, mas não se limita à validação de painéis e ferramentas de relatórios que fornecem dados acionáveis sobre distribuição de chamadas, atividade do agente e métricas de filas.

Grupos de caça: distribuição de chamadas

Os grupos de busca são um mecanismo fundamental para distribuir chamadas para conjuntos predefinidos de usuários. O teste de aceitação precisa confirmar se as chamadas são roteadas para os membros do grupo com base no algoritmo de busca configurado e se os cenários de estouro, encaminhamento e sem resposta são tratados de acordo com o design. Garantir que a associação ao grupo e os comportamentos de roteamento de chamadas correspondam aos previamente estabelecidos é essencial para a consistência operacional e a satisfação do usuário.

Atendedores automáticos: anúncios e operações de menu

Os atendedores automáticos representam a linha de frente do tratamento automatizado de chamadas. Os testes devem abranger a reprodução de anúncios, a precisão das saudações gravadas e a operação correta das árvores de menu. As seleções de menu devem encaminhar os chamadores de forma confiável para os departamentos, indivíduos ou números externos apropriados. Os testes também devem incluir cenários inválidos ou de tempo limite para confirmar que os chamadores recebem orientações claras ou são redirecionados conforme o esperado.

Operação de correio de voz

Finalmente, a funcionalidade do correio de voz é fundamental para a experiência do usuário. Os testes de aceitação devem verificar se as caixas de correio de voz estão corretamente atribuídas e acessíveis, tanto de dentro da organização quanto remotamente. A capacidade de gravar, recuperar e gerenciar mensagens deve ser confirmada, junto com a entrega da notificação.