Resposta direta
Na maior parte dos casos, o histórico não se perde na migração: ele nunca esteve registrado em lugar recuperável. Antes de atribuir a falha à ferramenta nova, é preciso separar três conjuntos: o que existia no sistema antigo, o que existia fora dele, em e-mail, planilha ou telefone, e o que só existia na memória de quem atendia. O diagnóstico começa pelo inventário do que era campo obrigatório, do que era texto livre e do que nunca teve dono. Sem essa separação, a importação copia volume e deixa a parte útil para trás. A decisão sobre manter ou descartar o acesso antigo vem depois do inventário, não antes.
- Objetivo
- Diagnosticar
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata a janela de acesso ao sistema antigo como prazo de diagnóstico e separa perda de dado de ausência de registro, recorte que as outras páginas do tema não fazem.
O que costuma faltar quando a exportação abre
Toda troca de ferramenta expõe a diferença entre o que o sistema antigo guardava e o que o atendimento de fato registrava. Ao abrir a exportação, aparece com frequência o mesmo quadro: campo obrigatório preenchido com opção genérica, resumo de uma linha, anexo apontando para caminho que não existe mais. Isso não é falha de migração. É o retrato de como o registro era feito.
Vale listar, antes de qualquer importação, o que era campo estruturado, o que era texto livre e o que vivia fora do sistema: caixa de e-mail individual, planilha de controle, bloco de notas da equipe, registro do telefone. Cada origem tem taxa diferente de recuperação e responsável diferente pela guarda. Tratar todas como uma só massa de dados é o que produz a sensação de perda total.
A conta que separa perda de ausência de registro
O diagnóstico fica objetivo quando se mede a cobertura recuperável por origem. Não se trata de estimar quanto se perdeu, mas de saber quanto do que existiu pode ser lido, atribuído a um cliente e datado. Registro sem vínculo com cliente, ou sem data, ocupa espaço e não serve para atendimento.
A conta deve ser feita por período e por canal, com o mesmo critério em todas as origens. O resultado não é meta: é linha de base para decidir o que migra, o que fica em arquivo consultável e o que será descartado. A decisão precisa de dono nomeado, porque a janela de acesso ao sistema antigo costuma fechar antes do fim da conferência.
O que o diagnóstico não resolve
O diagnóstico não recupera o que nunca foi registrado nem reconstitui conversa que só existia na memória de quem atendia. Também não resolve obrigação de guarda definida em contrato ou por regulação: nesses casos, o prazo e o formato vêm de fora e precisam ser verificados antes de qualquer descarte.
Ele não substitui a correção da rotina de registro. Se a operação continua aceitando campo genérico e resumo vago, o mesmo problema reaparece na próxima troca, com o mesmo formato. E não garante disponibilidade da base antiga: acesso, backup e permissão de exportação são condições prévias do trabalho, não etapas dele.
Recurso prático
Cobertura recuperável do histórico por origem
IRH = ((RE + AL) ÷ TI) × 100
- RE
- interações
- interações do período com registro estruturado, vinculadas a um cliente identificável e com data
- AL
- interações
- interações sem registro estruturado, mas com anexo, transcrição ou e-mail localizável no sistema antigo
- TI
- interações
- total de interações do mesmo período, contado na origem e não no que foi entregue pela exportação
- canal
- categoria
- origem contabilizada em separado, para que um canal com bom registro não esconda outro sem registro
O erro mais comum é calcular sobre o que a exportação entregou. A base exportada já exclui o que ficou em caixa de e-mail, planilha de controle ou telefone, e o índice sai alto justamente onde o histórico é mais frágil. O denominador precisa vir da contagem de interações na origem, feita antes de qualquer importação.
Sobre o que está escrito aqui
Conceitos relacionados: histórico de atendimento · exportação de base · campo estruturado · texto livre · janela de acesso ao sistema antigo. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Atendimento, relacionamento e retenção — Página central do tema
- Atendimento fragmentado: métricas para enxerg… — canais fragmentados
- Canais fragmentados: qual modelo de consolida… — canais fragmentados
Páginas relacionadas
O mesmo problema em outro objetivo
- Troca de ferramenta: o que fazer com o histórico perdido — Organizar um processo
- Histórico perdido na troca de ferramenta: o que comparar — Comparar alternativas
- Histórico perdido na troca de sistema: o que comparar e medir — Explicar medição
- Histórico antigo na troca de ferramenta: o que migrar — Orientar implementação
- Histórico perdido na troca de ferramenta: o que contratar — Orientar avaliação e contratação
Outras leituras em Atendimento, relacionamento e retenção
- Atendimento sem campo de resumo: o que vai no lugar — Comparação entre registrar atendimento por texto livre, campos estruturados e marcadores de desfecho, com critério de escolha e limites de cada opção.
- Chamado repassado sem contexto: onde o dado se perde — Mapeamento dos pontos de perda de dados entre etapas de atendimento, critérios de diagnóstico operacional e os limites da padronização.
- Por que o cliente precisa repetir informações a cada contato — Quatro pontos onde o contexto se perde entre canais, como localizar o principal e o que registrar para reduzir repetição.
- Protocolo sem numeração única: onde o vínculo se perde — Mostra onde o vínculo entre contatos se rompe quando cada canal cria seu próprio número, o que medir antes de padronizar e o que a numeração única não resolve.
- Pedido simples que exige escalonamento: onde investigar — Como investigar por que pedidos simples exigem escalonamento, separando regra ausente, permissão de acesso e falta de contexto antes de mudar o fluxo.