Migração de helpdesk sem downtime: dois sistemas em paralelo

Alguns times conseguem escolher um fim de semana tranquilo e trocar de helpdesk de uma vez só. Outros não: o suporte roda 24 horas por dia, o volume nunca dá trégua, ou o preço de uma segunda-feira caótica é simplesmente alto demais. Para esses times existe outro caminho — a operação em paralelo. Em vez de um evento de virada, a migração vira um botão de volume: dois helpdesks vivos ao mesmo tempo, o tráfego passando do antigo para o novo um canal por vez, e a ferramenta antiga desligada só quando os números disserem que é seguro.

Bem feito, o cliente não percebe nada e o agente nunca cai em um abismo. Feito no improviso, você colhe as duas falhas clássicas: o cliente atendido duas vezes por pessoas diferentes, ou atendido por ninguém, porque cada ferramenta achou que a outra estava cuidando do caso. A diferença entre um cenário e outro cabe em um punhado de regras.

O princípio: entrada nova no novo, drenagem no antigo

Uma única regra sustenta o padrão inteiro: as conversas novas nascem na ferramenta nova; as conversas em andamento terminam onde começaram.

Nada é movido no meio do fio. Um cliente que escreveu na terça pelo sistema antigo recebe a resposta de quinta pelo sistema antigo, de um agente que enxerga a troca inteira. Um cliente que escreve pela primeira vez depois da troca cai direto na caixa de entrada nova. Cada conversa tem exatamente uma casa, definida pelo lugar onde nasceu — o que significa que, em qualquer momento, os dois times e as duas ferramentas sabem sem ambiguidade quem é dono do quê.

O helpdesk antigo deixa de ser o seu sistema de atendimento e vira uma fila em drenagem: nenhuma entrada nova, um backlog que só encolhe e uma linha de chegada visível.

Troque um canal por vez

A operação em paralelo funciona justamente porque você nunca aposta todos os canais de uma vez. Uma ordem típica, do menor risco para o maior:

1. Chat no site. Um snippet trocado, reversível em segundos, e conversas de chat são curtas — drenar o que está em andamento leva horas, não semanas. É o seu ensaio geral com pouca coisa em jogo.
2. Um alias de e-mail secundário — o endereço de baixo volume, não o principal. Acompanhe uma semana inteira de tráfego ponta a ponta: roteamento, atribuição, escalonamentos, CSAT.
3. O e-mail principal do suporte. A essa altura o processo já está provado; a única variável nova é o volume.
4. Mensageiros e redes sociais — quase sempre dependem de passos de reconexão do lado da plataforma, então agende essa religação em vez de supor que ela é automática.

Dê a cada canal um período de decantação — alguns dias rodando na ferramenta nova enquanto você confere que nada vaza — antes de trocar o próximo. A escada inteira costuma levar de duas a quatro semanas. Ir mais devagar não é problema; pular degraus é o que empilha surpresas.

Dados consistentes entre duas ferramentas

A arquitetura tentadora é uma sincronização bidirecional ao vivo entre os dois sistemas. Resista. Sincronizar dois helpdesks nos dois sentidos é um encanamento frágil que quebra em silêncio, e ele existe para resolver um problema que a regra de roteamento já resolveu — ninguém precisa que as duas ferramentas guardem todas as conversas durante a sobreposição; o que se precisa é que cada conversa tenha uma casa agora e que a ferramenta nova tenha o registro completo no final.

O padrão que funciona é bem mais simples:

• Importação em massa antes de o período paralelo começar: histórico, contatos, base de conhecimento e macros chegam à ferramenta nova para que os agentes tenham contexto desde o primeiro dia.
• Uma importação delta no fim: quando a fila da ferramenta antiga tiver drenado, uma última passada recolhe tudo o que foi criado lá durante a sobreposição. O registro fica completo exatamente quando a ferramenta antiga se aposenta.
• Os contatos convergem pelo e-mail como chave de deduplicação, de modo que um cliente que aparece nas duas ferramentas durante a sobreposição vira um registro só, em vez de virar gêmeos.

