AI only sees what lands in the record, so map your buyer moments

An AI step in your sales process can only act on what has reached the data it reads at the moment it runs. If the buyer said something that changes the right next action, and that fact has not landed there yet, the step will act on yesterday's deal. Better prompts do not fix that. Better landing does.

The failure mode is acting ahead of the record. The follow up goes out the morning after the meeting because a timer said so. The stage changed, so the proposal step fired. Meanwhile the moment that should have changed the action, a new person in the decision or a new requirement, is sitting in a call transcript, an inbox, or a seller's head. Nothing in the CRM is wrong. It is simply behind.

The Truth note on evidence contracts covers what a commercial claim must carry once it exists in the record. This note covers the step before that: buyer moments that never become claims in time for the system that needs them.

Definition

Definition: A buyer moment landing map lists, for one AI step, the buyer moments that would change that step's action, and records when each moment happened, when it reached the data the step reads, and where it landed if it landed anywhere else.

A buyer moment is an event in the deal that changes what the right next move is. Typical examples: a new person joins the decision, the buyer names a new requirement, the timing moves, a competing option appears, or the buyer makes a commitment. Moments are not fields. A field is where a moment may eventually be written down.

Why a well kept CRM can still be behind

The UK Government Data Quality Framework treats timeliness as its own quality dimension. Data is timely when the lag between collection and availability suits the intended use. A correct fact that arrives after the step that needed it has run fails that step, even though nothing about the fact is inaccurate. The same framework recommends treating problems at source, where data is collected.

Gartner makes a related point about AI: data must be representative of the specific use case, and readiness includes the live feed into production systems, as an ongoing practice rather than a one time project. For a sales team, the live feed is whatever an AI step reads when it fires.

Many commercial AI steps are workflows, not free roaming agents. Anthropic describes workflows as systems that run through predefined code paths. Whether a step is a workflow or an agent, something starts it, and what starts it is a design choice. A timer, a stage change, or a new record are design choices, and each one decides how far ahead of the record the step is allowed to run.

Mark where each moment landed

Walk the buyer timeline of a few recent deals, using sources the team already has: emails, call notes, transcripts, calendar invites. For every moment that would have changed the step's action, mark one of four results:

• Landed. The moment reached the step's read set before the step ran.
• Late. It reached the read set, but only after the step had already acted.
• Buried. It was recorded, but somewhere the step does not read, such as a transcript, a shared inbox, or a document link.
• Lost. It never reached any system. It lives in a conversation or in someone's memory.

Each result has a different repair, and that is why the map is worth drawing:

• Lost needs a capture duty in the Playbook: who writes the moment down, in what form, and before what.
• Late needs a new trigger in Architecture: the step should start when the moment is captured, not when a clock runs out. If the delay comes from capture itself, the moment also needs a capture duty.
• Buried needs a Truth repair: either add that source to the read set with an explicit extraction step, or copy the fact into a field the step reads when it is captured.
• Landed needs nothing except an Operator who walks the next timelines and notices when it stops being true.

Worked example: the security review on the call

A team uses an AI step that drafts and sends a next steps email the morning after each buyer meeting. It reads the stage, the next step field, and the notes field the seller fills in the CRM after the meeting. The call transcript is stored, but the step does not read it.

On a call, the buyer's head of IT says that any vendor must pass a security review before a contract. The seller hears it, and it appears in the call transcript. The seller plans to update the CRM at the weekly pipeline review.

The next morning, the AI step reads a record that still says contract sent and drafts a friendly push for signature. The buyer receives it after explicitly saying that signature is blocked. Commercial capacity is lost twice: once in the buyer's trust, and again when the seller has to recover the conversation.

The landing map for this step shows one moment, a new requirement, that happened during the call, was buried in the transcript the same day, and landed in the read set days later. Late and buried at the same time.

The repair has three parts:

1. Playbook: a new requirement or a new person in the decision is a moment the owner captures before the meeting is closed out.

