Como migrar para CCaaS sem derrubar chamadas: um plano de 7 etapas para 2026

Resumo

Para migrar para CCaaS sem derrubar chamadas, primeiro encaminhe seus números antigos para novos números na plataforma em nuvem e deixe a portabilidade por último. Tudo antes da portabilidade pode ser desfeito com uma mudança de configuração. Uma portabilidade concluída não pode, e uma portabilidade nos EUA leva 2 to 4 weeks quando a documentação está correta. Então faça o inventário, reconstrua, teste em números de reserva e faça um piloto com uma fila enquanto o sistema antigo ainda recebe a maioria das chamadas.

A maioria dos planos ignora o lado do suporte: o helpdesk não muda de lugar, mas suas conexões com a telefonia mudam. O colega de equipe de IA para helpdesk da eesel trabalha dentro do helpdesk, então continua respondendo aos tickets durante a transição.

Para quem é este guia (e do que você precisa primeiro)

Este guia é para líderes de suporte ou operações que estão tirando uma linha telefônica de atendimento ao cliente de um PBX local ou de uma estrutura mais antiga de tecnologia de call center e levando-a para a nuvem (CCaaS, central de contato como serviço): Amazon Connect, Genesys Cloud, Talkdesk, Five9, Zendesk Talk, Aircall, Twilio Flex e outras. Se você ainda está escolhendo uma plataforma, minha seleção de softwares de call center apresenta as principais opções. Se você usa Freshdesk, o Freshdesk Contact Center integrado é outra opção, e o Dialpad e as alternativas ao Aircall cobrem as opções mais leves. Este post é sobre a migração em si.

Sou engenheiro na eesel e passo a maior parte da semana trabalhando com integrações, o que significa bastante tempo nas APIs de helpdesk e telefonia de outras empresas. O padrão que vejo é consistente: a telefonia ganha um plano de projeto, e as conexões do sistema telefônico com o helpdesk ganham um item chamado "integrações". É nessas conexões que uma transição dá errado sem ninguém perceber.

Se você também usa um agente de IA, a eesel CLI oferece aos seus engenheiros uma via alternativa controlável por scripts durante a migração: um agente de programação com IA como o Claude Code pode carregar conhecimento aprovado (artigos de ajuda exportados, macros, os novos roteiros da URA) e depois fazer perguntas de teste ao agente para verificar suas respostas antes de qualquer coisa entrar em produção. Conectar o helpdesk em si ainda exige que uma pessoa com acesso de administrador aprove a conexão.

Tenha estes itens prontos antes da etapa 1:

• Uma cópia da conta telefônica ou do Customer Service Record (CSR) de cada operadora. A documentação de portabilidade precisa corresponder exatamente a esse documento.
• Um responsável pela conta na operadora que possa assinar. A AWS pede uma assinatura de próprio punho na LOA (carta de autorização) e diz que a maioria das operadoras rejeita assinaturas eletrônicas.
• Acesso de administrador ao seu helpdesk e CRM, porque você vai reconectá-los.
• Seus relatórios de chamadas dos últimos 90 dias (volume por hora, taxa de abandono, tempo de atendimento) como referência para comparar a nova plataforma.

Por que tantas centrais de contato estão migrando agora?

Para muitas equipes, a migração não é opcional. Os grandes produtos de central de contato locais estão chegando ao fim do suporte dos fornecedores, e a rede telefônica de cobre do Reino Unido está sendo desligada. Aqui estão as datas das próprias páginas dos fornecedores e órgãos reguladores:

Se um prazo como esse é o que está impulsionando você, planeje de trás para frente a partir dele e comece cedo a parte da operadora. A AWS diz que exige que as solicitações de portabilidade sejam abertas "several months before pending go-live dates" porque as operadoras bloqueiam portabilidades em feriados e durante manutenções.

Qual é a única etapa que você não pode desfazer?

