A prestação de contas do vendedor de campo fecha o mês em R$ 2.400 de combustível e pedágio. Dezoito visitas no período, todas com check-in, todas marcadas como "realizada". O reembolso é aprovado sem uma pergunta.
Procure agora o que saiu da visita do dia 12, ao atacado farmacêutico de Sumaré — 140 km de ida e volta, manhã inteira. Não está em lugar nenhum. A empresa pagou o deslocamento e não guardou nada do que ele produziu. Falta a resposta para a única pergunta que paga a gasolina: e daí?
O check-in prova a coisa errada
O check-in é a parte da visita que todo mundo lembra de fazer e que menos importa. Ele responde "o vendedor estava lá". Só que presença nunca foi o problema da PME: ele foi, gastou combustível, sentou com o comprador.
Vale reparar em quem o check-in serve: à desconfiança do gerente, não à venda. Quem instala visita no CRM para conferir se o vendedor saiu de casa usa ferramenta cara para resolver problema de contratação. E o vendedor entende o recado na primeira semana: bate o ponto na portaria, e o sistema fica satisfeito.
O que decide o próximo negócio está do outro lado do encontro. É o check-out — e é justamente ele que o vendedor esquece, porque a essa altura já está no carro, atrasado para a próxima.
O que só o deslocamento produz
Existe uma classe de informação que a mesa não alcança. Você não descobre por telefone que o galpão do cliente está com dois turnos parados, nem no ERP que quem manda na compra não é o comprador, e sim o encarregado que reclamou do prazo no caminho do portão.
Isso é o que a viagem comprou. Se o registro guarda só data, endereço e "realizada", a empresa pagou o deslocamento e jogou fora a mercadoria.
Por isso o check-out separa o que foi conversado do que foi aprendido: temas discutidos, necessidades identificadas, objeções ouvidas, produtos de interesse e resultado. São campos diferentes porque respondem a perguntas diferentes. "Falamos de preço" é tema. "Ele acha nosso prazo 10 dias pior que o do concorrente" é objeção — e muda a proposta da semana que vem.
A cadeia: check-out vira conversa sem ninguém decidir registrar
Aqui está a mecânica que separa uma visita útil de um "realizado". Quando o vendedor fecha o check-out no zCRM, o sistema cria sozinho uma conversa no histórico da conta, com canal visit. Ele não escolhe registrar, não abre outra tela, não decide se vale a pena. O deslocamento vira memória porque a visita terminou, e ponto.
O mapeamento é campo a campo:
- o objetivo da visita vira o assunto da conversa;
- o resultado vira o resumo e o desfecho;
- os temas discutidos viram os detalhes;
- os participantes e os próximos passos atravessam com o mesmo nome;
- o check-in vira a hora de início e o check-out a hora de fim;
- a conversa nasce com visibilidade de equipe — quem assumir a conta depois vai ler.
E a duração é calculada, não digitada: a diferença entre check-in e check-out. Ninguém preenche "durou uma hora e meia" de memória, três dias depois, arredondando para cima. Duração digitada é duração lembrada; duração calculada é duração medida.
A conversa de visita é a única que o vendedor não precisa ter disciplina para criar — ela é subproduto de fechar a visita.
A próxima data é o campo que paga a viagem
De todo o check-out, um campo tem consequência fora da tela: a sugestão de próxima visita. Ela vira o follow-up prometido da conversa — e follow-up prometido entra no cálculo da próxima ação da conta, que no zCRM é derivada, nunca digitada: a menor data entre a atividade a fazer, a visita planejada e o follow-up prometido.
A consequência vale dizer com todas as letras: sair da visita sem sugerir a próxima data é sair sem próxima ação. A conta volta para o silêncio — não entra na agenda de ninguém, não puxa prioridade, não cobra retorno. Você dirigiu 140 km para produzir um registro histórico.
Não é burocracia pedir essa data no check-out. É o momento certo: ainda no estacionamento do cliente, o vendedor sabe se volta em duas semanas ou em três meses. Na segunda-feira seguinte ele não vai mais saber.
Onde foi planejado × onde aconteceu
A visita é a única entidade comercial com endereço, e o zCRM guarda três: o planejado, o do check-in e o do check-out — com latitude e longitude lidas do dispositivo.
Isso serve para comparar. Planejou a matriz, fez o check-in no centro de distribuição do outro lado da cidade? Não é fraude, é informação: o cadastro do endereço está errado, ou quem decide não fica onde você achou que ficava.
Erros comuns nas visitas
- Tratar visita como "atividade do tipo visita". Economiza uma tabela e custa o fluxo de campo: planejamento com endereço, check-in, check-out, cancelamento. Por isso, no zCRM, visita é entidade própria — decisão de desenho, não acaso.
- Fazer check-in e nunca check-out. A visita fica pendente para sempre e segue puxando a próxima ação da conta. Pior: o deslocamento não virou conversa nenhuma.
- Vincular a visita à oportunidade errada. O zCRM revalida no backend se contato, oportunidade e atividade de origem pertencem à mesma conta antes de aceitar o vínculo.
- Deixar o preenchimento para o fim do dia. Às 19h se lembra o resultado. O que se perde é a objeção.
- Medir vendedor por número de visitas. Você recebe o que mediu: muitos check-ins, nenhum aprendizado.
Como isso se aplica no zCRM
A dor é a visita que custa caro e devolve um "realizado": a empresa paga combustível, hora e janela do cliente, e recebe uma linha na lista.
O que o zCRM usa hoje: visita é entidade própria, com planejamento por endereço, check-in, check-out e cancelamento. O check-out grava o que o campo produz — temas, necessidades, objeções, produtos de interesse, resultado — e a conclusão cria automaticamente a conversa no histórico, com canal de visita, duração calculada e visibilidade de equipe. A sugestão de próxima visita vira follow-up prometido e entra no cálculo da próxima ação da conta. Visita planejada aparece na agenda e também puxa a próxima ação. Enquanto não estiver concluída ou cancelada, dá para editar tipo, objetivo, data, endereço e descrição, com a alteração registrada na timeline.
A decisão que muda: o gerente para de perguntar "quantas visitas você fez" e passa a perguntar "o que a visita de Sumaré produziu e quando você volta lá". A primeira tem resposta no ponto. A segunda tem resposta no histórico — ou não tem, e aí você achou um problema real.
Os limites, explícitos:
Não existe rastreamento de rota, roteirização, otimização de itinerário nem cerca virtual. O GPS é lido no check-in e no check-out, ponto. Não há acompanhamento contínuo do vendedor — isso é desenho, não pendência.
Não existe aplicativo mobile nativo. A interface é responsiva no navegador, e a geolocalização depende dele e da permissão do dispositivo.
O sistema não comprova que a visita aconteceu. Ele registra a coordenada que o dispositivo informou: evidência, não auditoria antifraude. Quem vender check-in como controle de fraude está vendendo outra coisa.
A visita não gera pedido nem proposta, e não escreve no ERP. Ela vira memória e vira data.
O sistema não cobra o check-out esquecido. Não há lembrete proativo: a visita sem check-out continua pendente e segue puxando a próxima ação da conta. Quem cobra ainda é o gerente.
Próxima leitura
- Conversas no CRM: o que registrar sem transformar o vendedor em digitador.
- Agenda comercial: como separar atividade, visita, conversa e oportunidade.
- Histórico comercial: por que memória de vendedor não escala.