2. Architecture: the follow up step no longer fires the next morning. It fires when the post meeting capture is complete, and the capture form asks directly whether a new requirement or a new person appeared.

3. Truth: the requirement becomes a field the step reads, so the draft can propose the security review as the next step instead of signature.

Decision rule

If a buyer moment can change what an AI step does, that step must be triggered by the capture event that would record that moment, such as closing out the meeting, not by a timer or a stage change. If that capture is overdue, the step routes the deal to its owner instead of sending. Until that trigger exists, a person reviews the step's output before it reaches the buyer.

Moments that arrive between meetings, such as a buyer email naming a competing option, need their own capture event before the step can rely on them.

Order the repairs by what the map shows. Fix lost moments first, because nothing downstream can see them. Then fix late ones by moving the trigger. Then promote buried ones into the read set.

Checklist

• One AI step named, with what starts it today.
• The moments that would change its action, listed in plain language.
• A few recent deal timelines walked from existing sources.
• Each moment marked landed, late, buried, or lost.
• A capture duty written for every lost moment.
• The step's trigger moved from a timer or stage change to the capture event where moments arrive late.
• Buried facts promoted into fields the step reads.
• The next timelines walked after the change, by a named owner.

What this is not

It is not a call to record everything. Only moments that change a specific step's action belong on the map.

It is not a promise that AI output will be right. It removes one class of error: acting before the buyer's latest moment has landed.

It is not a reason to stop using timers anywhere. A timer is fine for a step whose action no buyer moment can change.

FAQ

Which moments belong on the map?

Only the ones that would change the action of the step you are mapping. For a follow up step that usually means new people, new requirements, timing changes, competing options, and commitments. A moment that changes nothing about this step can wait for another map.

What if the team will not capture moments as they happen?

Then the map has done its job by showing the cost. Make the capture short, attach it to an event the team already performs, such as closing out a meeting, and make the AI step depend on it. When the follow up waits for the capture, the capture stops being optional paperwork.

Can AI pull the moments out of call transcripts instead?

It can help, and that is one way to promote a buried moment. Treat the extraction as its own step with its own check, and make the downstream step wait for it. Extraction cannot recover moments that never reached any system.

If your AI steps keep acting on an outdated picture of the deal and you cannot tell whether the restriction is capture, triggers, or ownership, a Lorde GTM diagnosis traces where buyer moments stop reaching the system.

A IA só enxerga o que chega ao registro, então mapeie os momentos do comprador

Uma etapa de IA no processo comercial só consegue agir sobre o que já chegou aos dados que ela lê no instante em que roda. Se o comprador disse algo que muda a próxima ação certa, e esse fato ainda não chegou lá, a etapa vai agir sobre a negociação de ontem. Prompt melhor não resolve isso. O que resolve é o fato chegar a tempo.

O modo de falha é agir à frente do registro. O follow up sai na manhã seguinte à reunião porque um relógio mandou. O estágio mudou, então a etapa de proposta disparou. Enquanto isso, o momento que deveria ter mudado a ação, uma pessoa nova na decisão ou uma exigência nova, está parado numa transcrição, numa caixa de entrada ou na cabeça do vendedor. Nada no CRM está errado. Ele só está atrasado.

A nota sobre a camada de Verdade trata do que uma afirmação comercial precisa carregar depois que já existe no registro. Esta nota trata do passo anterior: momentos do comprador que não viram registro a tempo para o sistema que depende deles.

Definição

Definição: O mapa de chegada dos momentos do comprador lista, para uma etapa de IA, os momentos da negociação que mudariam a ação dessa etapa, e registra quando cada momento aconteceu, quando chegou aos dados que a etapa lê e, se chegou a outro lugar, onde ficou.