A portabilidade dos números. Todas as outras etapas de uma migração para CCaaS são configurações que você pode reverter. A portabilidade transfere o número para uma nova operadora, e a AWS deixa claro que, após a conclusão, "the gaining carrier has sole control of the phone number." Transferi-lo de volta exige uma nova LOA, novos documentos e uma nova portabilidade.

Isso muda a ordem em que você deve organizar o trabalho. A pergunta não é "em que data fazemos a transição?". É "por quanto tempo podemos operar os dois sistemas antes de dar o passo sem volta?". Tanto a AWS quanto a Salesforce dão a mesma resposta para ganhar esse tempo: encaminhe primeiro.

O checklist do Voice da Salesforce alerta que a portabilidade "is highly regulated, can't be rushed," e recomenda três ações: obter um novo número para testes e produção, encaminhar o tráfego do número original para ele até concluir os testes e, depois, fazer a portabilidade do original. O guia de migração da AWS descreve a mesma etapa de encaminhamento como uma forma de oferecer "rapid rollback (which depends on a relatively simple change to call forwarding rules) without any dependencies on a carrier."

O encaminhamento não é gratuito, então não o deixe ativo por meses. A AWS destaca que, enquanto ele está ativo, você paga pela chamada recebida no número antigo, pelo encaminhamento de saída e pela chamada recebida no número novo, e cada chamada ocupa um circuito de saída. Eu trato o encaminhamento como algumas semanas de seguro, não como uma configuração permanente.

Etapa 1: Faça um inventário do que o sistema antigo faz

A maioria das surpresas na migração vem de algo que o sistema antigo fazia e que ninguém documentou. É a mesma lição que as equipes aprendem quando trocam de helpdesk. Antes de projetar qualquer coisa, liste tudo:

Dois itens merecem cuidado extra. O primeiro é o SMS. A Genesys alerta que o SMS de um número portado "will not be automatically transferred along with voice service. In fact, the SMS services will likely be disrupted." Se você envia mensagens de pedidos ou lembretes de agendamento a partir de um número de suporte, sinalize isso agora. O segundo é qualquer etapa da URA que acesse um sistema interno, como "digite o número da sua conta" consultando um banco de dados. Essa lógica precisa ser reconstruída na nova plataforma, e é fácil deixá-la passar porque está dentro de um fluxo que ninguém abre há anos.

Etapa 2: Projete a nova estrutura (reconstrua, não copie)

Fluxos de chamadas não são transferidos entre plataformas. Um consultor de Amazon Connect explicou isso de forma direta no Hacker News:

"when someone designs a call center with Amazon Connect, they use a GUI flowchart tool and create "contact flows". You can export the flow to JSON. But it isn't portable to other environments without some remapping."

raw_anon_1111, Hacker News

Como você vai reconstruir de qualquer forma, simplifique. As próprias orientações da AWS dizem "don't limit yourself" a simplesmente transferir o call center antigo como está, e a Salesforce recomenda começar pelos fluxos de contato padrão e evoluir a partir deles. Uma URA de sete níveis que fazia sentido em 2014 geralmente se resume a três opções e um retorno de chamada. Se você usa Zendesk, meu guia da URA do Zendesk Talk mostra uma árvore telefônica enxuta.

Parte do que a URA antiga fazia agora é trabalho para uma recepcionista telefônica com IA, que pode responder a perguntas simples antes mesmo de a pessoa que liga chegar a uma fila.

Duas decisões de projeto para tomar nesta etapa:

1. Como o antigo e o novo vão coexistir. Os agentes geralmente migram em grupos, e a AWS observa que a fase de migração "might take several months," com equipes em plataformas diferentes transferindo chamadas entre si. A AWS sugere números dedicados para transferência entre as plataformas para que você possa medir separadamente as transferências entre plataformas.
2. O que acontece com as gravações antigas. A AWS oferece duas opções: migrar gravações e relatórios (verifique primeiro o formato de áudio) ou arquivá-los onde estão até o fim do período mínimo de retenção. Arquivar costuma ser mais barato, mas alguém precisa ficar responsável pelo acesso ao arquivo antigo.

