Histórico de tickets e retenção: o que levar ao trocar de helpdesk

Toda migração de helpdesk obriga o time a encarar uma pergunta que ele vinha adiando havia anos: para que serve, afinal, todo esse histórico? Dez anos de tickets parecem um patrimônio — até o dia em que você precisa movê-los. Aí eles viram conta a pagar, medida em horas de exportação, tempo de importação, armazenamento e ruído na busca. A resposta honesta é que o histórico de tickets cumpre três funções, cada uma com um prazo de validade diferente, e assim que você as nomeia a decisão entre guardar e arquivar praticamente se resolve sozinha.

As três funções que os tickets antigos cumprem

Função 1: contexto para o agente. "Esse cliente já escreveu antes? O que prometemos a ele?" Esse é o uso do dia a dia, e ele é fortemente puxado para o presente. Antes de confiar na regra de bolso de quem quer que seja, olhe os dados da sua própria ferramenta: veja quando foi a última vez que um agente abriu um ticket com mais de um ano. Na maioria dos times, as consultas se concentram de forma esmagadora nos últimos seis a doze meses, com uma cauda fina de contas enterprise ativas e disputas em aberto.

Função 2: relatórios e tendências. Curvas de volume, mistura de assuntos, padrões sazonais. Relatório precisa de agregados, não de conversas cruas — e agregados podem ser calculados uma vez, exportados como números e guardados para sempre a um custo irrisório. Você não precisa de dez anos de tickets brutos para lembrar que janeiro é o seu pico.

Função 3: base para a IA. A função mais nova e a mais mal compreendida das três, então ela merece uma seção só dela.

Repare no que não aparece nessa lista: nada exige histórico bruto de uma década inteira dentro da ferramenta em que o seu time trabalha todo dia. A Função 1 quer atualidade, a Função 2 quer números e a Função 3 — como veremos a seguir — quer curadoria. O impulso de migrar tudo vem da aversão à perda, não de nenhuma função que o dado realmente cumpra.

O que a sua IA realmente precisa (menos do que você imagina)

Uma intuição tentadora diz: quanto mais histórico, mais inteligente a IA. O funcionamento da IA de suporte moderna aponta exatamente para o lado contrário.

Os agentes de IA constroem as respostas a partir da sua base de conhecimento — artigos atuais, com curadoria —, e não escavando anos de conversas cruas. Onde os tickets passados ajudam de verdade, são os recentes e bem resolvidos: eles mostram como o seu time fala hoje, sobre o produto que você entrega hoje. Tickets velhos descrevem produtos que já mudaram, políticas que já foram substituídas e contornos que já foram corrigidos. Jogá-los na IA não acrescenta sabedoria; acrescenta contradição — e contradição chega até o cliente na forma de respostas erradas ditas com toda a confiança.

Há um efeito de segunda ordem que os times não enxergam: histórico obsoleto também polui a busca dos agentes. Quando alguém procura "política de reembolso" e recebe resultados de três gerações de política, o rascunho que a IA monta em cima dessa busca herda a confusão. Um corpus podado e recente não é uma concessão na qualidade da IA — ele é a qualidade da IA. É por isso que uma migração é, discretamente, o melhor evento de preparação para IA que um time de suporte ganha: ela força a faxina no corpus que ninguém agenda por conta própria.

O framework guardar / arquivar / excluir

São três baldes, decididos por classe de dado e não ticket a ticket:

• Guardar (migrar para a ferramenta viva): os últimos 12 a 24 meses de conversas, todos os contatos com seus campos personalizados, a base de conhecimento inteira e as disputas em aberto ou fechadas há pouco, independentemente da idade. Isso cobre quase toda consulta real e tudo aquilo de que a IA se beneficia.
• Arquivar (exportar, guardar, não importar): todo o resto, como exportação somente leitura em formato estruturado — JSON com um índice vence CSV para qualquer coisa que você talvez precise buscar um dia — mais os anexos, em um armazenamento sob o seu controle. O arquivo existe para a auditoria rara, para a disputa e para a consulta nostálgica; ele não tem lugar no índice de busca da ferramenta em que você trabalha.
• Excluir: tickets fechados como spam, trocas de uma palavra só, entulho de e-mails devolvidos e tickets de teste. Isso não é minimalismo arriscado; é remoção de ruído. Nunca ninguém precisou do acervo histórico das respostas automáticas.

