Roteamento de tickets no CRM: como automatizar quem atende o quê

Fim de tarde numa loja a 300 km da capital, e o PDV do caixa 2 apaga. Não liga mais. A fila passa a andar num caixa só, clientes veem a fila crescendo e vão embora, o impacto financeiro é imediato. A gerente registra o chamado no portal de atendimento do CSC (Centro de Serviços Compartilhados), e a pergunta que decide o resto da semana daquela loja é: quem vai lá consertar, e em quanto tempo?

A resposta não era óbvia, nem imediata. A manutenção de TI das lojas estava dividida entre três empresas terceirizadas, cada uma responsável por certos equipamentos em certas lojas. Mandar o chamado para a empresa errada significava perder um dia inteiro para ouvir "isso não é conosco". E ainda tinha o relógio: o contrato previa prazos diferentes conforme a distância da loja até a capital. Errou isso e ou o fornecedor é cobrado por um SLA que nunca assinou, ou a loja espera três dias por um conserto de oito horas. E enquanto a informação correta não chega no time correto, o cliente continua com o atendimento prejudicado e a loja sofre os impactos financeiros.

Alguém precisava tomar essa decisão para cada chamado. E eram milhares de chamados.

Eu já presenciei isso algumas vezes, aquela sua loja do bairro, em que você sempre pega na geladeira uma água, um suco. Um belo dia a geladeira para de funcionar e você desiste da compra porque a água não está gelada. No meu caso, foram seis meses vendo essa geladeira sem funcionar, e obviamente meu hábito mudou e nunca mais comprei lá, mesmo depois que a geladeira finalmente foi consertada.

O que é roteamento de tickets

Esse ato de decidir o destino de cada chamado tem nome: roteamento de tickets. É a etapa entre o cliente apertar "enviar" e o chamado aparecer na fila de quem resolve. Todo CRM faz alguma versão disso, do help desk da padaria ao contact center do banco.

Numa operação pequena, o roteamento é uma pessoa. Já foram tantas visitas a clientes que essa cena já é comum para mim. O supervisor abre a fila de manhã, bate o olho em cada chamado e distribui. E está tudo bem: para vinte chamados por dia, automatizar isso está longe de ser uma prioridade. A régua muda quando o volume cresce. Com milhares de chamados por dia, distribuir fila vira um emprego em tempo integral, e dos ruins: repetitivo, chato, e que faz o cidadão repensar qual o sentido da vida. Uma pessoa cansada manda o chamado de PDV para a empresa de monitor, esquece a prioridade, aplica o prazo da capital numa loja do interior. Não por incompetência. Por ser humana, às cinco da tarde, no chamado de número oitocentos. (quando aplica, uma vez que fazer o tracking de SLA sem um CRM é algo que exige um quê de criatividade em planilhas)

Mil lojas, três fornecedores, dez equipamentos

O caso que me ensinou o tamanho desse problema foi o de uma rede varejista com mais de mil lojas pelo Brasil. Dez tipos de equipamento de TI por loja: monitor, desktop, PDV, impressora fiscal, leitor de código de barras, e por aí vai. Três fornecedores dividindo a manutenção de tudo isso.

Aí vem o detalhe que muda o jogo: o fornecedor certo não dependia só do equipamento. Dependia do equipamento e da loja. O mesmo PDV era atendido por uma empresa numa região e por outra empresa em outra, conforme o contrato de cada fornecedor. Se a regra fosse só por equipamento, uma tabela de dez linhas colada na parede resolvia. Com loja e equipamento juntos, a conta muda: mil lojas vezes dez equipamentos são dez mil combinações, cada uma com um dono.

E em cima de tudo isso, o SLA. O contrato tinha três faixas de prazo conforme a distância da capital: loja na região metropolitana tinha um prazo, loja a até 100 km tinha outro, e acima disso um terceiro, porque tem conserto que começa com um técnico pegando estrada. Ninguém roteia isso de cabeça. Ou melhor: alguém roteava, e essa pessoa não dava mais conta. A empresa contratou o CRM, mas sem a configuração adequada, o que antes era feito via planilha agora era uma sequência de cliques na interface do atendente.

A matriz de fornecedores

A parte boa: o cliente já sabia responder quem atende o quê. A resposta existia, viva e atualizada, numa planilha. Cada linha dizia: esta loja, este equipamento, este fornecedor, este SLA.

Na reunião de discovery, ficou claro qual era o cenário. Os dados e processos já estavam definidos, faltava tirar a execução manual desse roteamento para que a operação fosse escalável.