Espere que a nova plataforma exija conhecimentos reais de administração. Se você também está saindo do Zendesk, meu guia de migração do Zendesk cobre a parte dos tickets. Um engenheiro sênior de telefonia que avaliou o Genesys Cloud CX no G2 escreveu:

"Genesys Cloud CX is extremely capable, but that capability comes with complexity. There are many situations where something that appears relatively straightforward ends up requiring Architect customization, Data Actions, APIs, or external automation."

Justin H., engenheiro sênior de telefonia, avaliação no G2

Essa é uma avaliação justa da maioria das plataformas corporativas de CCaaS, incluindo a Genesys. Reserve tempo de engenharia para a reconstrução e evite ficar sem saída: as armadilhas da dependência de fornecedor que se aplicam às ferramentas de IA também se aplicam às plataformas de telefonia.

Etapa 3: Refaça as conexões do lado do helpdesk

Esta é a etapa que a maioria dos planos resume a uma única linha, e é nela que eu gastaria mais tempo do que você imagina. O sistema telefônico muda. Seu helpdesk, central de ajuda, macros, CRM e agente de IA ficam onde estão. A telefonia muda; as conexões entre a telefonia e o helpdesk precisam ser reconstruídas. Cada uma delas precisa ser testada novamente.

Verifique três conexões em particular:

• Registro de chamadas em tickets. Toda chamada cria ou atualiza um ticket no helpdesk, com a gravação e a pessoa que ligou vinculadas? Se você está migrando para uma ferramenta de telefonia que se conecta ao seu helpdesk, como CloudTalk e Zendesk, teste como o ticket fica em uma chamada real.
• Abertura automática do registro de quem liga. Quando o telefone toca, o agente vê o registro do cliente? Isso costuma depender de o formato do identificador de chamada corresponder ao do CRM, e esse formato muda entre operadoras.
• Relatórios. O tempo de atendimento e a taxa de abandono são calculados de forma diferente em cada plataforma. Uma pessoa que avaliou o Genesys Cloud no G2 considerou os relatórios personalizados "difficult to navigate." Combine as novas definições com a liderança antes da entrada em produção, ou seu primeiro relatório mensal vai parecer um desastre que, na verdade, não aconteceu.

Depois, verifique o que a automação do seu helpdesk faz com tickets de chamadas. É um detalhe que passa despercebido: configurações de IA bem administradas costumam ignorar tickets telefônicos de propósito. A Lesson Pro, um grupo de marcas de aulas que opera duas contas Zendesk, usa a eesel para deixar notas e rascunhos em 1,900 tickets por mês, mas deixa as mensagens de voz de fora. A Luxedo, no Gorgias, configura seu agente para ignorar tickets de chamadas telefônicas, spam e pesquisas, para não gastar nada com eles. Se sua nova plataforma de telefonia nomeia ou marca os tickets de chamadas de forma diferente da antiga, essas regras param de funcionar sem aviso e, de repente, a IA está redigindo respostas para transcrições de mensagens de voz. Verifique os gatilhos, as visualizações e as automações que filtram tickets de chamadas.

O lado positivo é que o suporte por e-mail e chat não depende em nada da plataforma de telefonia. Um agente de IA que trabalha dentro do helpdesk continua funcionando durante toda a migração. A smava, uma empresa alemã de comparação de empréstimos, usa a eesel em um único Zendesk para duas marcas: 27,000 tickets tratados em um mês, 14,600 categorizados e 15,300 rascunhos de respostas preparados. Uma fila como essa não se importa com qual operadora a telefonia usa.

A SamCart é um caso semelhante no Freshdesk: um agente trabalha nos tickets do Freshdesk e outro cuida do chat do site, então o suporte por escrito tem seus próprios caminhos.

Etapa 4: Teste em números de reserva

Monte a nova estrutura em números temporários e teste antes que qualquer chamada de cliente passe por ela. O checklist de entrada em produção da AWS exige que cada linha de atendimento dentro do escopo tenha "successfully run UAT scripts" usando um número telefônico temporário.

