Pipeline questions are a data audit in disguise
Moving a bank’s data estate to the cloud exposed gaps that had been easy to overlook: fields people assumed were maintained, missing histories and definitions that varied between teams. I think about that work when an AI assistant is asked to explain a sales pipeline. Before trusting the explanation, I want to see whether the CRM actually preserves the changes the assistant is being asked to describe.
That is useful if you design for it. The first pipeline question should usually be retrospective: what changed between two snapshots, and which changes matter? It is easier to evaluate than a forecast because the movements can be inspected, and it tests whether CRM history supports the story the business expects.
Treat that exposure as a gift. Every gap the assistant reveals is a gap your forecast already had; the AI simply makes it impossible to ignore. The CIOs and CROs I respect most use early pipeline questions as a structured data quality review, with a named owner for each finding, rather than as a test the model either passes or fails. That framing keeps the pilot honest and gives sales operations a concrete improvement agenda instead of a vague sense that the data is messy.
Ask what changed before asking what will happen
Define the comparison period and the opportunity population. Decide whether new, reopened and re-dated opportunities and currency changes are included. A single net total hides several different events.
Ask sales operations for a known example, such as a large opportunity that slipped a quarter while several smaller deals advanced. The assistant should separate those movements rather than call every increase demand and every decrease a loss.
In the private banking and wealth management platforms I led, the same discipline applied to advisor pipelines. A new household relationship, a consolidation of existing assets and a rescheduled review meeting are different events. Treating them as one number misleads the people coaching advisors.
Inspect the fields behind the narrative
Stage, amount, close date and owner are the usual starting fields, but their meaning depends on how each team uses the CRM. Stage definitions drift across regions. Close dates are maintained unevenly. A narrative built on those fields should not imply more certainty than the records support.
Check for history. A current-state export shows today's stage, not when or why it changed. If the question needs a historical comparison, confirm the snapshots or change records exist. An assistant must not invent a transition because today differs from someone's memory.
Separate missing data from negative evidence. No recorded next step does not prove the account owner has no plan. It proves the source lacks one. That distinction matters when the analysis is used to coach a team or escalate an account.
Write questions that reveal the limits
Include questions that need clarification, such as which deals are at risk or how healthy the quarter is. Risk could mean a delayed close date, missing activity, a stalled stage or a subjective judgment. Ask the business owner to define it, because those are different analyses.
Use a duplicate account name or a reassigned opportunity to check that the assistant does not merge unrelated entities or credit work to the wrong owner. Identity and timing errors produce convincing explanations because the totals still look plausible.
Test access boundaries by region and team. Pipeline data is commercially sensitive even without personal identifiers. In the Claude deployments we run, permissions and data boundaries are fixed during design, and denied requests belong in the evaluation set alongside successful summaries. A conversational interface must never widen what a manager is entitled to see.
Turn findings into a better operating rhythm
Review data gaps with sales operations before adding more questions. Some need source fixes; others need clearer language in the response. If close dates are unreliable, the assistant should say so rather than present a precise forecast, and the business decides whether fixing the field is worth the effort.
Bring the results to the next pipeline review with a short data-improvement backlog: the fields that need attention, an owner for each correction and the questions the evidence currently supports. Keep the question, the answer and the reporting snapshot together under your retention policy so later reviewers can tell a missing field from a misread request.
Forecast accuracy and win rates need months of observation. The immediate test is simpler: can managers use the assisted explanation with less reconstruction and clearer source context? If they can, you have earned the right to ask harder questions.