"Our Data Is a Mess — It'd Never Work Here"

Every rep hears it. Usually somewhere between the second call and the pilot conversation, right when things were going well. The champion leans back a little and says some version of: "Look, I like this. But our data is a mess. It'd never work here."

And most reps do one of two things. They either agree enthusiastically and offer to help clean it up, which is how you hand your deal to a data engineering team that has never heard of you. Or they wave it off — "oh, our platform handles messy data" — which is a lie the buyer can smell from across the table, because they know exactly how messy it is and you don't.

The reason both responses fail is that reps treat this as one objection. It's two. And they need opposite handling.

Two different sentences that sound identical

The first version is a real technical constraint. The person is telling you something true about their systems. Fields are empty. Three systems disagree. The migration in 2019 dropped history. They are not stalling you, they are trying to save you both a wasted quarter. This person is doing you a favor and most reps step right past it.

The second version is an operator protecting themselves. They have looked at what your product does, they have understood that it will make visible things that are currently invisible, and some of those things are theirs. Maybe the work order completion rate their plant reports is generous. Maybe the dispatcher notes would show that the same three carriers get every good load. Maybe nobody wants a system that can count how long a claim actually sat.

That person is not lying to you. They genuinely believe the data is a mess — they are the one who knows it best. But the objection is doing emotional work, not technical work. Solving the technical problem will not move them, because the technical problem was never the blocker.

I have lost deals by treating version two like version one. Spent weeks getting sample extracts, building a mapping doc, proving the model works on their garbage — and then the deal died anyway, because the person who raised the objection never wanted it solved. That's a stupid way to lose. So learn to tell them apart early, and it takes about two questions.

Question one: make them show you a record

"Totally fair. Can you pull up one record and walk me through it? Doesn't matter which one. I want to see what a normal row looks like."

The technical answer is specific and it comes fast. "Okay so here's a load. Origin's fine, destination's fine, this appointment field — see, that's blank about as often as it's filled, because dispatch does it by phone and nobody goes back in. And the accessorial codes are a free-for-all, every rep has their own." That's a person describing a system they use every day. They are handing you a spec.

The self-protective answer stays abstract. "It's just all over the place. Different people enter things differently. It's grown organically over the years." Push once, politely — "totally, what's an example?" — and if the second answer is also abstract, you are not talking about data. You are talking about something else. Nobody who has genuinely wrestled with a bad table struggles to name the specific field that ruins their week. They have a grudge against that field.

Question two: find the last attempt

"When's the last time somebody tried to use this data for something? How'd that go?"

This is the better question of the two, and reps almost never ask it. Every answer is useful.

Sometimes you get: "Never, honestly, that's part of the problem." Fine — genuine constraint, no scar tissue, you're clear to scope.

Sometimes you get a long, detailed story about a consultant, a BI project, or an ERP module that took eighteen months and produced a dashboard nobody opens. That's a real constraint plus organizational fatigue. Different problem, still solvable, but you now know your first phase has to be small enough that it cannot possibly become the next eighteen-month story.

And sometimes the temperature in the room changes. They get shorter. They mention that corporate ran a report last year and "the numbers weren't right." That is your tell. Somebody got embarrassed, and it may well have been the person sitting in front of you. The data isn't the wound. The report was.

Once you know which one you've got, you can actually work.

The reframe: everybody's data is a mess

Here's the thing worth saying out loud, because it changes the conversation from a confession into a design question.

I have never once been inside a company whose data was clean. Not at AWS, not at Dell, not in any of the businesses I've built. Not one. The buyer thinks their mess is unusual and disqualifying. It isn't. It is the normal condition of an operating business, because data gets entered by people who are being paid to do something other than enter data.

So the question is never "is the data clean enough." The question is: does this product tolerate the specific kind of mess this company has? Those are wildly different questions, and the second one is answerable in a week.

Say it plainly: "Every customer I have says this. Genuinely, every one. The useful version of the question isn't whether your data is clean — it isn't, nobody's is. It's whether the parts I actually need are usable. There are about three fields I care about. Let's look at those three and ignore everything else."

That lands, because it's true, and because it shrinks the problem from "fix our company" to "check three columns."

Know your minimum viable data, and be honest about the edges

You cannot run that play unless you know, precisely, what your product needs to work. Not what it likes to have. What it needs.

Most reps can't answer this. They know the demo dataset. They don't know which fields are load-bearing. Go ask your solutions engineer, this week, before your next call: what is the smallest set of fields on which this thing produces a result worth paying for? Write it down. Memorize it. It's probably shorter than you think — often a timestamp, an identifier, and one outcome column.

Then learn the other half, which is the part that builds trust: what your product cannot do with their mess. "If your appointment times are blank half the time, the on-time metric is going to be junk and I'm not going to pretend otherwise. What we can do is the dwell analysis, because that only needs the arrival and departure stamps and those come off the telematics feed, not off a human."

A rep who volunteers a limitation before the buyer finds it is a rep who gets believed on everything else. This is the single highest-return habit in enterprise selling and it costs you nothing but the discipline to say a true thing that isn't flattering.

Every company has one clean dataset. Follow the money to find it

Here is the pattern I'd want every rep to internalize, because it turns the objection into a scoping exercise.