Quem atende onde: escalar o time sem cérebro dividido

Divida o time por canal, não por senioridade: quem cuida do chat trabalha na ferramenta nova no dia em que o chat muda; a turma do e-mail atravessa quando o e-mail mudar. Cada agente troca de lado junto com uma mudança de roteamento, então ninguém opera duas filas ao mesmo tempo — e operar duas filas ao mesmo tempo é exatamente o que produz a resposta em duplicidade.

Duas regras de apoio:

• Os campeões atravessam primeiro. Os agentes que aprendem mais rápido pegam o primeiro canal e, quando o e-mail principal virar, a ferramenta nova já tem especialistas de casa em todos os turnos.
• A ferramenta antiga ganha uma data de desligamento no calendário, visível para todo mundo. Período paralelo sem prazo cria acampamento na fila — agentes que se demoram na ferramenta conhecida — e você acaba pagando por dois sistemas por pura inércia.

Métricas durante o período duplo

Números misturados mentem durante uma sobreposição: a fila da ferramenta antiga encolhe por desenho e a da nova cresce por desenho, então qualquer média combinada mede mais a mistura do que o atendimento. Em vez disso:

• Acompanhe tempo de primeira resposta e tempo de resolução por ferramenta e compare os números da ferramenta nova com a linha de base pré-migração da antiga — essa é a comparação honesta, de igual para igual.
• Vigie a curva do backlog da ferramenta antiga. Ela deve cair de forma monotônica; um platô significa que alguma entrada ainda está sendo roteada para lá, e achar esse vazamento é a tarefa mais importante do dia.
• Espere que os números da ferramenta nova comecem um pouco piores e cruzem a linha de base em uma ou duas semanas por canal, conforme os hábitos assentam.

Critérios de saída: quando desligar a ferramenta antiga

Escreva estes itens antes de o período paralelo começar, para que a decisão seja um checklist e não um debate:

• Todos os canais roteados para a ferramenta nova, cada um com seu período de decantação cumprido.
• Fila em andamento da ferramenta antiga drenada abaixo de um número combinado, com os retardatários explicitamente reatribuídos.
• Importação delta executada, com conferência por amostragem confirmando que o registro está completo.
• Métricas por canal da ferramenta nova iguais ou melhores que a linha de base pré-migração.
• Integrações, webhooks e automações verificados e apontando somente para a ferramenta nova.
• Aval do time — os líderes de turno concordam que nada mais depende do sistema antigo.

Depois disso: ferramenta antiga em somente leitura até o fim do ciclo de cobrança (seguro barato e referência honesta), cancelamento confirmado por escrito e a exportação do arquivo guardada em um lugar que é seu.

Os modos de falha contra os quais se projeta

• Respostas em duplicidade — sempre sintoma de um agente operando as duas filas ou de um canal roteado para as duas ferramentas. A regra de roteamento e a escala alinhada por canal previnem isso de forma estrutural.
• Aliases órfãos — aquele encaminhamento esquecido que continua alimentando a ferramenta antiga depois que "tudo" já mudou. O platô do backlog denuncia.
• Integrações escrevendo para o defunto — um webhook ou script ainda criando tickets no sistema antigo. Está nos critérios de saída por um bom motivo.
• A sobreposição eterna — pagar pelas duas ferramentas por seis meses porque ninguém assumiu a data final. Defina essa data no primeiro dia.

Onde o MoveDesk entra

O MoveDesk foi construído para o padrão paralelo: a migração assistida gratuita inclui tanto a importação em massa inicial quanto a passada delta final, os assentos ilimitados deixam o time inteiro viver nas duas ferramentas durante a sobreposição sem aritmética de licenças, e o teste de 14 dias cobre com folga os primeiros degraus da escada de canais. Se você quer enxergar como é o outro lado da sobreposição, a comparação com o Intercom mostra o caminho da migração em detalhes.

Escolha o seu primeiro canal — provavelmente o chat — e defina hoje a data de desligamento da ferramenta antiga. Uma migração paralela sem data final não é uma migração; é uma segunda assinatura.