Your CRM Has Always Measured the Wrong Thing

For as long as I've worked with CRMs — and that's since 2012 — we've measured data quality by asking one question: is the field filled in?

It's the wrong question. And most businesses have never had the tools to ask a better one.

Think about how data quality actually gets measured in Salesforce. You check whether a field is null. You might count the characters with a formula. You build a dashboard that shows completeness as a percentage, turns a few charts green, and gets shown in a leadership meeting as evidence that the CRM is in good shape.

But completeness only ever told you the shape of the data. Never the substance.

The "NA" problem

I've seen the consequence of this more times than I can count. A field is set to required, so a sales rep types "NA" to get past it. The rule is satisfied. The character count is greater than zero. The dashboard ticks green. And the field is worthless.

The rule isn't clever. It can't be. It can only see whether something is there, not whether it's any good.

The black hole of text fields

It gets worse with the fields that matter most — the free-text ones. Call notes. Next steps. Account background. The places where the actual intelligence of a deal lives.

Salesforce itself makes these almost impossible to review at scale. Pull a long text or rich text field into a report and it's truncated to the first 255 characters. So even if you wanted to sit down and read your team's notes to judge whether they're any good, the tooling fights you. At any real volume, that data is effectively unreviewable.

So we ended up in a strange place. The most valuable information in the CRM — the human context around a relationship — was also the least measurable, the least consistent, and the most dependent on whichever individual happened to type it.

You could tell whether a field was full. You could never tell whether it was right.

What actually changed

This is where MCP and AI models come in — and I want to be precise about what each one does, because the distinction matters.

MCP, the Model Context Protocol, is a standard way of connecting an AI model to your systems. In plain terms: it's the pipe. It lets a model like Claude reach into Salesforce, or into my call recording tool, and work with what's there.

The old way of connecting systems was laborious. You mapped every field by hand, wrote the sync logic, built the deduplication rules, and most of it needed a developer. MCP replaces a lot of that bespoke plumbing with a standard connection.

But the pipe isn't the clever bit. The clever bit is what the model does once it's connected. Because a model can actually read a field. Not check whether it's blank — understand what's in it. And once something can understand the content, quality stops being a black box. It becomes something you can evaluate, improve, and enforce.

From checking boxes to checking substance

Here's what that looks like in practice, using my own work.

I run our consulting delivery in a Salesforce app we built. Every project task has to follow a standard structure — what, why, how, and then the technical detail. In the old world, "enforcing" that would have meant a validation rule that checks the field isn't empty. Useless, as we've established.

Instead, the rules live in plain English, in a skill the AI follows. A task must have a due date and an estimated effort — and if someone doesn't supply the effort, the model estimates it from the context. Notes get reshaped into the what/why/how format whether or not they were typed that way. If the input is poor, the model can push back, or draft a first version based on what it already knows about the record.

Notice what's different. The rules aren't code. I can change them by editing a sentence. I don't need a developer, it's quicker, and it's cheaper. You still test it — that doesn't change — but the cost of defining and adjusting what "good" looks like has collapsed.

Capturing quality at the source

The second shift is where the good data comes from in the first place.

I record my calls on Fathom. Through MCP, Claude can read those transcripts directly. So instead of finishing an hour-long call and rekeying the important bits into Salesforce from memory — badly, like everyone does — the model already has the full, rich context of what was actually said. It can update the record, ask me the questions it needs to fill the gaps, and put everything in the right format.

I'm not transcribing. I'm reviewing. The data going in is better because it came from the source, not from whatever I could be bothered to type afterwards.

The real prize: consistency across a team

Everything so far makes my data better. On its own, that's a productivity story.

The part that should interest anyone running a team is this: the same rules apply to everyone.

Right now, in most organisations, the quality of a record depends entirely on who wrote it. One rep writes thorough, structured notes. Another writes "good chat, keen." When that first rep reads their own notes back, they remember the conversation. But a manager reviewing the pipeline, or a colleague picking up the account after someone leaves, is stuck trying to decode one person's personal shorthand.

Apply a shared standard through AI, and everyone's updates land in the same readable format. Not because you've sent another email asking people to write better notes. Because the standard is the default.

That's the difference between hoping for good data and building it in.

Why this matters

None of this is about the technology being impressive. It's about trust.

A forecast is only as good as the data under it. A handover only works if the next person can understand what came before. Reporting is only worth looking at if it reflects substance rather than ticked boxes.

For years we've accepted that CRM data quality meant completeness, because completeness was all we could measure. That ceiling has lifted. The question is no longer "is the field filled in?" It's "is this actually good — and does it match what good looks like across the whole business?"

That's a question worth being able to answer.