In a 5-50 person business, the load-bearing data layer is usually a person, not a system. That person has a name. The team knows it. The CRM doesn’t.
The CRM looks empty for a reason
When the dashboard reads thin, most operators conclude the team isn’t disciplined about notes. The intake form has gaps. The status field is stale. Nobody updates the source channel.
That read isn’t wrong. It misses the deeper one.
The team isn’t writing things down because nothing forces them to. Someone already knows. The shop manager who can tell from a customer’s name which jobs are going to come back as callbacks. The senior tech who reads a job description and routes it to the right crew in five seconds. The office manager who hears “the website thing” and knows it means a referral from one specific partner from 2021.
That person is the data layer. The CRM sits downstream.
The system looks empty because the actual database isn’t a system. It’s a chair, occupied by one person, who answers operational questions faster and more reliably than any tool the business has bought in the last decade. The team built a routing pattern around that chair years ago. Nobody named it. Nobody documented it. The pattern just is.
Empty CRMs at this size aren’t usually a discipline problem. They’re a routing problem. The data exists. It got routed around the system before the system was even chosen.
He’s payroll until he’s a project
The cost stays invisible while he’s there. He fields routing questions. He spots exceptions before they hit production. He sends the right tech to the right job because he reads the customer’s name and knows what last winter looked like. The team’s day runs. The dashboard nobody trusts is irrelevant because his answers arrive faster than the dashboard could.
What’s being paid for, quietly, is operational infrastructure nobody named. A decade of institutional memory subsidized as a side effect of one salary. Invisible because nobody requested documentation. Fragile because the knowledge sits in one head, and there is exactly one of him.
Three events make the cost legible.
He takes two weeks off. The team makes plausible-looking calls all month. The customer who has always been on a 1.5x rate on Saturday work gets quoted standard and accepts. The relationship is twenty-two-hundred dollars lighter the next month, and the team didn’t know to flag it.
He gets recruited. The operator realizes the side benefit they treated as a payroll line is a single point of failure with a market price, and that market price is being negotiated.
The business tries to scale. A new hire arrives. The owner budgets two months of ramp. It runs eight. Every week of that overrun is full salary against half output, while the new person learns from the same person who was supposed to be back to building.
By the time the documentation project starts, it starts under deadline pressure with the institutional knowledge halfway out the door. The bill arrives all at once.
Three kinds of knowledge that hide in him
When I run the data-discipline pillar of the assessment, I’m not looking for empty fields. I’m looking for where the knowledge actually lives that the empty fields would otherwise hold. Three categories show up in nearly every 5-50 person business. Each one is a different shape of what extraction has to surface.
Customer-specific exceptions.
Twelve, fifteen, twenty customers who deviate from the standard contract in a way the team has memorized. One pays net-30 instead of net-15 because of a deal made in 2019. One gets the senior tech on every job, no exceptions, because the last junior tech who went got chased off the property. One only takes calls Tuesday afternoon. None of this lives in a field. It lives in the part of the brain that recognizes a name and routes the call accordingly. When he takes a day off, half of those customers get the wrong handling. When he leaves, all of them do.
Process exceptions.
The two dozen “when X happens, you actually do Y” rules that the documented process doesn’t cover. A job comes in for a service the company sells, but the access at the customer’s house requires a different crew composition. An order arrives for a product variant the standard pricing sheet underbills by 15%. A quote request mentions a competitor name that signals the prospect is shopping and won’t close, so the team triages it. The documented playbook covers the regular cases. The senior person carries the irregular ones. The irregular ones are where most of the margin and most of the risk live.
Vendor and partner relationships.
When a part goes out of stock on Wednesday afternoon, he texts a specific contact at a specific supplier and gets it by Friday morning. When a subcontractor flakes, he knows which of three backups will pick up on short notice. When a referral partner is going through a slow season, he checks in with them so they keep sending leads. None of this lives in a CRM record. None of it is in a vendor list. It’s a network built over years, and it ships with him when he leaves.
Extraction is the data work
Most operators in this size range hear “data discipline” and picture better software. A cleaner CRM, a stricter intake form, a dashboard that actually reflects reality. A consultant has probably pitched one of the three in the last quarter.
Software isn’t the discipline. Software is the destination.
The discipline is the project of pulling what experienced people already know out of their heads and into a structured format the team and any future tool can use. In a 5-50 person business, that is what data work actually looks like, and it shows up in shapes that don’t impress: hours sitting next to him asking what he’d tell a replacement on day one, a notebook that finally exists outside a text history, a customer-exception document populated one cell at a time, a vendor list reconciled against what’s actually in someone’s phone.
This is slower than buying a tool. It can’t be demoed in a conference room. It produces nothing impressive enough for a vendor case study. It also happens to be the only data work at this size that changes outcomes, because every automation the business will ever buy is built on what this project surfaces, or fails to.
Software builds on extraction. Extraction doesn’t build on software.
A conversation worth replacing
Most discovery calls I take open with a tool. The operator has been pitched a CRM upgrade, a chatbot, a lead scorer, or an AI quoting agent. The pitch was specific and the demo was convincing.
The exchange goes like this.
Operator: We’re looking at moving CRMs. The current one is a mess. Me: How much of what your team knows is in the current one? Operator: … not most of it. Me: Where is most of it? Operator: Brian, mostly. Some in his email. Me: Moving CRMs won’t help. You’re moving the empty one.
A new CRM doesn’t fix the problem if the old CRM was empty because nothing routed through it. The new one will also be empty, with a nicer interface and a higher monthly bill. Whatever made the team route around the system the first time still routes them around it. The dashboard reflects nothing because nothing is captured. The reports lie because they’re rolling up the absence of data.
The conversation worth having opens differently. What does the senior person know that nobody else has access to. Where do the team’s operational questions actually go. What does a new hire spend six months learning that isn’t in any document.
Those questions produce a different project than the CRM migration. They produce extraction. Notebooks. Interview hours. A document of customer exceptions. A pricing reconciliation. A vendor list that finally exists outside one phone.
Then, after that work, the CRM choice is meaningful. The system has something to hold. The dashboard reflects something the team would actually trust. The new hire ramps against what the company knows, not against the same one person.
Empty the head before you fill the system.