Como automatizar o follow-up pós-venda no Salesforce e parar de perder cliente no silêncio

O negócio fechou, todo mundo comemorou, e o CRM criou direitinho uma tarefa de retorno pós-venda para dali a alguns dias. Aí ela vence. E ninguém liga. O vendedor está atrás da próxima meta, a tarefa some no meio de trinta outras, e o cliente que acabou de comprar fica semanas sem um único contato. Quando ele não renova, ninguém sabe apontar o momento em que a relação esfriou. Esse é o churn silencioso: não há um evento de perda, há uma ausência de acompanhamento que ninguém viu acontecer.

Para automatizar o follow-up pós-venda no Salesforce, uma classe Apex agendada (Schedulable) roda todo dia, encontra as tarefas de acompanhamento ainda abertas e já vencidas, e dispara uma Custom Notification: um resumo por vendedor e um digest consolidado por gestor. Passado o SLA de dias vencidos, ela escala o segundo toque, tudo sem campo custom novo, derivando dono, gestor e atraso de campos padrão.

Por que o follow-up pós-venda morre no silêncio

A maioria das empresas até tem o processo desenhado no papel: ao fechar, criar uma tarefa de retorno para confirmar entrega e satisfação. O problema não é a intenção, é que a tarefa nasce e depois fica órfã. Ela entra na lista de afazeres do vendedor competindo com prospecção, proposta, reunião e a meta do mês, que é o que paga o comissionamento dele. Retorno de cliente que já comprou não tem urgência aparente, então escorrega para o fim da fila todo santo dia, até vencer.

O custo disso não aparece num relatório porque ele é uma não-ação. Você consegue medir venda perdida, ticket caído, desconto exagerado. Não consegue medir com facilidade o cliente que ficou trinta dias sem contato, achou que a empresa sumiu depois de faturar, e simplesmente não respondeu a próxima cotação. A conta chega meses depois, disfarçada de "queda de recompra", e ninguém liga o ponto A ao ponto B. Segundo estudos de retenção amplamente citados no mercado, reconquistar um cliente que esfriou custa bem mais que manter o relacionamento aquecido desde o começo, e o follow-up pós-venda é justamente o mecanismo mais barato de manter esse calor. O que falta quase sempre não é a tarefa, é alguém, ou algo, garantindo que a tarefa não morra vencida.

A tarefa vencida não é o problema. A ausência de um vigia é

Vale separar dois momentos que costumam ser confundidos. O primeiro é a criação da tarefa de acompanhamento: isso é um evento por registro, acontece uma vez, no instante em que a Oportunidade vira Closed Won. Um Flow before-save ou after-save resolve, cria a Task para o dono da conta com vencimento alguns dias à frente e um assunto padronizado, algo como "Pós-venda: confirmar entrega e satisfação". Até aqui, quase toda org já está.

O segundo momento é o que ninguém constrói: varrer, todo dia, todas as tarefas de pós-venda que venceram e continuam abertas, e cobrar quem precisa cobrar. Esse é um trabalho de conjunto, não de registro. Ele precisa olhar a equipe inteira, agrupar por dono, resolver o gestor de cada dono e decidir o que já estourou o prazo. Flow disparado por registro não enxerga esse conjunto, ele reage a um evento e vai embora. A fronteira entre os dois casos é a mesma que tracei no post sobre quando usar Flow ou Apex no Salesforce: enquanto a lógica couber num registro e seu momento, Flow; quando ela precisa varrer um conjunto num horário fixo, território de uma classe Schedulable em Apex.

O detalhe que faz esse vigia funcionar é ele ser agendado, não reativo. Você não quer disparar o alerta no minuto em que a tarefa vence (isso geraria um pico de avisos espalhados pelo dia e um por tarefa). Quer um pente-fino diário, num horário calmo, que consolida o estado do dia inteiro num aviso só. É a diferença entre um alerta ao vivo, que tem seu lugar em situações de tempo real, e um resumo agendado. Sobre o outro extremo, o de reagir na transição exata de um evento crítico, escrevi no post de alertas em tempo real com Platform Events: pós-venda vencido é o oposto, ele pede o digest calmo das 7h, não o push instantâneo.

