Follow-Up Summaries and CRM Hygiene

The tempting setup is a clean loop: the call ends, AI summarizes it, extracts the next step and the budget number and the renewal date, and writes all of it straight into the CRM. Nobody retypes anything. The summary is usually good. The problem is the word "usually," because the CRM is not your scratchpad. It is the shared record every other seller, every forecast, every routing rule, and every renewal play reads from later, and they read it as fact. A wrong field you typed yourself is one person's mistake. A wrong field an AI wrote with full confidence is a mistake the whole institution now trusts.

This is why CRM hygiene stops being a tidiness chore the moment AI can write to it at volume. The same automation that de-dupes contacts and enriches stale records can just as easily flood the system with plausible-but-wrong values, and the downstream cost is asymmetric. Consider an enrichment step running at 85% field-level accuracy. That sounds like a strong tool until you sit with the other number: roughly one in seven rows is wrong, and nothing in the record tells you which ones. The 15% does not arrive flagged. It arrives looking exactly like the 85%, gets auto-actioned into a sequence or a forecast, and the next seller who opens that account inherits a confident wrong title, a decayed email, or a renewal date that was never said on the call. Bad auto-logged data does not announce itself. It compounds quietly, because every reader after the write assumes the write was checked.

The fix is not to keep AI away from the CRM. Drafting follow-ups and proposing field updates is exactly the mechanical work it should carry. The fix is to move the human review to before the write instead of after the damage, and to gate the write on confidence rather than trusting every extraction equally. A field the model is sure about — the meeting happened, the attendee's name as spoken — can write through. A field it inferred or half-heard — the deal value, the decision date, the competitor named in passing — drops below the threshold and routes to a human who confirms or corrects it in seconds. The same logic governs enrichment, which is why operators run it as a waterfall: query provider A, take the hit; on a miss fall through to B, then C, first valid result wins, because no single data source has good coverage and B2B contact data decays continuously as people change jobs. The waterfall is cheaper too — stacked providers run roughly $0.08 to $0.22 per enriched row against about $0.52 for a single premium source, a 6.5x penalty for pretending one provider is enough. But cost is the minor point. The real reason to stack and to re-fire enrichment on job-change and new-hire signals is that a CRM is a decaying asset, and the gate is what keeps the decay from being silently overwritten with confident garbage.

The gate only earns its keep where the cost of a wrong write is real and downstream readers actually exist. On a solo book where you are the only person who ever reads the record, the verification step is overhead — you already know what was said, and a heavy review queue just slows you down. Push the discipline up only as far as the blast radius justifies it. The opposite failure is more common and worse: a confidence threshold set so loose it gates nothing. If the model self-reports high confidence on everything, including the figures it half-heard, the gate becomes theater and the wrong rows write through exactly as before. Model-reported confidence is a weak signal here; it is calibrated to sound sure, not to be right. So the threshold has to be tuned against fields you can check against a second source, not trusted on the model's own say-so. And the gate guards the write, not the extraction. It catches a low-confidence value before it poisons the record, but a confidently-wrong high-confidence value — the renewal date the model heard clearly and got wrong anyway — sails through, which is why high-stakes fields like contract value or close date stay on human review regardless of what confidence the model reports.