Data that touches money is clean. Data that doesn't, isn't. Somebody audits the billing table. Nobody audits the notes field.

In a freight brokerage, ask a rep about their data and they'll tell you about the dispatch notes, and they're right — it's a swamp of shorthand, carrier phone numbers, and "driver says 2hrs out." Nothing structured, nothing consistent. But the load table is immaculate, because it drives the invoice and the carrier settlement. Rate, origin, destination, carrier, pickup and delivery dates. All of it clean, because if it's wrong somebody doesn't get paid and the phone rings within a day. Your first phase runs on the load table. The notes come in phase three, if ever. Getting to that answer requires asking the right questions on the first call, which is exactly what the freight and 3PL discovery playbook is built to force.

At a carrier, claims notes are the most valuable and most unusable data in the building. Decades of adjuster free-text, abbreviations that vary by office, three different systems from three acquisitions. A buyer who says "our claims data is a mess" is describing that, and they are correct. But the FNOL intake fields are structured, the reserve history is structured, and the payment records are structured — because of reserving discipline and regulatory reporting. There is a whole product's worth of value sitting in the timestamps alone. When you're mapping this in discovery, the insurance discovery playbook walks through which claims-side questions to ask before you commit to a scope you'll regret.

At a utility, the asset records will break your heart. The GIS says the pole is at one coordinate and the crew finds it thirty feet into somebody's yard. Install dates are missing on anything predating the last system. Half the transformer records were typed off a paper card. Genuinely bad. But outage records are clean, because the regulator reads them, and work order completion is clean, because it's tied to the capital program. Scope phase one against outages and completions, and treat the asset master as something you improve as a byproduct rather than a prerequisite. The energy and utilities discovery playbook has the asset-hierarchy questions that surface this on call one instead of call four.

In a plant, work orders are half-filled and the closeout notes say "fixed." Maintenance techs are not typists and the plant manager knows it. But the historian is clean — downtime, cycle counts, production output — because it feeds OEE and OEE goes to corporate. So you demo against the historian. That's also why the manufacturing demo script for plant managers starts from a machine and a number rather than from a screen tour; a plant manager who sees you working off data he trusts will let you keep talking.

In all four cases the move is identical. Do not argue that the mess isn't a mess. Agree, immediately and specifically, and then point at the one dataset they cannot afford to let rot.

Why "we'll help you clean it" costs you the deal

This is the trap, and it's tempting because it feels generous and consultative.

The moment you offer to clean their data, four things happen. Your deal stops being a product purchase and becomes a data project, which is a different budget line with a different owner. A new stakeholder appears — IT, or data governance, or an architect — who has no relationship with you and no stake in your outcome. Your timeline stretches from a pilot to a program. And you have quietly accepted the blame for anything that goes wrong, including all the problems you're about to discover that nobody knew about.

In my experience that offer costs you a quarter minimum, often more, and the cleanup work never finishes, because there is no natural end to it. There's no such thing as done. Meanwhile your champion has moved teams and your original business case has gone stale.

What to do instead: shrink it to a sample. "Don't clean anything. Send me an export of the worst version you've got — a few hundred rows, whatever's easiest to pull, no formatting. I'll come back Thursday and show you exactly what it produces and where it falls over."

This is better in every direction. It's a small ask, so it gets done. It's fast, so you keep momentum. It proves tolerance rather than arguing for it. And it makes the mess a shared discovery rather than their embarrassing secret. If it turns out the data genuinely can't support the use case, you find that out in a week instead of a quarter, and you either re-scope or you walk. Both of those beat a slow no.

Handling the self-protective version without calling it out

If question two told you there's scar tissue, do not name it. Ever. "It sounds like you're worried about what this will show" is a sentence that ends a deal. You will be right, and you will still lose.

Give them cover instead. Build the first phase so that it cannot embarrass anyone, and say so explicitly. No executive dashboard in week one. Outputs go to their team and nobody else. They decide what gets shared and when. "Nothing leaves this room until you tell me it's ready" is the most persuasive sentence available to you here, and you should mean it.

And give them the story they'll need later. If the data does turn out to look bad, the framing that saves them is that they found it, deliberately, as part of an improvement they initiated. Hand them that framing early: "When we run this, we're going to find things. That's the point — you'll be the person who found them, not the person they were found on." Some buyers will take that deal immediately. It's the whole objection, dissolved.

Where this actually gets solved

Notice that everything above is easier if the data conversation happened in discovery instead of ambushing you in week six. The rep who asked "which system does that live in, and who owns it" on the first call is not having this argument. They scoped around it before the buyer had a chance to build it into a wall.

So if this objection keeps hitting you late, the fix isn't a better rebuttal. It's better discovery, earlier.

If you want to get the reps fluent rather than merely informed, run it as a drill. Pick one vertical, have someone play the plant manager who says "our work orders are garbage," and make the rep get to the historian in two questions without offering to fix anything. Do it ten times and it stops being a scramble. That's the thing DrillCall was built for — repping the objection out loud, against a buyer who pushes back, until the response is automatic. If I were building a ramp plan today, this objection would be in the first week of it, because it's the one that separates reps who scope deals from reps who inherit projects.

The short version: agree that the data is a mess, because it is. Find out in two questions whether the mess is the real problem. Then point at the one table that touches money, and start there.