If you've ever built or administered a CRM, you've probably seen the dashboard that looks great for two weeks and quietly turns into fiction by week three. The usual diagnosis is people: the reps won't log their calls, ops forgets to move the deal stage, marketing assumes someone else will enter the lead.
I think that diagnosis is wrong, and it leads teams to the wrong fix. The data dies because of where the system sits, not because of who uses it.
I'm Justin Pennington, founder of Infraxio, based in Ponte Vedra in St. Johns County, Florida. We build operations software for mid-size businesses and run our own company on it. This is a builder-oriented rewrite of an essay on my site, Nobody Lives in the CRM. More about me and what we're building: infraxio.com/justin-pennington.
The tab test
Watch what someone on an operations team actually has open at 9 AM on a Monday: chat, email, maybe a project board. The CRM is one tab away, and that tab may as well not exist.
When a prospect replies, the instinct is to answer in the thread where the conversation is happening and move on. Updating a record is a second action that happens later, if at all. Humans are very good at deleting second actions from their day, and they're right to be. It's overhead that helps someone else run a report.
So the question I ask when reviewing any internal system is simple: is this tool on the path of the work, or next to it? Tools on the path get adopted without a mandate. Tools next to the path need enforcement forever.
Enforcement is a symptom
The standard response to a dying CRM is a stack of enforcement mechanisms:
- Required fields that block saving a contact until twelve boxes are filled
- Weekly pipeline reviews where the manager asks why nothing was updated
- Automated nag emails from the admin
- A quarterly "data cleanup day"
Every one of these produces compliance, not adoption. You get data that's late, minimal, and grudging. If you're the engineer asked to add yet another validation rule, that's a signal the architecture is wrong, not that the validation is missing.
Re-entry is where data quality goes to die
From a systems point of view, the bigger problem isn't motivation. It's that the CRM is downstream of several other systems and depends on humans to copy data between them.
Every manual hop is a lossy transform:
| Hop | What typically gets lost |
|---|---|
| Campaign tool to CRM | Source, engagement history, score |
| CRM to project tool | Scope notes, promised dates |
| Project tool to invoicing | Completed milestones, billable time |
| Inbox to CRM | The actual conversation |
A transposed phone number here, an abbreviated company name there, an optional "lead source" field left blank because the rep was in a hurry. Multiply by every lead, every week, and within a month nobody trusts the data. Once nobody trusts it, nobody updates it. That feedback loop is the week-three cliff.
The design principle: state transitions create the records
The fix I keep coming back to is architectural. Put the relationship data inside the workspace where the work happens, and let the records get written as a byproduct of people moving work forward.
Concretely, that means designing around transitions people already perform, not forms they're asked to fill in:
- A lead qualifies. It should arrive in the workspace with its context attached: which campaign sourced it, what it engaged with, how it scored. Nobody retypes it.
- A deal closes. The delivery tasks should be generated in the same workspace, linked to the same client record.
- A milestone completes. The billing data should already be there, because the work and the time were tracked in the same place.
Each step is something the operator was going to do anyway. The data trail is a consequence, not a separate job.
This is the pattern we built IFX Hub around: the deal, tasks, client updates, time entries, and invoices live in one operational workspace rather than three tools wired together. Upstream, Growth7 handles outbound campaigns, lead scoring, and qualification, and routes qualified leads into that workspace with their history intact. I'm biased, obviously. But the principle holds whatever stack you use, including a homegrown one.
A checklist if you're building or picking one
If you're designing an internal ops tool, or evaluating one for your company, these are the questions I'd ask:
- Does work happen inside it? If tasks, client communication tracking, and billing live elsewhere, the record will always lag.
- Does data enter exactly once? Count the places a client's name gets typed. More than one is a bug.
- Is the first screen useful to the person doing the work? Not the VP. The coordinator opening it at 7 AM. If the landing page is a pipeline chart they don't care about, they'll close it.
- Are reports derived or demanded? Forecasts and client health should fall out of real activity, not be assembled by someone filling in fields for a meeting.
Why the industry keeps shipping the side-trip CRM
Most CRMs are optimized for the person who buys the software, usually a sales leader or CEO who wants pipeline visibility, rather than the person who uses it all day. That's why they demo well in a conference room and stall in the field.
I see it constantly with service businesses and contractors across Northeast Florida, from Ponte Vedra to downtown Jacksonville. These are sharp operators. They bought a well-known CRM, did the implementation, did the training. Six months later the most reliable pipeline source is a text thread between the founder and the sales lead.
That's not a discipline problem. It's a design problem, and design problems are the kind engineers can actually fix.
So before you add another required field, ask the better question: where does this team already spend its day, and can the CRM function live there instead?
Originally published on penningtonj.com. I'm Justin Pennington, founder of Infraxio in Ponte Vedra, Florida. More writing at penningtonj.com.
What's the worst "required field" you've ever been asked to add to keep a CRM alive? I'd like to hear it in the comments.
Top comments (0)