The fields that lie: CRM data you should not trust

Some CRM fields are wrong in predictable ways, and the predictability is the useful part. A field that is randomly wrong is a data quality problem. A field that is wrong in the same direction every time is a design problem, and every metric built on it inherits the bias without anyone noticing.

The five below are the usual offenders. In each case the field is not wrong because people are careless. It is wrong because of what the field is being asked to do.

Close date

Close date is asked to be two incompatible things at once. Forecasting wants an honest prediction. Pipeline hygiene rules flag anything with a date in the past. So when the date passes and the deal has not closed, the fastest way to clear the warning is to push the date, and the field quietly becomes a record of when someone last cleared an alert.

The tell is clustering at period boundaries. If close dates pile up on the last day of the month or quarter far more than anywhere else, those are not predictions. A count of close dates by day of month shows the pattern in a few minutes.

What to build: count the pushes. A deal whose close date has moved three times is a different object from one that has never moved, and the push count is often a better risk signal than the date itself. If field history tracking is on for close date, the raw material already exists, and the count needs only a report.

Lead source

Lead source is usually captured once, at creation, then overwritten by whatever touched the record most recently, or set by whichever integration wrote last. It also tries to hold two different ideas: where the person came from originally, and what caused this particular opportunity. The result is that source-level conversion rates are comparing categories that do not mean the same thing. Any budget decision made from that comparison is guesswork wearing a percentage sign.

What to build: separate original source from most recent source, set the original once and make it immutable, and keep the raw capture data. A derived field you can recompute beats a field people can edit. When the attribution definition changes, recompute from the raw capture instead of asking anyone to correct history by hand.

Stage entry dates

Most CRMs store the current stage, not the history of stages, unless someone deliberately built the history. Velocity metrics get reconstructed after the fact from whatever history tracking happens to exist, which does not survive a stage being skipped, a deal moving backward, or a bulk update that touched a thousand records. Backward movement is the one that quietly breaks everything. Nearly every velocity calculation assumes deals move forward, and deals do not.

What to build: capture stage transitions as events when they happen, with a timestamp, and store them outside the record. Then duration is a fact you recorded rather than a number you inferred. A deal that moves backward adds one more event to the log instead of corrupting the calculation.

Next step

Next step is free text with no validation, filled in before a forecast call, and never cleared afterward. A stale next step from six weeks ago is indistinguishable from a current one, which makes the field worse than empty: empty is honest, stale looks like coverage. Sort open deals by when the next step was last edited, and the size of the problem is usually obvious.

What to build: derive it. A scheduled future meeting on the account is a next step. A dated task is a next step. Both are structured, both are verifiable, and neither depends on someone remembering to update a text box.

Anything a rep types under time pressure

Competitor, use case, pain, decision criteria. These fields are filled in at the end of the day before a pipeline review, and the honest description of most of their contents is that they were plausible when written. Their fill rate looks fine, which is exactly why they get trusted.

What to build: extract them from the conversation rather than asking for them. Call recordings and email threads already contain the answer, and a model reading the actual thread produces a better competitor field than a dropdown selected under deadline. Write it back with a confidence marker and the source, so a human can check it.

The test for any field

Ask two questions. Who fills this in, and what happens to them if it is wrong. If the answer is a rep, and nothing, the field is decorative and should not carry a metric.

Then ask whether the field is being used for two purposes. Fields with one job stay accurate. Fields that serve both a workflow rule and a report get optimized for the rule, because the rule is the one that nags.

What this means for AI on top of it

An agent reading these fields inherits every bias in them, and states the result with more confidence than a person would. Pointing a model at a close date field and asking it to forecast produces a well-written summary of a fiction. The order that works: fix what the system captures, derive what can be derived, and only then put a model on top. That sequence is also why data hygiene tends to be the first project rather than the third.

SYN.AUTON builds the capture and derivation layer before the AI layer, because the second one is worthless without the first. That means events for stage and close date changes, derived fields for source and next step, and extraction from calls and email for the rest. See AI Revenue Operations or tell us what you want to automate.