Escreva seu roteiro de testes pensando primeiro nas falhas e depois no cenário ideal:

Verifique também seus limites de capacidade antes de testar em escala. A AWS diz que novas instâncias podem começar com cotas tão baixas quanto "10 concurrent calls or 5 phone numbers", então solicite aumentos com antecedência. E teste nas configurações reais dos agentes: a AWS recomenda headsets USB com fio em vez de Bluetooth e conexão Ethernet cabeada, e sugere prever orçamento para adaptadores antes de a migração começar.

Etapa 5: Faça um piloto com uma fila usando encaminhamento

Escolha uma fila de baixo risco (dúvidas gerais, uma linha interna de TI, uma região pequena; meu post sobre call center versus central de serviços explica por que linhas de TI se comportam de forma diferente) e encaminhe seu número para a nova plataforma. Mantenha as linhas de alto volume e maior criticidade, como cobrança, no sistema antigo até que o piloto funcione sem problemas.

Defina seus critérios de reversão antes de começar, em números. O checklist de entrada em produção da AWS orienta você a acompanhar chamadas atendidas, taxa de abandono, tempo médio de atendimento e tamanho da fila em tempo real, e a manter uma conferência telefônica aberta "until go-live (or rollback) activities have been completed." Eu escreveria algo como "se a taxa de abandono ficar acima do dobro da referência dos últimos 90 dias por uma hora, revertemos o encaminhamento" e definiria quem tem autoridade para tomar essa decisão.

Depois, migre o restante das filas em grupos. A AWS diz que o período com duas plataformas é caro e que, quanto mais ele dura, maior é "the risk of human errors such as making changes on the wrong platform." Avance de forma constante, não devagar.

Etapa 6: Faça a portabilidade dos números

Depois que todas as filas tiverem funcionado sem problemas com números encaminhados, faça a portabilidade dos originais. Veja o que as principais plataformas dizem sobre os prazos:

O prazo legal é mais rápido do que qualquer um desses. Nos EUA, a FCC exige uma portabilidade simples em até um dia útil e uma não simples em até quatro dias úteis. Mas um bloco de números de uma central de contato em um tronco raramente é "simples", e as semanas da tabela correspondem à documentação, validação e agendamento em torno da mudança efetiva.

É na documentação que as portabilidades dão errado. A AWS lista os quatro motivos comuns de rejeição: um saldo pendente ou uma taxa de saída por portabilidade, um nome ou endereço que não corresponde ao CSR, um número que não pode ser portado e informações ausentes, como uma assinatura. Uma LOA rejeitada "resets the porting timelines." A AWS também exige que a LOA tenha sido datada nos últimos 15 dias, então não a assine com um mês de antecedência.

Mais duas regras que pegam as pessoas de surpresa:

1. Não cancele a operadora antiga antes da hora. A FCC recomenda iniciar a portabilidade com o novo provedor antes de encerrar o serviço antigo, e a Aircall alerta que números de uma conta cancelada podem ser perdidos permanentemente.
2. Conheça seu prazo de cancelamento. A AWS precisa de 5 dias úteis de antecedência para cancelar ou reagendar, e, quando o número chega à nova RespOrg, "the port is complete."

No próprio dia da portabilidade, a AWS alerta que ela "can be disruptive" porque as rotas são atualizadas entre operadoras, incluindo as que não estão envolvidas, e "in rare cases it can take several hours" para estabilizar. Faça a portabilidade em uma manhã tranquila de um dia útil, mantenha agentes conectados nos dois sistemas, acompanhe a queda do tráfego na plataforma antiga e faça chamadas de teste para todos os fluxos.

Etapa 7: Estabilize e depois desligue o sistema antigo