Momento do comprador é um acontecimento na negociação que muda qual é o próximo passo certo. Exemplos comuns: uma pessoa nova entra na decisão, o comprador traz uma exigência nova, o prazo muda, aparece uma alternativa concorrente ou o comprador assume um compromisso. Momento não é campo. Campo é só o lugar onde o momento talvez acabe anotado.

Por que um CRM bem cuidado ainda pode estar atrasado

O framework de qualidade de dados do governo britânico trata a atualidade do dado como uma dimensão própria de qualidade. O dado é atual quando o intervalo entre a coleta e a disponibilidade combina com o uso pretendido. Um fato correto que chega depois que a etapa que precisava dele já rodou falha para essa etapa, mesmo sem nenhuma imprecisão. O mesmo framework recomenda tratar o problema na origem, onde o dado é coletado.

A Gartner aponta algo parecido sobre IA: o dado precisa representar o caso de uso específico, e a prontidão inclui o fluxo que alimenta os sistemas em produção, como prática contínua e não como projeto pontual. Numa equipe comercial, esse fluxo é tudo o que a etapa de IA lê quando dispara.

Muitas etapas de IA no comercial são fluxos de trabalho, não agentes soltos. A Anthropic descreve fluxos de trabalho como sistemas que seguem caminhos definidos em código. Seja fluxo, seja agente, alguma coisa dá início à etapa, e o que dá início é uma escolha de desenho. Um temporizador, uma mudança de estágio ou um registro novo são opções, e cada uma decide quanto a etapa pode andar à frente do registro.

Marque onde cada momento chegou

Percorra a linha do tempo do comprador em algumas negociações recentes, usando as fontes que a equipe já tem: e-mails, anotações, transcrições, convites de agenda. Para cada momento que teria mudado a ação da etapa, marque um de quatro resultados:

• A tempo. O momento entrou nos dados que a etapa lê antes de ela rodar.
• Atrasado. Entrou nesses dados, mas só depois que a etapa já tinha agido.
• Enterrado. Foi registrado, mas num lugar que a etapa não lê, como uma transcrição, uma caixa de e-mail compartilhada ou o link de um documento.
• Perdido. Nunca entrou em sistema nenhum. Ficou numa conversa ou na memória de alguém.

Cada resultado pede um conserto diferente, e é por isso que vale desenhar o mapa:

• Perdido pede um dever de registro no Playbook: quem anota o momento, em que formato e antes de quê.
• Atrasado pede um novo gatilho na Arquitetura: a etapa começa quando o momento é registrado, não quando um prazo vence. Se o atraso vem do próprio registro, o momento também precisa de um dever de registro.
• Enterrado pede um conserto de Verdade: incluir aquela fonte nos dados que a etapa lê, com uma etapa explícita de extração, ou trazer o fato para um campo que a etapa lê no momento do registro.
• A tempo não pede nada, só um Operador que percorra as próximas linhas do tempo e perceba quando isso deixar de ser verdade.

Exemplo: a revisão de segurança na reunião

Uma equipe usa uma etapa de IA que escreve e envia um e-mail de próximos passos na manhã seguinte a cada reunião com o comprador. Ela lê o estágio, o campo de próximo passo e o campo de anotações que o vendedor preenche no CRM depois da reunião. A transcrição fica guardada, mas a etapa não a lê.

Na reunião, o responsável de TI do comprador avisa que qualquer fornecedor precisa passar por uma revisão de segurança antes do contrato. O vendedor ouve, e a fala fica na transcrição. Ele pretende atualizar o CRM na revisão semanal de pipeline.

Na manhã seguinte, a etapa de IA lê um registro que ainda diz contrato enviado e escreve uma cobrança simpática pela assinatura. O comprador recebe o e-mail depois de ter dito com todas as letras que a assinatura está travada. A capacidade comercial se perde duas vezes: na confiança do comprador e no trabalho do vendedor para recuperar a conversa.

