Revenue Engineering

CRM Data Quality Checklist Before You Automate

Twelve checks to run on your CRM before automating anything on top of it, why each one breaks automation downstream, and the order to fix them in.

Mauricio Esparza By ·Published ·3 min read
mithub.club
Short answer

Before automating on a CRM, check twelve things: duplicate records, field meaning drift, empty required fields, inconsistent phone and email formats, stage definitions nobody agrees on, ownership gaps, dead contact details, records with no source, free text where a picklist belongs, timestamps that are missing or wrong, permissions, and whether a second person would read the record the same way you do. Every one of them turns into an automation failure downstream, usually a silent one.

Automation does not fix bad data. It applies bad data faster, at scale, with an audit trail. Run these before building anything on top of your CRM.

The twelve checks

1. Duplicates. Exact matching finds the easy ones. The expensive ones are near duplicates: the same company with and without a suffix, the same person at two email addresses.

2. Field meaning drift. Ask three people what a field contains. If you get three answers, every automation reading it is guessing.

3. Required fields that are empty. Required in the schema, empty in practice, because someone found a way around the form.

4. Format consistency. Phone numbers with and without country codes. Emails with trailing spaces. Automations match exactly. Humans do not notice.

5. Stage definitions. What has to be true to move from this stage to the next. If nobody can say, your pipeline reporting is describing something other than reality.

6. Ownership gaps. Records with no owner do not get worked and do not appear in anyone's list. They accumulate quietly.

7. Dead contact details. Numbers and addresses older than the records holding them. A dial on a wrong number costs exactly what a dial on a right one costs.

8. Records with no source. The most damaging item here, because it fails silently. Without a source you cannot walk backwards from revenue, so you cannot decide what to stop paying for.

9. Free text where a picklist belongs. Fourteen spellings of the same outcome cannot be counted or branched on.

10. Timestamps. Missing or wrong created and modified times break every speed metric, including the one that usually matters most.

11. Permissions. The automation needs to write to the fields it is responsible for. Discovering this at launch costs a week.

12. The second reader test. Give a record to someone who was not on the call. Can they say what happened and what is next? If not, no automation built on it will produce a useful handoff either.

The order to fix them in

  1. Source and timestamps first, because they are unrecoverable later. Every record from today forward should carry both.
  2. Stage definitions, because everything branches on them and a change cascades into several automations at once.
  3. Formats and duplicates, which are mechanical and can be scripted.
  4. Dead contact details, routed into their own path rather than deleted, so they get researched instead of dialled.
  5. Free text to picklists, last, because it needs the previous four to be stable.

What not to do

Do not attempt a full cleanup before any automation ships. These projects die of scope, and the cleanup rots again while you finish it.

Fix what your first automation touches, route everything unusable into a flagged path, and make the automation normalise formats rather than invent missing values. An automation that guesses produces confident errors, and confident errors are far harder to detect than empty fields.

The definition of done

After the cleanup, open a record at random. You should be able to say where it came from, when, who owns it, what was said to it and what happens next. If you can, automation on top of it will behave. If you cannot, it will not, no matter how good the tooling is.

If you want someone to run this with you

MitHub publishes open profiles of engineers who have done this inside real revenue systems, with the work written out.

See the talent.

Frequently asked questions

Do we have to fix everything before automating?

No. Fix what the first automation touches, and route the rest into a path that flags it rather than processing it. A full cleanup before any automation is how these projects die of scope.

What is the single most damaging problem?

Records with no source. Everything else produces visible errors. A missing source produces a silent inability to attribute revenue later, which you only discover when someone asks which spending to cut.

Should the automation clean the data?

It should normalise formats and flag what is unusable, not invent values. An automation that guesses at missing data creates confident errors that are much harder to detect than empty fields.

How often should this be rerun?

Quarterly as a habit, and always before adding a new channel or a new location. Data quality decays at the speed the business changes around it.

Sources

  1. Handle errors gracefully · n8n Docs (accessed 2026-09-22)
  2. Why evaluate AI workflows · n8n Docs (accessed 2026-09-22)
Revenue EngineeringCRMData Quality
Mauricio Esparza
Mauricio EsparzaGTM Systems Lead · Revenue Engineer · Founder of MitHub. Designs and runs revenue systems for multi-location businesses: AI voice campaigns, enrichment, CRM automation and attribution. Founded MitHub to teach the method in the open.

Part of Revenue Engineering on MitHub.

Keep going