Não desative o PBX antigo no dia seguinte à portabilidade. Mantenha-o funcionando durante um ciclo completo de faturamento e pelo menos um período de pico, para poder comparar relatórios (e seus números de ROI do call center) e recuperar gravações antigas se surgir uma contestação. Avise o financeiro de que haverá sobreposição de custos: a AWS observa que seu próprio faturamento sobe e os custos do sistema legado caem somente depois que a nova central de contato entra em produção.

A AWS também aponta uma lacuna não técnica: "user training, process changes, and service desk changes are often overlooked until the project is close to completion." Antes de desligar o sistema antigo, garanta que sua equipe interna de TI ou central de serviços saiba quem é responsável pela nova plataforma e como abrir um incidente relacionado a ela. A AWS sugere abrir um incidente de teste e acompanhá-lo até o fim.

E quanto ao 911 e aos agentes remotos?

Isso é uma exigência legal nos EUA, não algo apenas desejável. Pela Kari's Law, qualquer sistema telefônico multilinha instalado após 16 de fevereiro de 2020, o que inclui sua nova estrutura em nuvem, deve permitir que os usuários disquem 911 diretamente, sem um prefixo como "9", e deve enviar uma notificação (com um número para retorno e a localização) a alguém que provavelmente a veja.

As regras de localização são mais rígidas para agentes que trabalham de casa. Segundo o 47 CFR 9.16, dispositivos usados fora das instalações devem fornecer automaticamente uma localização que permita o envio de socorro (um endereço físico validado) quando isso for tecnicamente viável, ou então uma localização que o usuário atualize manualmente. Na prática, minha interpretação é: colete o endereço de cada agente em home office, ofereça uma forma simples de atualizá-lo quando se mudar e teste o fluxo de uma chamada para o 911 usando o procedimento de teste do serviço de emergência local. Pergunte ao seu fornecedor de CCaaS como o softphone dele lida com isso antes da entrada em produção, não depois.

Checklist de prontidão para a transição

Marque cada item conforme for concluído. Se você não conseguir marcar todos, ainda não é o dia da portabilidade.

Quanto tempo leva uma migração para CCaaS?

Para uma equipe em um único país com uma operadora, dois a três meses é um planejamento realista: algumas semanas de inventário e projeto, algumas semanas de reconstrução e testes, um piloto e, depois, as 2 to 4 weeks de documentação da portabilidade acontecendo em paralelo. Vários países estendem esse prazo, já que a AWS informa de dois a seis meses para portabilidades fora dos EUA e do Canadá, e trata mais de 10 faixas de números ou 10 locais como "a project" que exige o envolvimento de sua equipe de contas.

O lado do helpdesk pode avançar muito mais rápido, e esse é o objetivo de mantê-lo separado. Um agente de IA que trabalha dentro do helpdesk não espera pela telefonia. A Luxedo conectou a eesel ao Gorgias em julho, construiu seu conhecimento e suas instruções em agosto e ativou o gatilho na última semana de agosto, tudo no Gorgias. Meu cronograma de implantação de suporte com IA explica por que a maioria das equipes fica entre duas e oito semanas.

Experimente a eesel enquanto sua telefonia está migrando

Uma migração para CCaaS representa alguns meses estressantes para uma equipe de suporte: os agentes estão aprendendo a usar um novo softphone, a fila piloto está oscilando e a liderança quer saber por que os relatórios mudaram. Não é uma boa hora para a fila de e-mail e chat também acumular. O colega de equipe de IA para helpdesk da eesel se integra ao seu helpdesk atual (Zendesk, Freshdesk, Gorgias e outros), aprende com sua central de ajuda, macros e tickets anteriores (a mesma base de conhecimento que seus agentes de telefonia usam) e prepara rascunhos ou envia respostas, para que a fila de atendimento por escrito fique tranquila enquanto a telefonia migra. Você pode simular seu desempenho em tickets anteriores antes que ele responda a alguém, e os planos começam em $299 por mês para 500 tickets na página de preços.

Experimente a eesel gratuitamente com 100 créditos, ou agende uma demonstração se quiser ajuda para planejar a implantação em torno da sua transição.