O que a gente fez foi integrar essa planilha com o CRM. Ela foi ingerida como um objeto customizado, que é o nome que os CRMs dão para uma tabela sua vivendo dentro do sistema: você define as colunas, carrega as linhas e, o mais importante, as automações conseguem consultar. A gente passou a chamar aquilo de matriz de fornecedores, e ela virou a fonte da verdade do roteamento inteiro.

Nada de exótico: quatro colunas e dez mil linhas, agora num lugar onde a automação alcança.

A automação (e o formulário que pergunta só o essencial)

Agora o caminho do chamado. A pessoa da loja entra no portal de atendimento, que só funciona logada. E aqui entra uma decisão de design que rende mais do que parece: o formulário não pergunta em que loja ela está. Não precisa. O CRM tem o recurso de organizações, em que cada usuário pertence a uma, e no nosso desenho cada organização era uma loja. O chamado já nasce sabendo de onde veio. Formulário bom não pergunta o que o sistema já sabe: nome da loja, endereço, telefone, CNPJ, tudo isso já mora no cadastro da organização. Sobrou para a pessoa escolher o equipamento num dropdown de dez opções e descrever o problema.

Na hora em que o chamado é criado, a automação entra em ação. Ela lê os dois campos que importam, loja e equipamento, e procura na matriz a linha correspondente. Achou? Faz duas coisas: atribui o chamado ao grupo do fornecedor daquela linha e aplica o SLA dela. Os técnicos dos três fornecedores trabalhavam como agentes dentro do CRM do cliente, cada empresa com o seu grupo, então rotear era entregar o chamado direto na fila de quem resolve, com o prazo de SLA já correndo e visível para todo mundo. Do envio do formulário até o chamado cair na fila certa: menos de um segundo, sem passar por mão nenhuma.

Quando a matriz não tem resposta

E quando a busca volta vazia? Acontece. O caso clássico era o equipamento fora da lista: nem todos os equipamentos da loja estavam no contrato, só os principais. Então quando alguém abre chamado para algo como problema no sensor de abertura da porta, a automação não tem como adivinhar o dono.

Para esses casos existia uma fila de triagem. O chamado sem correspondência caía nela, e o CSC do cliente, o centro de serviços compartilhados, olhava caso a caso e decidia o destino na mão, fazendo cotação com outros fornecedores. Assim o time do CSC gastava atenção só nos chamados que realmente pediam julgamento, em vez de ter que agir nos outros milhares.

Quem cuida da matriz depois

Roteamento automático tem uma dependência que ninguém pode esquecer: a matriz precisa acompanhar o contrato. Loja nova, fornecedor trocando de região, faixa de SLA renegociada: se a planilha mudou e o objeto customizado não, a automação continua roteando, com toda a confiança, para o lugar errado.

No nosso caso as mudanças eram raras, coisa de algumas vezes por ano, e o processo continuou o mesmo do primeiro dia: o cliente atualizava a planilha e a gente ingeria de novo. Simples e suficiente. Para uma operação que mexe nas regras toda semana eu recomendaria outra coisa: um aplicativo dedicado, com uma tela própria para editar as regras direto, sem planilha no meio. E existe um meio do caminho, que a gente já montou para clientes com necessidade parecida e sem vontade de investir na tela: um script que lê o Excel e atualiza o objeto customizado pela API. A planilha continua sendo a fonte da verdade, no formato que o time de contratos já domina, e ninguém edita dez mil registros na mão.

O que mudou

Uma das coisas mais gratificantes na vida de um consultor é ver o sorriso do time de atendimento após uma automação realizada com sucesso. O tempo entre abrir o chamado e ele estar na fila certa caiu de "quando alguém pegar" para imediato, em qualquer horário, domingo incluído. O CRM que até aquele momento era "caro" começou a justificar o seu investimento. Essa é a minha luta pessoal, de reduzir a entropia no atendimento. Como digo para meus colegas, enquanto houver Excel, haverá o caos no mundo.

No fim, isso tudo foi uma planilha, um objeto customizado e uma automação que lê dois campos. Nenhuma inteligência artificial, nenhum projeto de seis meses. Se sua operação se parece com o que eu falei aqui, vem trocar uma ideia com a gente na Red Lotus.

Leandro é fundador da Red Lotus Tecnologia, especializada na implementação, suporte e evolução de Freshdesk para times de atendimento no Brasil.