Acionamento de cobrança: como registrar cada contato

Acionamento de cobrança é cada tentativa de contato com o devedor: uma ligação, uma mensagem, uma carta, uma visita. Registrar o acionamento é guardar por qual canal ele foi feito, com qual contato, o que aconteceu e o que ficou combinado, para que o próximo operador não comece do zero e o gestor saiba o que a equipe fez. Na especificação do quarto incremento deste CRM de cobrança, cada um desses campos exigiu uma decisão, e duas delas ficaram para validação jurídica. Este artigo mostra as regras, as escolhas e o que ficou de fora de propósito.

Um escopo que encolheu duas vezes#

O mapa do projeto previa, para este incremento, os acionamentos e a fila de trabalho do operador, isto é, a ordem em que os devedores chegam a cada pessoa. A fila já tinha sido adiada uma vez, na especificação da baixa de títulos, porque não estava madura. Desta vez, o escopo foi definido assim desde o início: só o registro dos contatos. A fila e os limites de contato (horários, frequência, canais permitidos) continuam em aberto.

Mesmo assim, a fila quase voltou por outro caminho. No meio das perguntas, veio uma observação: “um acionamento pode terminar agendando um retorno”. Retorno é a data e hora em que o operador combinou voltar a falar com o devedor. A ferramenta propôs uma agenda simples: a lista “Meus retornos” na entrada do sistema, encerrada pelo próximo contato. As duas perguntas sobre a agenda foram respondidas na opção recomendada. Logo depois, veio a correção: “Não vamos tratar a agenda.”

A agenda de retornos é a ponta de uma fila de trabalho. Decidir quem vê um retorno, quem o atende e quando ele se encerra é decidir como o trabalho chega ao operador, e esse era o tema adiado. O retorno ficou só registrado no acionamento: aparece no histórico, sem lista e sem aviso.

Canal, devedor e data do contato#

O canal em lista fixa repete a lógica do meio de pagamento no incremento anterior: os números por canal não dependem de como cada pessoa escreveu “Whats”, “zap” ou “WhatsApp”. O acionamento é do devedor, e não de um título, porque um contato é com a pessoa, sobre tudo o que ela deve.

A data informada resolve um problema real e cria outro. Contatos feitos fora do sistema, ou no fim do expediente, precisam entrar com a hora certa. Por outro lado, um prazo longo permite completar a produção de um dia fraco com contatos lançados depois. Os 7 dias são uma premissa, e a especificação registra que a área de operação é quem a validaria. O momento do lançamento fica gravado junto, então a diferença entre contato e lançamento sempre aparece.

Resultados: uma lista do gestor com três tipos fixos#

Que os resultados de um contato viriam de uma lista editável pelo gestor estava decidido desde a reorganização do mapa. O problema de uma lista livre é que qualquer indicador passa a depender de como cada gestor nomeou os resultados. “Não atendeu”, “Ninguém atendeu” e “NA” são a mesma coisa para quem lê e três coisas diferentes para quem conta.

A especificação pôs uma classificação fixa por trás da lista. Todo resultado é de um de três tipos: falou com o devedor, falou com terceiro ou sem contato. O gestor cria, renomeia e desativa resultados à vontade, mas o tipo não muda depois de criado. Mudar o tipo de “Caixa postal” para “falou com o devedor” reescreveria o significado de todos os acionamentos antigos que usaram esse resultado. Pelo mesmo motivo, resultado já usado não é apagado, só desativado.

Os resultados também decidem o retorno. A observação veio na mesma conversa: “existem categorizações que levam a isso, e categorizações que não permitem isso”. Cada resultado tem uma regra de retorno: exige data de retorno (“Pediu para retornar depois”), permite (“Não atendeu”) ou não permite (“Número ou endereço inexistente”). O sistema começa com 11 resultados nessa estrutura, que o gestor ajusta.

Nada é apagado: anulação com motivo#

Uma das regras gerais do projeto é que acionamentos, promessas e acordos formam um histórico que não se reescreve. A pergunta era o que fazer com um registro errado: o operador anotou o contato na ficha do devedor errado, ou escolheu o resultado errado.

Quem registrou pode anular o próprio acionamento. Anular o de outra pessoa exige uma permissão específica.

O contato usado e o texto do operador#

O operador escolhe o telefone ou o e-mail que está na ficha, ou digita outro: o número que o devedor passou durante a conversa, por exemplo. O contato digitado fica só no acionamento. O cadastro do devedor continua vindo da carteira importada, que já tem uma regra para isso desde o primeiro incremento. Deixar o operador atualizar o cadastro abriria um conflito: na próxima carga, o número digitado seria sobrescrito pelo que o sistema do credor manda, ou o contrário.

O texto livre do operador é guardado como texto puro: o que for digitado aparece exatamente como escrito, nunca interpretado como formatação ou código. Um texto com <script> aparece na tela como <script>. É a resposta concreta à decisão anterior de que o operador poderia escrever “texto sanitizado”.

O texto livre também é dado pessoal. A tela de registro lembra o operador de escrever só o necessário para a cobrança, que é o princípio da necessidade da Lei Geral de Proteção de Dados (art. 6º, III): tratamento limitado “ao mínimo necessário para a realização de suas finalidades”.

As premissas que um jurídico olharia#

Duas premissas da especificação são jurídicas, e nenhuma pessoa de produto deveria fechá-las sozinha.

Recado com terceiro. Um dos resultados iniciais é “Recado com terceiro”: o operador falou com um parente ou colega do devedor. O Código de Defesa do Consumidor diz, no art. 42, que “na cobrança de débitos, o consumidor inadimplente não será exposto a ridículo, nem será submetido a qualquer tipo de constrangimento ou ameaça”. O art. 71 trata como crime o procedimento que exponha o consumidor, injustificadamente, a ridículo. O sistema só registra o contato, mas o texto do operador pode guardar o que foi dito ao terceiro, e esse registro é prova. A premissa é que registrar esse resultado não expõe o credor. Se o jurídico discordar, o resultado precisará de orientação na tela ou de campos que impeçam registrar o conteúdo dito ao terceiro.

Quanto tempo o texto fica. A especificação assume que os acionamentos ficam enquanto o devedor estiver no sistema. Retenção e eliminação de dados pessoais têm regras próprias, e a especificação deixa isso registrado como premissa a validar, com a consequência: se estiver errada, será preciso um prazo de retenção e uma rotina de eliminação já neste incremento.

A visão do gestor e uma escolha contra a recomendação#

O gestor ganhou uma lista de todos os acionamentos do credor, com filtros por período, operador, canal, resultado e tipo, e, no resumo da carteira, o número de acionamentos e de devedores acionados nos últimos 7 e 30 dias, por tipo de resultado. Um devedor acionado mais de uma vez conta uma vez em cada tipo em que apareceu.

Nas permissões, a recomendação era criar duas: “registrar acionamentos” e “anular acionamentos de outros”, deixando a lista de resultados com a permissão de configuração que já existia. A escolha foi criar três, com “gerenciar resultados” separada. A lista de resultados define o que a operação mede, e quem altera faixas de atraso ou políticas de pagamento não precisa, por isso, mexer nela.

Em números#

O que vem a seguir#

O plano técnico propõe um módulo de acionamentos ao lado da carteira e dos pagamentos, com o tipo do resultado copiado em cada acionamento, já que ele não muda, para que a lista e o resumo não dependam da tabela de resultados. Depois do episódio dos pagamentos, a medição de desempenho entra no plano desde o início: 1 milhão de acionamentos num credor, com a lista e o resumo abrindo em até 2 segundos.