O mapa dessa etapa mostra um momento, uma exigência nova, que aconteceu na reunião, ficou enterrado na transcrição no mesmo dia e só chegou aos dados que a etapa lê dias depois. Atrasado e enterrado ao mesmo tempo.

O conserto tem três partes:

1. Playbook: exigência nova ou pessoa nova na decisão é um momento que o dono da oportunidade registra antes de encerrar a reunião no sistema.

2. Arquitetura: a etapa de follow up deixa de disparar na manhã seguinte. Ela dispara quando o registro pós-reunião é concluído, e o formulário pergunta diretamente se apareceu exigência nova ou pessoa nova.

3. Verdade: a exigência vira um campo que a etapa lê, e o rascunho passa a propor a revisão de segurança como próximo passo, em vez da assinatura.

Regra de decisão

Se um momento do comprador pode mudar o que uma etapa de IA faz, essa etapa precisa ser disparada pelo evento de registro que capturaria esse momento, como o encerramento da reunião no sistema, e não por um temporizador ou por uma mudança de estágio. Se esse registro estiver atrasado, a etapa devolve a oportunidade ao dono em vez de enviar. Enquanto esse gatilho não existir, uma pessoa revisa o que a etapa produz antes de chegar ao comprador.

Momentos que surgem entre reuniões, como um e-mail do comprador citando uma alternativa concorrente, precisam do seu próprio evento de registro antes que a etapa possa contar com eles.

Ordene os consertos pelo que o mapa mostrar. Primeiro os momentos perdidos, porque nada adiante consegue enxergá-los. Depois os atrasados, mudando o gatilho. Por fim, os enterrados, trazendo o fato para os dados que a etapa lê.

Checklist

• Uma etapa de IA nomeada, com o que a dispara hoje.
• Os momentos que mudariam a ação dela, escritos em linguagem simples.
• Algumas linhas do tempo recentes percorridas com as fontes que já existem.
• Cada momento marcado como a tempo, atrasado, enterrado ou perdido.
• Um dever de registro definido para cada momento perdido.
• O gatilho da etapa trocado de temporizador ou mudança de estágio para o evento de registro, onde os momentos chegam atrasados.
• Fatos enterrados trazidos para campos que a etapa lê.
• As próximas linhas do tempo percorridas depois da mudança, por um responsável com nome.

O que isto não é

Não é um pedido para registrar tudo. Só entram no mapa os momentos que mudam a ação de uma etapa específica.

Não é promessa de que a resposta da IA vai acertar. Remove um tipo de erro: agir antes que o momento mais recente do comprador tenha chegado.

Não é motivo para abandonar temporizadores em todo lugar. Um temporizador serve bem para uma etapa cuja ação nenhum momento do comprador consegue mudar.

Perguntas frequentes

Quais momentos entram no mapa?

Só os que mudariam a ação da etapa que você está mapeando. Para uma etapa de follow up, isso costuma incluir pessoas novas, exigências novas, mudanças de prazo, alternativas concorrentes e compromissos. Um momento que não muda nada nessa etapa pode esperar outro mapa.

E se a equipe não registrar os momentos na hora?

Então o mapa já cumpriu seu papel ao mostrar o custo. Deixe o registro curto, prenda esse registro a algo que a equipe já faz, como encerrar a reunião no sistema, e faça a etapa de IA depender dele. Quando o follow up espera pelo registro, o registro deixa de ser burocracia opcional.

A IA pode tirar os momentos das transcrições das reuniões?

Pode ajudar, e esse é um jeito de resgatar um momento enterrado. Trate a extração como uma etapa própria, com sua própria verificação, e faça a etapa seguinte esperar por ela. A extração não recupera momentos que nunca entraram em sistema nenhum.

Se as suas etapas de IA continuam agindo sobre uma versão velha da negociação e você não sabe dizer se a restrição está no registro, nos gatilhos ou na responsabilidade, um diagnóstico de GTM da Lorde mostra onde os momentos do comprador deixam de chegar ao sistema.