Every RevOps conversation eventually arrives at the same complaint: the CRM data is bad. Deals sit in the wrong stage. Contact records haven't been touched in months. Activity logging is sporadic at best, absent at worst. Leadership can't trust the pipeline report because the pipeline report doesn't reflect reality.

The standard diagnosis is a people problem. Sales reps aren't disciplined enough. They need better training. They need to be held accountable. So the company runs another CRM training session, adds some mandatory fields, and threatens consequences for non-compliance.

Six months later, the data is still bad.

The problem was never adoption. The problem is that the CRM was built to extract value from salespeople, not to give value back to them.

"A CRM that creates work without returning value will always be ignored. That's not a character flaw — it's a rational response."

The Broken Value Exchange

Every tool a salesperson uses survives or dies on a simple equation: does using this thing make my job easier, or harder? Email clients survive because they're the medium itself. Dialers survive because they eliminate friction. Slack survives because it replaces slower communication.

Most CRMs fail this test for the average rep. Logging a call takes longer than making the next one. Updating a deal stage requires navigating three screens. Adding a contact means filling in eight required fields before you can save. None of these actions make the next sale more likely — they just create data that someone else will use in a report the rep will never see.

The value exchange is broken. The rep does the work. Management gets the insight. The rep gets nothing except compliance reminders.

The core question

Before adding any field, workflow, or requirement to your CRM, ask: who benefits from this data, and does the person entering it get anything in return? If the answer is "only management benefits," expect the field to be empty within 90 days.

What Sales Reps Actually Need From a CRM

When you ask salespeople what they need — not what they should need, but what would actually make their day better — the list is short and consistent:

Most CRM implementations deliver none of these things. They deliver fields, stages, and mandatory inputs designed entirely around reporting needs.

The field proliferation problem. Every stakeholder who touches a CRM implementation wants their data. Marketing wants lead source. Finance wants contract value broken down by product line. Customer success wants implementation date. Legal wants contract type. Each request is individually reasonable. Collectively, they produce a contact record with 40+ fields that a rep is expected to maintain across a portfolio of active deals.

Nobody maintains 40 fields. They maintain the ones that are required to save the record, and they fill in the rest with whatever gets the red asterisk to go away.

How to Reverse the Value Exchange

Fixing a broken CRM isn't a training problem or a data quality project. It's a product design problem. You're building an internal tool, and internal tools need to be designed with the same user-centricity as external ones.

The framework I use starts with one question: what would make a rep open this record voluntarily, without being asked? If you can't answer that, you don't have a CRM — you have a compliance system with a database attached.

The redesign sequence

1. Audit what's actually used. Pull field completion rates. Any field below 60% completion is either irrelevant or too burdensome — kill it or automate it.

2. Automate the logging. Call logging, email capture, meeting notes — if your stack can capture it automatically, it should. Every manual entry you eliminate is trust restored.

3. Build rep-facing views first. A rep's pipeline view, their activity summary, their deal velocity — these exist to help them sell. Build these before you build the management dashboard.

4. Add fields in exchange for value. If you need a new field, pair it with something that benefits the rep. Add "decision maker identified?" and surface a sequence trigger when they mark yes.

Where Automation Changes Everything

The biggest shift in CRM usability in the last three years is the quality of native integrations and automation tooling. What used to require a developer — automatic activity logging, deal stage triggers, enrichment on contact creation — can now be configured in an afternoon with n8n, Zapier, or native HubSpot workflows.

In my own setup across multiple brands, I've eliminated the manual logging of calls, emails, and meetings almost entirely. When a rep books a meeting via Calendly, the contact is created or updated in HubSpot automatically. When a deal moves to proposal, a task is created and the rep gets a Slack notification with context. When a contact hasn't been touched in 21 days, the assigned rep gets a reminder with the last activity summary.

None of this required the reps to do anything differently. The system now works with their existing behaviour rather than demanding new behaviour.

The Data Quality Payoff

When you reduce manual burden and return value to the people entering data, something predictable happens: the data gets better. Not because you enforced it — because people are actually using the system.

A rep who opens their CRM to check context before a call will notice when something is wrong and fix it. A rep who sees their own activity metrics in a dashboard will care whether those metrics are accurate. A rep who gets a useful automation triggered by a deal stage update will start updating deal stages.

The compliance problem solves itself when the tool is worth using. That's the only sustainable version of CRM adoption.

"The best CRM audit you can run is watching a rep use it for 20 minutes without intervening. Everything they avoid telling you."

Before You Rebuild, Do This First

If your CRM data is bad, resist the urge to start a data cleanup project. Clean data in a broken system will be dirty again within a quarter. Fix the system first.

None of this is technically complex. It's mostly subtraction — removing what doesn't serve the people who have to use the system every day. That's harder than it sounds, because it requires stakeholders to give up data they think they need. But it's the only way to build a CRM that people actually use.