Então você decidiu migrar de outro aplicativo para Intercom e quer manter seus dados históricos. E agora?
Visão geral do processo
Descrição das etapas
Planejamento - defina a abordagem que você adotará: quem será responsável pela migração, se conversas ou tickets serão criados no Intercom, como você criará contatos no Intercom, etc.
Configuração do Intercom - pelo menos o básico (atributos) deve ser configurado no Intercom para completar o exercício de mapeamento.
Mapeamento - um exercício para definir como entidades e atributos que existem na configuração do seu aplicativo atual serão mapeados para entidades e atributos na sua nova configuração do Intercom.
Exportação / Importação de Scripts (a versão mais técnica desta etapa) - crie o processo e os scripts para pegar e converter sua exportação do Zendesk para JSON ou chamar as APIs do Zendesk para recuperar dados de contato e ticket e chamar as APIs do Intercom para criar conversas / tickets.
Teste em lote (UAT: Teste de Aceitação do Usuário) - uma vez que você tenha completado a versão 1 dos scripts, execute um teste em lote em um subconjunto de tickets para fazer atualizações e iterar nos scripts.
Execução inicial - quando os scripts estiverem finalizados, você definirá a “Data Delta” como um ponto fixo no tempo para coletar apenas os tickets Fechados até essa data / hora. Esses tickets Fechados agora podem ser migrados para seu ambiente de Produção do Intercom pronto para lançamento, mas não ativo.
Transição e Deltas - quando estiver pronto para a transição do Zendesk, que incluiria encaminhar seus e-mails de Suporte para o Intercom e/ou lançar o Intercom Messenger para chat ao vivo, agora podemos migrar os tickets restantes que foram fechados desde a data / hora Delta, além de quaisquer tickets Abertos / Pendentes.
Planejamento
A primeira pergunta a se fazer é “por que eu preciso desses dados?” A resposta impactará a estrutura e o estilo da sua migração.
Se você precisa dos dados apenas para conformidade regulatória, pode considerar se quer esses dados em um banco de dados que possa consultar ou no Intercom.
Se você só precisa dos dados no Intercom para que seus novos relatórios do Intercom incluam dados históricos, é recomendado migrar os dados na forma mais simples (evitando migração mensagem por mensagem). O processo chave aqui é garantir que os valores dos atributos pós-migração sejam complementares aos seus novos processos para que o relatório seja consistente.
Se você precisa dos dados para fornecer o contexto das interações históricas de um usuário para resolver seus problemas hoje, ainda pode migrar os tickets na forma mais simples, mas isso justificaria mais a migração mensagem por mensagem. Lembre-se que isso aumentará o número total de chamadas API para o Intercom em 10 a 100 vezes.
Se for qualquer combinação das razões acima, é recomendado migrar para o Intercom!
Mapeamento
Agora que você confirmou por que está migrando seus dados, o próximo passo é se perguntar “Quais dados precisam ser migrados do meu sistema de origem e em que formato?”
Tenha em mente:
Cada ticket ou conversa precisa estar associada a um usuário ou lead existente (há um registro de contato para cada usuário final identificável).
Esses contatos serão criados como parte da migração ou importados antes?
Esses contatos precisam, no mínimo, de um user_id (do seu produto) ou endereço de e-mail.
Cada ticket / chat / etc. de origem será migrado como uma Conversa do Intercom ou um Ticket do Intercom?
Conversas vs. Tickets: qual você deve escolher?
Esta é uma das decisões mais importantes antes de começar a criar scripts. A escolha afeta quais endpoints da API você usa, como os dados são estruturados no Intercom e o que seus clientes e agentes verão.
Conversas — melhor se seus tickets do Zendesk eram principalmente interações de suporte ao cliente (e-mail ou chat). Conversas são visíveis no Intercom Messenger e suportam comunicação em tempo real. Use os endpoints Create conversation, Update conversation, Reply to conversation e Manage conversation.
Tickets — melhor se seus tickets do Zendesk eram solicitações estruturadas e rastreáveis (ex.: relatórios de bug, solicitações de recurso, tarefas administrativas) que não exigem um thread ao vivo para o cliente. Tickets têm estados definidos e atributos personalizados. Use os endpoints Create ticket, Update ticket e Reply to ticket.
Você pode migrar alguns dados históricos como Conversas e outros como Tickets — mas tente limitar o número de estruturas diferentes que você cria, pois isso adiciona complexidade aos seus scripts e validação de dados.
Se quiser manter dados históricos tanto em Tickets quanto em Conversas no Intercom (ex.: migrar tickets do Zendesk para conversas do Intercom mantendo registros de tickets), será necessário executar scripts de importação separados para cada estrutura. Planeje isso durante sua fase de Mapeamento antes de escrever qualquer script.
Para importar users do Zendesk, você pode:
Exportar users como arquivo CSV do Zendesk
Navegar até Contacts > People no Intercom e clicar em 'New Users or Leads', depois selecionar 'Import People'
Enviar seu arquivo CSV e mapear os atributos conforme necessário
Só porque algo era um ticket no Zendesk não significa que tem que ser um ticket no Intercom. Temos conversas temporais que podem ser chat ou e-mail, tickets voltados para o cliente e tickets administrativos — TODOS com métodos para se comunicar com os clientes.
Tente limitar o número de estruturas diferentes que você está criando, pois isso só adiciona complexidade.
Identifique quais atributos você migrará e para o que eles devem ser mapeados no Intercom (tickets e contatos).
Identifique e planeje quaisquer casos extremos potenciais.
Ao final desta fase, você terá uma tabela ou diagrama detalhando tudo que deseja migrar e qual será seu equivalente no Intercom!
Para evitar perfis duplicados:
Garanta que os IDs de user no Zendesk correspondam aos do Intercom
Defina os mapeamentos de atributos entre Zendesk e Intercom antes de iniciar a sincronização
Lembre-se que alterações nos IDs de user via CSV após a migração não são suportadas (use a API do Intercom em vez disso)
Criação de scripts
Agora é hora de revisar o plano com seu Implementation Engineer (IE).
Nota: Ordem das operações — ao migrar manualmente via API, você deve completar as etapas nesta sequência ou suas importações falharão:
Crie ou importe contatos primeiro. Toda conversa ou ticket deve estar vinculada a um contato existente. Contatos exigem no mínimo um user_id ou endereço de e-mail.
Crie atributos de dados personalizados (incluindo atributos de dados de conversa). Eles devem existir no Intercom antes de importar conversas, para que os valores dos atributos possam ser mapeados corretamente.
Importe conversas ou tickets. Eles só podem ser criados depois que os contatos que referenciam já existirem no Intercom.
Tentar criar conversas ou tickets antes que seus contatos associados existam resultará em erros.
Esta é uma oportunidade para ambos os lados revisarem o plano e fazerem quaisquer perguntas de esclarecimento antes de criar os scripts.
Seu script mudará dependendo se você está pré-importando o contato associado ou se está criando o contato (user ou lead) como parte do processo.
A estrutura geral para a criação de uma conversa ou ticket é:
Recupere os detalhes do ticket do Zendesk.
Ou pesquise e associe o solicitante ao user do Intercom ou crie o registro do user e atualize seus atributos.
Crie a conversa / ticket identificando o canal.
Você está criando a conversa simulando uma mensagem recebida do cliente (importante para visibilidade no Messenger).
Atualize os atributos da conversa / ticket, anexos e atribuição (equipe e colega de equipe)
Responda à conversa com uma mensagem enviada de volta ao cliente ou adicionando uma nota
Use esta resposta para postar a transcrição COMPLETA da conversa (corpo) do Zendesk em vez da abordagem mensagem por mensagem.
Se você estiver respondendo ao cliente e criou uma conversa no canal de email, essas notificações serão enviadas ao cliente, a menos que você não esteja ativo no workspace ou esteja suprimindo todas as notificações por email (podemos ajudar com isso).
Gerencie o estado da conversa / ticket
Todos os tickets fechados passarão primeiro pelo processo de serem abertos, atualizados e respondidos antes de serem fechados por esta chamada. É importante garantir que todos os workflows que atuariam sobre as conversas tenham uma exceção nas regras de gatilho para “Created via API” ou estejam temporariamente desativados durante a migração.
Teste em lote
Neste ponto, você deve ter uma versão funcional do script de migração configurada e pode começar a testar migrando um subconjunto de dados de amostra para seu workspace de TESTE.
Verifique minuciosamente os resultados desses testes e colabore com seu IE para fazer ajustes conforme necessário.
Se você comprou um pacote de migração dos Serviços de Implementação ao Cliente da Intercom e estamos fazendo isso em seu nome - só pediremos que você valide os resultados e faremos as atualizações necessárias!
Corte
Como você planeja abordar a migração de tickets abertos no Zendesk impactará como você planeja o cronograma para seu corte.
Drain and Fill:
Nesta abordagem, você faria o corte para o Intercom antes da sua data oficial de lançamento para que todas as novas solicitações de suporte entrem no Intercom. Sua equipe de suporte trabalharia em ambas as plataformas até que todos os tickets abertos restantes no Zendesk sejam fechados.
Após fechar todos os tickets restantes do Zendesk, você executaria seu lote final de migração. Na prática, essa abordagem não migra tickets abertos, mas espera que todos os tickets sejam fechados no Zendesk antes de movê-los.
Corte ao vivo:
Nesta abordagem, suas equipes sincronizariam o corte para o Intercom para coincidir com quando você executaria a migração final contendo apenas tickets abertos.
Essa abordagem requer uma coordenação muito maior do que drain and fill, pois tudo precisará ser redirecionado para o Intercom enquanto os tickets abertos estão sendo migrados.
Endpoints relevantes da API do Zendesk (para recuperação)
Endpoints relevantes da API do Intercom (para criação)
Migração
O plano está concreto, o script de migração está finalizado e ajustado, agora é hora de transferir seus dados!
Tenha em mente:
É importante criar um "Run Book" (e "Roll Back Plan") dos passos para a Primeira Execução da Migração (todos os tickets fechados até uma certa data e hora) e o Corte Formal + Execução da Migração Delta.
Certifique-se de ter pensado em um plano para quais componentes dos tickets migrados devem ser visíveis para eles (e onde), além de quaisquer notificações que eles devem receber. Normalmente, nossos clientes querem o mínimo de impacto ou visibilidade para seus clientes durante a migração, mas uma experiência aprimorada após a migração.
Após completar a migração, realize verificações minuciosas:
Verifique se os perfis dos users estão corretamente mapeados
Verifique se o histórico de conversas e tickets foi transferido corretamente
Confirme se os detalhes da organização estão representados com precisão
Use exportações CSV ou a interface administrativa do Intercom para validação
Após a migração, valide seus dados de ticket e pronto! 🎉