A classe agendada: um Schedulable que roda todo dia e agrupa por dono

O coração da solução é uma classe que implementa Schedulable e roda uma consulta única: as tarefas de pós-venda abertas cujo vencimento já passou, ordenadas da mais antiga para a mais recente. Ordenar por ActivityDate ascendente não é capricho: garante que a primeira tarefa de cada dono seja a mais atrasada, que é o ponto de partida da ação e o alvo do clique na notificação.

List<Task> overdue = [
    SELECT Id, OwnerId, Owner.Name, ActivityDate, WhatId, What.Name
    FROM Task
    WHERE Subject = :POS_VENDA_SUBJECT
      AND IsClosed = false
      AND ActivityDate < :today
    ORDER BY ActivityDate ASC NULLS LAST
];

Repare no Subject = :POS_VENDA_SUBJECT. É o assunto que o Flow gravou na criação, e é ele que amarra a tarefa criada ao lembrete que a cobra. Sem esse vínculo por assunto, você varreria toda e qualquer tarefa vencida da org, ligação, reunião, e-mail, e o pós-venda se perderia no meio. Filtrar pelo assunto padronizado é o que mantém o escopo exato. E o IsClosed = false é o que torna o desenho autolimpante: no instante em que o vendedor marca a tarefa como concluída, ela deixa de bater a consulta e some do lembrete do dia seguinte, sem nenhum passo extra.

Com as tarefas em mãos, o agrupamento por dono é um laço simples que monta, para cada vendedor, um resumo: quantos acompanhamentos venceram, qual a mais antiga, quantos já passaram do limite de escalonamento e as primeiras contas envolvidas. Como a lista já veio ordenada, a primeira tarefa que o dono aparece é automaticamente a mais antiga, então o resumo captura o vencimento e o Id dela sem precisar reordenar nada.

for (Task t : overdueTasks) {
    OwnerSummary s = byOwner.get(t.OwnerId);
    if (s == null) {                         // 1a ocorrência = a mais antiga (lista já ordenada)
        s = new OwnerSummary();
        s.oldestTaskId  = t.Id;              // alvo do clique na notificação
        s.oldestDueDate = t.ActivityDate;
        byOwner.put(t.OwnerId, s);
    }
    s.overdueCount++;
    if (daysOverdue(t.ActivityDate, today) > ESCALATION_DAYS) {
        s.escalatedCount++;                  // segundo toque: já estourou o SLA
    }
}

Uma escolha de arquitetura que costuma gerar dúvida: a classe é without sharing, de propósito. Ela roda em contexto de agendador, no papel de sistema, e precisa enxergar as tarefas de toda a equipe para resolver dono e gestor. O que a protege não é o sharing, é o alvo do envio: cada notificação vai só para o destinatário que já tem acesso àquele registro (o próprio dono, ou o gestor dele). O agendador não expõe nada a quem não deveria ver. Vale entender por que essa decisão é consciente e não descuido, o assunto de contexto de execução e visibilidade eu destrinchei no post sobre segurança em Apex com CRUD, FLS e sharing.

Digest ao gestor e escalonamento por SLA: o segundo toque

Avisar o vendedor é metade do serviço. A outra metade é dar visibilidade ao gestor sem afogá-lo. Aqui entra o digest consolidado: um único aviso por gestor que soma o atraso da equipe inteira e nomeia os vendedores mais atrasados, do maior para o menor. Em vez de o gestor receber quinze notificações soltas, ele recebe uma frase que já diz de quem cobrar primeiro. Acima de um teto de nomes, o texto resume o resto em "e mais X vendedores", para não virar uma parede de texto.

O escalonamento por SLA é o que transforma lembrete de rotina em cobrança. O atraso de cada tarefa é a diferença em dias entre hoje e o ActivityDate. Passado o limite (na Vetra, a distribuidora fictícia que mantenho como demonstração do portfólio, sete dias), a tarefa deixa de ser um lembrete gentil. O texto do aviso ao dono muda de "registre o retorno" para "já passou de sete dias, foi escalado ao seu gestor, priorize hoje", e o digest do gestor ganha uma linha de escalonamento com o total estourado, quantos vendedores estão nessa situação e o pior atraso da equipe. Esse patamar de dias sai de um Custom Label, então o gestor de vendas ajusta o SLA sem pedir deploy, no mesmo espírito de medir tempo por status que descrevi em como medir SLA e tempo em cada status no Salesforce. Essa mesma ideia de escalar o que ficou parado além do prazo vale sem uma linha de código: veja como o onboarding de cliente com filas e Flow usa o caminho agendado para cobrar a etapa que empacou, sem campo de data custom.

