By KYN AI Advisory Team — AI implementation specialists, Singapore
Conversation drift is a discovery call that quietly changes subject while the deal keeps its original qualification. The rep follows the prospect's new problem, which is good listening, and nobody re-tests whether the first thesis still holds. A design that catches it has three parts: a flag at the moment new information appears, a rule to ask rather than assume, and a check capped at a few exchanges. This is a design pattern, not a shipped product feature, and it needs testing on your own call transcripts.
What is conversation drift?
Every qualification framework, whether BANT, MEDDIC or SPICED, starts with a thesis: this prospect has this problem, this budget, this timeline and this authority. The thesis is often written in the first ten minutes.
Prospects then change it. They name a different bottleneck from the one that triggered the outbound message. They bring in a stakeholder whose priorities differ. They reframe the problem. The rep stays helpful and moves with them.
The call was not bad. The deal's qualification status no longer describes the conversation that took place.
Why do qualification frameworks miss it?
They are applied once, at the top of a call or a pipeline stage. Four things keep the gap open:
- The rep's attention is on the live conversation, not on auditing opening assumptions.
- CRM fields are updated after the call from memory, which tends to match the notes to whatever the rep already concluded.
- No alert fires when a prospect raises something outside the thesis.
- Manager reviews happen after the fact, on a sample of calls.
Fact: we hold no transcript data on how often drift occurs or how it affects win rate. Do not assume a number. Measure it on your own calls first.
Real-time flag or post-call review?
Post-call review is the default. By the time a manager reads the summary, the rep has made a dozen decisions on a thesis that may have lapsed.
A real-time flag is a different design. The precedent is not sales software. It is how multi-agent systems correct themselves. In a content pipeline built as planner, researcher, writer and reviewer, a conditional edge sends work back to revision the moment the reviewer finds a problem, instead of publishing and fixing later. A discovery call needs the same branch: when new information falls outside the thesis, route to a check.
What does an ask-first rule look like on a call?
Reconciliation agents match bank lines to invoices. Their rule is that a false match is worse than an open item, so uncertain matches go to a person. Apply the same bias to qualification:
- When the prospect raises a problem, stakeholder or constraint outside the thesis, flag it. Do not let the deal stay "qualified" by default.
- The flag does not kill the deal or force a script change. It raises an open question for the rep or manager.
- The default state is uncertain until someone confirms, revises or rejects the thesis.
The cost of a false "still qualified" is a month of selling to the wrong problem. The cost of the question is thirty seconds.
How do you keep the check fast?
A flag that never resolves is noise. Borrow two ideas from the review loop in a content pipeline.
- Name the mismatch. "The new stakeholder does not match the original buyer role" is useful. "Deal may be off track" is not.
- Cap the exchanges. Resolve in a small fixed number of steps: thesis confirmed, thesis revised, or thesis marked uncertain. An open-ended review during a live call becomes its own distraction.
What would the checkpoint look like end to end?
| Step | Trigger | Output | |---|---|---| | Listen | A new problem, role or constraint enters the transcript | A candidate flag | | Compare | Match against the stored thesis fields | A named mismatch or no flag | | Ask | Mismatch found | One question for the rep to put to the prospect | | Resolve | Prospect answers | Thesis confirmed, revised or uncertain, written to the CRM with time and actor | | Escalate | Still uncertain after the cap | A named manager reviews the deal |
The agent only suggests and records. The rep decides what to say, and a person decides whether the deal stays in the pipeline.
How would you validate it?
Do not trust it by analogy. Test it.
- Collect a sample of real discovery transcripts, with consent from the people recorded.
- Label where each thesis was introduced, held or abandoned.
- Measure how often drift occurs and whether it tracks with longer cycles or lower win rates.
- Run the flag on recorded calls and check how many flags were right. A flag that is wrong too often trains reps to ignore it.
- Compare flagged-and-resolved deals with a control group.
Recording calls and storing transcripts is personal data processing. Check the rules for the country of the participants before you start.
What does a stored thesis contain?
A flag can only compare against something written down. The thesis needs to be a small set of fields, filled at the end of the first call or on the qualification form, not a paragraph of notes.
| Field | Example (illustrative) | Drift signal | |---|---|---| | Problem | Month-end close takes too long | Prospect now talks mainly about payroll errors | | Buyer role | Finance manager | A sales director joins and sets the agenda | | Trigger | New auditor requirement | Prospect says the audit is no longer the reason | | Constraint | Must stay on current accounting software | Prospect is open to replacing it | | Timeline | Live before year end | Prospect mentions next financial year | | Budget owner | Finance director | "I will need to check with the owner" |
Six fields keep the comparison honest. More fields produce more flags and more noise.
What are the types of drift?
The same mechanism covers four different shifts. Each needs a different question.
- Problem drift. The pain the prospect names is not the pain you qualified. Ask: "Earlier you said close takes too long. Is payroll now the bigger issue?"
- Stakeholder drift. A new person with different priorities joins. Ask: "Who else decides on this, and what would they want to see?"
- Constraint drift. A rule you assumed fixed, such as keeping the current software, is now negotiable or newly strict. Ask which one it is.
- Timeline drift. The date moves, often quietly. Ask what changed.
Naming the type in the flag tells the rep which question to put, so the check stays under a minute.
A worked example
This example is illustrative. The company and the call are invented.
A rep qualifies a logistics firm on a thesis of "slow invoice matching, finance manager, live before year end". Twenty minutes into the call, the prospect says the real trouble is that drivers submit delivery proofs late, so invoices cannot be raised. A sales director joins and asks about reporting by customer.
The checkpoint produces two flags:
- Problem drift: invoice matching is no longer the stated bottleneck; delivery proof is.
- Stakeholder drift: a sales director now sets the agenda.
The agent suggests one question for each. The rep asks them. The prospect confirms that delivery proof is the larger issue and that the finance manager still signs. The rep revises the thesis: problem changed, buyer unchanged. The record shows who revised it and when. Without the flag, the proposal would have gone out for invoice matching, a problem the prospect had already moved past.
What goes wrong with this pattern?
- Too many flags. If every new topic raises a flag, reps stop reading them. Start with the two or three fields that most change a quote, and add more only after the first set is trusted.
- Wrong comparison. A model may read a polite aside as a change of subject. Count flags that the rep dismisses as wrong. If more than a small fraction are dismissed, tighten the trigger.
- Rep distrust. If reps think the flag is a way to monitor them, they will avoid recording calls. Say plainly that the flag checks the deal, not the person.
- Stale thesis. If the thesis was never written down, there is nothing to compare. The first fix is a better first-call form, before any agent.
- Late transcripts. A transcript that arrives ten minutes after the call is a post-call tool, not a real-time one. Pick the version you can support.
What should you measure?
Set these before the pilot so you can tell whether it helped.
- Flags raised per 10 calls.
- Share of flags the rep marked correct.
- Share of flagged deals where the thesis was revised.
- Days from first call to proposal, for flagged and unflagged deals.
- Proposals that were rejected as "not what we asked for".
Use your own baseline. A vendor figure from another company says little about your calls.
Where KYN fits
KYN builds sales agents on cloud infrastructure in the client's own account. Agents have their own restricted accounts, every action is logged with the actor, and outbound messages and CRM deletions wait for a named person. For an insurance brokerage, we built a reply desk that sorts replies at about S$0.01 each. Live-call flagging has not been built by KYN; the nearest working piece is context-aware drafting from full conversation history.
The first 14 days are a review of your stack and interviews with the team. A full build ships in under 90 days. See sales systems and security.
Frequently asked questions
Is conversation drift the same as going off script?
No. Going off script is a style issue. Drift is a qualification issue: the facts that justified the deal no longer match what the prospect is saying.
Should the AI interrupt the rep during the call?
Probably not. A quiet prompt to the rep, with one named question, is less disruptive than an interruption. Test this with reps before choosing.
Does this need a recorded call?
A flag needs a live or near-live transcript. A post-call version works on a recording and still helps by writing the thesis check into the CRM before the next stage.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
