CRM AI Readiness Assessment

Five questions your CRM cannot answer about itself.

The scan runs the detection half of every tool against your own records and reports what it finds. It writes nothing.

The gap this closes. Everyone suspects their CRM is bad. Almost nobody can say how bad, in what way, or whether it improved this quarter. Data quality stays a feeling rather than a number, so it never gets prioritised against anything that has one.

Before AI can be trusted with a CRM, somebody has to establish what is in it. Not a vendor benchmark, and not a maturity model with five tiers and a colour. The actual counts, from your actual records.

It reads and reports. Detection is the half of every tool that costs nothing and changes nothing: finding the duplicates rather than merging them, computing what a normalization pass would rewrite rather than rewriting it. The scan runs that half and stops.

It ends with a sequence, not a score. A number out of a hundred tells you how you are doing and not what to do. The scan finishes by proposing the runs that would fix what it found, in the order they have to happen.

Five questions, asked of your own data.

Each one is a real query against your records rather than a survey you fill in about yourself.

Duplicates

How many duplicate groups are actually in there, found by running detection with real matching rules. Not an estimate: the groups exist afterwards and you can open them.

Field coverage

Which fields are thin, by object. The ones your segments and scores silently depend on, and how much of the book is missing them.

Value consistency

How many records hold a value that is not canonical, measured by computing what a normalization pass would change without changing it.

Rule fitness

How the rules you already have actually perform against your data, rather than whether they exist.

Ideal customer

Whether your own closed deals contain enough signal to describe who you sell to. It fits the model from your won and lost history, and declines honestly when the history is too thin to say.

What it writes

Nothing. Detection touches no field, so there is nothing to approve and nothing to undo.

It hands you the sequence, not a grade.

The findings are the easy half. Knowing what to do about them in what order is the half that never gets done.

Order matters more than it looks. Normalizing before deduplicating changes what the matching rules can see, because five spellings of one city are five different records to a matcher. Enriching before deduplicating means paying a provider twice for the same company. A list of problems does not tell you that; a proposed sequence does.

So the scan finishes by composing the runs that address what it found, in an order that holds, each one scoped to the records the finding actually names. You read it, you change what you disagree with, and nothing is dispatched until you say so.

The second scan is the one that matters.

A single reading is a diagnosis. Two readings are a trend.

Every scan is kept as its own record rather than overwriting the last one, because the question people actually ask after acting on a finding is whether it worked. A latest-only number cannot answer that.

Which turns data quality into something a RevOps team can take to a QBR: eleven thousand duplicate groups in March, four hundred in June, on the same book, measured the same way.

Five questions your CRM cannot answer about itself.

Five questions, asked of your own data.

It hands you the sequence, not a grade.

The second scan is the one that matters.

What the scan is reading.

Run it against your own book.