Why CRMs rot
Almost every rotten CRM got there the same way. Not neglect, but well-intentioned over-capture at the start.
Someone sets it up, adds thirty fields because each one might be useful for reporting later, and the team dutifully fills them in for a month. Then a busy week arrives and the optional fields get skipped. Then the required ones get filled with placeholder values so the form will save. Six months later the database is 60% populated, nobody trusts a report generated from it, and a spreadsheet has quietly reappeared beside it.
The underlying rule
A field gets filled reliably only when someone needs it to do the next thing. Fields that exist for a report nobody reads will be empty within two months, and half-empty fields make the whole record untrustworthy.
The 12 rules
One owner per record, always a person
Not a team, not a shared queue. A named human who is accountable for that record being accurate.
Shared ownership of data means nobody notices when it goes stale, and it is the most common reason a pipeline drifts away from reality.
Never a teamEvery open deal has a dated next step
Two fields: what happens next, and when. Enforced, not encouraged.
This one rule does more for pipeline quality than any other. A deal with no dated next step is not being worked, whatever its stage says.
The highest-value rule hereFixed lists wherever you will want to count
Loss reason, lead source, industry, deal type. If you will ever want to group by it, it cannot be free text.
Free text is fine for context nobody will aggregate. It is useless for anything you will later want a number from.
Count it later, list it nowOne unique key, enforced on every route in
Usually email address. Every import, form, and integration matches on it before creating anything.
Duplicates are not a cleanup problem, they are a capture problem. Fixing the entry points is the only thing that stops them recurring.
Usually emailClose dead records, with a reason
A deal nobody has touched in 90 days is not open, it is clutter inflating your pipeline value.
Closing it lost with a reason is not admitting defeat. It is the only way the forecast means anything and the only way loss reasons accumulate into something you can learn from.
90 days, then decideSix required fields, no more
Contact, company, stage, value, next step, next step date. That is enough to run a business.
Every required field beyond this is a tax on every single update, paid by the people you least want doing admin.
Six is plentyStages describe the customer, not your activity
"Demo Done" records what you did. "Solution Agreed" records what they confirmed.
Activity-based stages always forecast optimistically, because activity is entirely within your control and buying is not.
Their confirmation, not your effortNotes record decisions, not narration
"Wants pricing for 12 seats before Friday, decides with the CFO" is worth keeping. "Good call, went well" is not.
The test: could a colleague pick this up cold and act on it? If not, the note has recorded that a call happened, which the activity log already knows.
Actionable, or leave it outNever let a second source of truth start
The moment a private spreadsheet appears, the CRM is downgraded to a reporting chore and the real data lives elsewhere.
When you find one, ask what the CRM could not do. It is usually a genuine gap, and fixing it is cheaper than fighting the spreadsheet.
Ask why it existsAutomate what people forget, not what they decide
Stale-deal flags, follow-up reminders, and duplicate checks are safe to automate. Stage changes are not.
Automating a judgement encodes a guess as a fact. Our guide to [what to automate first](/blog/what-to-automate-first) covers the line in more detail.
Flag, do not decideImport with a dry run, always
Map the columns, import ten rows, inspect them, then do the rest. Never import a thousand rows straight into a live database.
Bad imports are the single fastest way to destroy trust in a CRM, and they are almost impossible to unpick afterwards.
Ten rows firstReview the rules quarterly, in 20 minutes
Which fields are under 80% filled? Which have never been used in a report? Delete them.
Removing a field is the cheapest quality improvement available, and it is the one nobody ever schedules.
Delete more than you add
Which fields to keep
| Keep | Reason | Cut |
|---|---|---|
| Owner | Accountability for accuracy | Secondary owner |
| Stage | The core of any forecast | Per-deal probability percentage |
| Value | Prioritisation | Weighted value as a stored field |
| Next step and date | The forcing function | Free-text "status" |
| Decision maker | Who actually says yes | Full org chart |
| Loss reason, from a list | The only honest learning loop | Free-text loss notes |
| Source, from a short list | Where good deals come from | Nested source sub-categories |
The right-hand column is not useless information. It is information that will not be maintained, and a field that is 40% filled makes every report built on it misleading in a way an absent field does not.
Cleaning one that has already rotted
A weekend of deletion, not a quarter-long project.
Close everything untouched in 90 days. Bulk action, one reason code such as "no response". You are not deleting the contacts, only the fiction that these were live deals.
De-duplicate on email. Merge, keep the oldest created date, keep the most recent activity. Do this before anything else, because every other count is wrong while duplicates exist.
Delete fields under 80% filled unless a report actually uses them. Export first if you are nervous, then delete.
Re-stage what is left against real exit criteria. Expect this to be uncomfortable. Deals you believed were close will land in earlier stages, and the pipeline total will drop. That drop is the point: you are replacing a number nobody trusted with one you can plan against.
Write the rules down on one page and put them where new joiners will see them. A process that lives only in one person's head has the same problem as a spreadsheet. Our guide to documenting a process covers what that page needs.
The reason any of this matters is what happens downstream. A clean CRM makes the weekly pipeline review a 30-minute decision meeting instead of a data-correction session, and it makes a handover possible without a two-hour briefing. Kin enforces the validation and idempotency side of this, so repeated imports and agent actions cannot quietly create the duplicates you just spent a weekend removing.
Frequently asked questions
- How often should you clean a CRM?
- Continuously, through rules that prevent bad data, plus one quarterly sweep for duplicates and stale records. A CRM that needs an annual clean-up project has a capture problem, and the project will be needed again next year.
- What causes duplicate records?
- Imports without a matching key, two people entering the same contact from different sources, and integrations that create rather than match. Pick one field as the unique key, usually email address, and make every import and integration match on it.
- Should sales reps be responsible for CRM data quality?
- For their own records, yes, but only if updating is faster than the alternative. If the pipeline review, the forecast, and the handover all run off CRM data, updating becomes the shortcut. If people are asked for separate status updates as well, the CRM will always be second.
- How many fields should a CRM record have?
- As few as the next action requires. Six required fields on a deal is plenty for most small teams. Every additional required field is a tax on every update, and optional fields that are half-filled are worse than absent ones because they look like data.
- What is the most useful field most teams do not have?
- A loss reason chosen from a short fixed list. Filled in every time, it becomes the only honest record of why deals do not close. As free text it is worthless, because nobody can aggregate it.