O framework tem um efeito colateral agradável: o seu novo helpdesk começa rápido e continua rápido, porque o índice de busca dele carrega sinal em vez de sedimento.

Obrigações de retenção, em bom português

Aqui os times ou prometem demais ou simplesmente travam, então vamos ser diretos e honestos. As regras de retenção existem, elas variam de caso para caso — e este artigo não é uma consultoria jurídica.

Ainda assim, vale conhecer alguns formatos gerais:

• Alguns registros têm retenção mínima obrigatória em determinados setores e jurisdições — em geral coisas como correspondência ligada a cobrança, reclamações em setores regulados ou registros atrelados a contratos. A obrigação costuma se prender ao tipo de registro, e não ao helpdesk como um todo.
• Os regimes de privacidade puxam para o lado oposto: os princípios de minimização de dados esperam que você guarde dados pessoais apenas pelo tempo necessário a uma finalidade declarada. "Guardamos tudo para sempre porque assim era mais fácil migrar" não é uma finalidade.
• Arquivar não isenta o dado das obrigações de privacidade. Um ticket no armazenamento frio continua sendo dado pessoal: pedidos de exclusão, pedidos de acesso e os deveres em caso de incidente alcançam o dado lá também.

O movimento prático: antes da migração, peça a quem cuida do jurídico ou de compliance na sua empresa que escreva os prazos de retenção por classe de dado — tickets, contatos, anexos, CSAT —, mesmo que a resposta seja uma tabela simples de três linhas. A migração então implementa a tabela. É essa, por inteiro, a relação entre as duas coisas: o jurídico decide, a migração executa.

Como lidar com dados pessoais no arquivo

Se você seguir o framework, é no arquivo que os dados pessoais antigos vão se concentrar — então trate esse arquivo com intenção:

• Restrinja o acesso. O helpdesk em uso tem acesso por papéis; o seu arquivo deveria ter também. Um bucket aberto ao mundo com dez anos de conversas de clientes é um passivo, não um backup.
• Mantenha um manifesto: o que o arquivo contém, quais intervalos de datas, em que formato e quem aprovou o prazo de retenção. O seu eu do futuro, lidando com um pedido de exclusão, vai consultar o manifesto em vez do dump bruto.
• Projete pensando na exclusão. Guarde os dados por cliente de um jeito que permita remover os registros de uma pessoa sem desempacotar tudo. Um arquivo do qual você não consegue excluir nada é uma obrigação que você não consegue cumprir.
• Defina uma validade. Decida quando o próprio arquivo será revisado ou destruído, e coloque isso no calendário. Retenção sem data final é só acúmulo com um documento de política em cima.

O que isso significa para o seu plano de migração

A decisão sobre retenção remodela a própria migração, e para melhor: a importação para a ferramenta viva encolhe a uma fração do plano ingênuo de "mover tudo", o que significa janelas de importação mais curtas, busca limpa desde o primeiro dia e um corpus de IA que nasce afiado em vez de turvo. Os times que escolhem de 12 a 24 meses mais as disputas costumam ver a importação terminar em horas, e não em dias.

A migração do MoveDesk deixa você escolher a profundidade do histórico na hora de importar — e, como a migração assistida é gratuita e as duas ferramentas podem rodar em paralelo, dá para começar com 12 meses, conviver com isso por um mês e importar um histórico mais profundo depois, se a realidade um dia pedir. Pela nossa experiência, ela raramente pede.

Escreva a tabela dos três baldes esta semana — guardar, arquivar, excluir, com um prazo de retenção por classe. É uma página só, deixa a migração menor e ainda melhora a sua postura de dados no caminho.