Article
Where agents read bad CRM fields
An agent does not know which field your team stopped trusting two years ago. It reads them all with the same confidence. Here is where the bad ones usually hide, and the order we fix them in before anyone wires an assistant on top.
Most CRM problems are invisible to the people who work around them every day.
Sales knows the "Stage" field is only updated on Fridays. Ops knows "Last contacted" includes automated reminders. Finance knows the "Value" field was a guess at first quote and never revised. Everyone quietly corrects for it in their head.
An AI agent cannot do that. It has no memory of the workaround. It reads the field, takes it at face value, and gives you a confident answer built on the one number your team already learned to ignore.
That is why the first post in this series said fix the data before you add the agent. This one gets specific about where in the CRM the bad data usually sits.
Five places bad fields hide
1. Free-text fields doing a dropdown's job
"Status", "Source", or "Service type" typed by hand ends up with five spellings of the same thing. A person reads past it. An agent counts them as five different answers, so summaries, filters, and routing rules split in ways nobody intended.
2. Fields that stopped being maintained
Every CRM has a field someone added for one campaign or one manager and nobody updates any more. It still looks official. An agent has no way to know it is stale unless something tells it.
3. The same fact in two places
Phone number on the contact and on the company. Deal value in the CRM and in the invoicing tool. When they disagree, which one wins? If the answer lives in someone's head, the agent will pick one at random, or worse, blend them.
4. Automation that writes over people
A form integration, an email tool, or an old Zapier step updates a field after a person has corrected it. The record looks touched recently, so it looks trustworthy. It is not.
5. Notes carrying the real truth
The actual status of a job is often in a free-text note: "waiting on council", "paid cash, don't chase". If structured fields say one thing and the notes say another, an agent reading only the fields is reading the wrong story.
Why agents make this worse, not better
A dashboard with a bad field shows a strange number, and someone eventually asks about it.
An agent with a bad field writes a fluent paragraph, drafts a follow-up email, or moves a deal to the next stage. The error is wrapped in good sentences, so it is harder to spot and it travels further before anyone catches it.
That is not a reason to avoid agents. It is a reason to decide, field by field, what an agent is allowed to read and act on.
The order we fix it in
This is the same order as our Data Intelligence work, applied to the CRM specifically:
- List the fields an agent would read. Not the whole CRM. Just the ones that feed the question or task you want automated.
- Name an owner and a source of truth for each. One field, one owner, one system that wins when two disagree.
- Retire or hide what nobody maintains. If a field is not owned, the agent should not see it.
- Lock the fields that drive actions. Dropdowns over free text, validation over hope, and an audit trail on who or what changed a value.
- Then add the agent, with a human in the loop. It drafts and suggests. People still approve anything that goes to a customer or moves money.
None of this needs a new platform. Most of the time it is cleaning up the system you already pay for, and connecting it properly to the tools around it. If the CRM itself is the problem, that is where CRM design and development comes in, and the AI automation layer goes on after.
Next step
If you are about to put an assistant on your CRM and you are not sure which fields it should trust, start there.
We look at the fields an agent would actually read, name the ones that drift, and only then talk about automation.
Amir
Alphesda Interactive