Para tornar concreto, veja o que uma equipe de três vendedores gera num dia real de varredura, com o limite de escalonamento em sete dias:

O gestor recebe uma frase do tipo "Sua equipe tem 7 acompanhamentos vencidos, em 3 vendedores. Por vendedor: Ana (4), Bruno (2), Carla (1). Escalonamento: 3 acompanhamentos passaram de 7 dias vencidos em 2 vendedores (pior atraso: 11 dias)." Ana e Carla recebem, cada uma, o aviso de segundo toque; Bruno recebe o lembrete de rotina. Ninguém recebe uma notificação por tarefa. São, no total, quatro envios (três aos donos, um ao gestor) para sete tarefas espalhadas, e cada envio já vem resumido e priorizado.

Anti-fadiga por design: um envio por dono, um por gestor

Esse é o ponto que separa uma automação que a equipe respeita de mais uma que ela silencia. A tentação óbvia é disparar uma notificação por tarefa vencida. Faça isso e, na primeira semana, o vendedor com dez pendências recebe dez alertas, aprende a ignorar todos, e cria uma regra mental de "isso aí é spam do sistema". A partir daí a automação existe mas não move ninguém, que é o pior dos mundos: você pagou pela construção e ainda colhe o hábito de ignorar avisos.

A regra que segurou isso na Vetra é dura: um único envio por dono e um único por gestor, por dia, apenas de tarefas abertas e vencidas. O envio consolida a contagem, mostra a conta mais antiga como âncora e usa o clique para levar direto à tarefa mais atrasada, o ponto onde a ação deve começar. Como só entra o que está aberto e vencido, o volume se autorregula: resolveu, saiu; deixou acumular, o número sobe e a cobrança fica mais dura por conta do escalonamento. O aviso vira um termômetro do próprio comportamento, não um despejo de notificações.

Há um contraponto honesto. Esse desenho de um resumo diário só faz sentido quando o volume de acompanhamentos é alto o bastante para que notificar tarefa a tarefa vire ruído. Numa operação que fecha três negócios por semana, um Flow simples que manda um e-mail no dia do vencimento já resolve, e montar Schedulable, digest e escalonamento seria engenharia a mais para um problema que ainda não existe. A régua é o volume e a dispersão da equipe: muitos donos, muitas tarefas, um gestor que precisa de visão agregada. Abaixo disso, construa o simples.

Por que nada disso exigiu um campo custom novo

Uma restrição comum em orgs maduras, e que enfrentei de verdade, é que criar campo custom em objeto padrão vira um processo burocrático, às vezes travado por governança. A boa notícia é que esse lembrete inteiro se apoia só em campos que já existem. O dono da tarefa é OwnerId. O gestor sai de User.ManagerId, a hierarquia padrão de usuários. O atraso é calculado na hora, subtraindo o ActivityDate da data de hoje, então não há nenhum campo "dias em atraso" para materializar e manter atualizado. O vínculo entre criação e cobrança é o Subject padronizado. E os parâmetros que mudam de vez em quando (dias de escalonamento, quantos vendedores nomear no digest) moram em Custom Label, ajustáveis sem deploy.

Isso importa por dois motivos. Primeiro, torna a entrega possível mesmo numa org que restringe campos novos, o que já foi a diferença entre implantar na semana ou esperar um mês pela aprovação de metadado. Segundo, reduz a superfície de manutenção: campo custom derivado é um lugar a mais para o dado divergir. Calcular o atraso no momento do envio, a partir da fonte padrão, elimina a chance de o número guardado ficar defasado em relação à realidade da tarefa. Menos campo materializado, menos coisa para sincronizar, menos bug silencioso.