"Our Data Is a Mess" — The Objection That's Really About Being Exposed

I have heard "our data is a mess" in a discovery call, in a demo, in a procurement review, and once from a VP of Operations three days before a signature. Same five words every time. Almost never the same meaning.

Early on I treated it as a technical question. I would start talking about connectors, field mapping, how we handle nulls, whether we could ingest a CSV export from a system nobody had upgraded in a decade. I was answering a question the buyer had not asked. The deals stalled anyway, and I could never work out why, because on paper I had handled the objection.

Here is what I eventually figured out. When somebody tells you their data is a mess, they are usually not asking you whether your product can cope. They are telling you what will happen to them personally if your product works. If we turn this on, the state of my asset register becomes visible. My boss sees it. My boss's boss sees it. And the person who gets asked about it is me.

That is a completely different objection, and it does not get solved with a slide about your ingestion pipeline.

Three versions of the same sentence

Before you respond to "our data is a mess," you need to know which one you are holding. There are three, and they need three different plays.

Version one: the genuine technical blocker

This is real. It exists. It is also the rarest of the three, in my experience, which is exactly the opposite of what most reps assume.

A genuine technical blocker sounds specific. The buyer knows what is broken and can describe it without you prompting them. "We have two asset registers because of the acquisition, they use different naming conventions for the same substations, and nobody has reconciled them." That is a person describing a problem they have already looked at. They have opened the file. They know where the bodies are.

Genuine blockers come with detail. They come with history. They usually come with the name of a person who tried to fix it before and failed.

Version two: the political fear

This one sounds vaguer, and it arrives with a slight change in tone. Notice when the energy in the call drops. Somebody who was leaning in about the workflow suddenly gets careful with their words.

"Honestly, our data isn't great." "I'd want to clean things up first." "We'd need to get our house in order before something like this."

Nobody says "our house in order" about a technical problem. That is the language of shame. What they mean is that the gap between what the organisation believes is true and what is actually true is large, and your product is about to close that gap in public.

The maintenance leader whose PM completion rate looks fine on paper because half the work orders get closed without anyone touching the machine. The operations manager whose asset register has hundreds of records for equipment that was scrapped years ago. The brokerage ops lead whose margin per load looks healthy in the monthly report because the accessorials that eat it are logged inconsistently and never rolled up.

None of these people are frauds. They inherited a system, they have been running hard, and nobody has had time to reconcile anything. But they know. And your dashboard is going to know too, and it is going to know in front of the CFO.

Version three: the polite brush-off

The third version is not about data at all. It is a no, wearing a hat.

It shows up when the buyer has already decided this is not a priority but does not want to have that conversation, either because they are conflict-averse or because they think you will argue. "Our data is a mess" is a socially acceptable exit. It sounds responsible. It sounds like something a diligent operator would say. And crucially, it puts the problem on their side of the table where you cannot argue with it.

The tell is that it comes without detail and without follow-up energy. You ask a probing question and they give you a short answer and change the subject. There is no curiosity behind it. A person with a real problem wants to talk about their real problem. A person giving you a brush-off wants the call to end.

The diagnostic question for each

You cannot ask "is this a real objection or are you brushing me off?" So you ask questions that produce different answers depending on which version you are dealing with.

For the technical blocker, ask about the last attempt. "Who was the last person to try and sort this out, and where did they get to?" A real blocker has a history. You will get a name, a date, a half-finished project, a consultant who left. If there is no history at all, be suspicious — a problem genuinely bad enough to block a purchase usually has scar tissue around it.

For the political fear, ask about visibility. This is the one that matters most and the one almost nobody asks. "If we switched this on next month and it showed something nobody expected, who would see it first, and how would that conversation go?"

That question does two things. It names the fear without accusing anyone of having it, and it invites the buyer to describe the political weather. The answers are extremely informative. "It would go to the exec dashboard" is a different deal from "it'd come to me first and I'd decide what to do with it." If they hesitate before answering, you have found your real objection and you should stop selling and start listening.

For the brush-off, ask about the cost of doing nothing. "Suppose the data stays exactly as it is for the next two years — what does that cost you?" A person with a real problem answers immediately and with feeling. A person brushing you off says something like "yeah, it's not ideal" and stops. That is your signal to stop spending cycles here and go find a better-qualified opportunity. Not every no needs converting. Some of them need accepting quickly so you can get your time back.

I put versions of these into the discovery structure I use with field-service and asset-heavy buyers, because in those markets the data question comes up in nearly every first call. If you sell into utilities or networks, the energy and utilities discovery playbook is built around getting to the state of the asset register early rather than at the end, which is where it usually ambushes you.

The reframe: bad data is the first deliverable

Here is the single most useful shift I have made in how I handle this objection.

Stop treating clean data as a prerequisite. Start treating the mess as the first thing your product finds.

Most vendors, without meaning to, tell the buyer they have homework. Get your records in order, standardise your naming, then come back and we will implement. That is a terrible offer. You are asking someone to complete a project they have already failed to complete, with no budget and no headcount, in order to buy something from you. And you are implicitly telling them the mess is their fault.

The reframe sounds like this:

"You don't need to clean it first. If the register's wrong, the fastest way to find out exactly how wrong is to run it through this and look at what falls out. That report is the first thing you get. It's not a prerequisite, it's output one."

This is not a trick. It is usually true. A system that reconciles asset records will tell you which records do not reconcile. A tag-tracking system will tell you which tags have not been scanned in eighteen months, which is a polite way of saying they are gone. A load-data platform will tell you which accessorials are being logged three different ways. The exceptions are the value. You are not selling a clean-data requirement, you are selling a mess-detection engine, and the buyer already knows they need one.

What this does politically is important. It converts the buyer from the person who let the data rot into the person who found the problem. Same facts, opposite story. That is the whole game.

Scope a slice narrow enough that nobody needs permission

The reframe only works if the first step is small. If you say "the mess is the first deliverable" and then propose a nine-month enterprise rollout, you have not removed the fear, you have amplified it.

So scope a slice. One site. One depot. One equipment class. One customer's freight. The test is simple: can your champion authorise this without asking anyone above them, and can the result be shown to a boss as an interesting finding rather than an incident?

Three worked examples, because this gets abstract fast.

Asset registers. A utility or a large facilities operator has a register that nobody fully trusts. The instinct is to propose a full reconciliation. Don't. Propose one substation, or one class of asset across one region. Something small enough that if the answer is "a quarter of these records are wrong," the finding is contained and interesting rather than a scandal. "Let's take the assets at one site, run them through, and see how closely the register matches reality. If it matches, great, we've proved the register is solid and we can move faster on everything else. If it doesn't, you'll have a number to take to the capital planning conversation you're already having." Either outcome is a win for your champion. That is what a well-scoped slice looks like.

Tag data on job sites. Anyone who has sold into construction knows the tags are in the truck, the truck is on a site two hours away, and the register was last updated by a foreman who has since left. The mistake is trying to establish a full inventory baseline before you can show value. Instead, take one active site and one category of kit. Scan what is actually there over a week. Compare it to what the system thinks is there. The gap is the deliverable. Nobody needs to clean anything first, and the site manager gets a document that makes their life easier rather than an audit that makes it harder. I go into how to open this conversation without triggering the defensive reflex in the construction and trades discovery playbook, because in that market the objection often arrives dressed as logistics rather than data quality.

Load data in brokerage. Freight is the hardest of the three, because the room you are demoing to is actively looking for where your product breaks and they will bring their ugliest lane to find out. Do not fight this. Ask for the ugly lane. "Give me the customer whose data is worst. That's the one I want." Then scope to that single customer's loads over a defined period, and let the exceptions surface. If your demo can absorb genuinely bad input and still produce a usable answer, you have won the technical argument and the credibility argument at once. I wrote up how to run that room in the freight and 3PL demo script — the short version is that you invite the breakage instead of steering around it.

The exact language that gives your champion cover

This is the part reps skip. You can handle the objection perfectly and still lose, because you never gave your champion the sentence they need to say internally.

Your champion is going to have to explain to somebody why they are buying software that will reveal how bad things are. If you do not write that explanation for them, they will have to write it themselves, under pressure, in a meeting, and they will probably decide it is not worth the risk.

So hand it over. Say something like:

"When you take this to your director, the framing that tends to land is: we've suspected the register's drifted for a while, this gives us a cheap way to quantify it on one site before we commit to anything bigger. That way you're the person who got ahead of it, not the person who got caught by it. Do you want me to put that in writing so you're not paraphrasing me?"

Every clause there is doing a job. We've suspected makes the problem pre-existing rather than newly created. Cheap way to quantify makes it prudent rather than expensive. One site before we commit makes it reversible. Got ahead of it is the story your champion tells about themselves.

And offering to put it in writing is not a courtesy, it is the most valuable thing you can do in the whole cycle. The document your champion forwards internally is the actual sales call. You will not be in the room for it. Write it as if you will not be.

One more piece of language, for when the fear is obviously present but nobody has named it. Do not name it directly — you will embarrass them and lose the deal. Name it about somebody else. "The thing people in your seat usually worry about is that the first report lands on the wrong desk before they've had a chance to look at it. We can set it up so the initial output comes to you and only you, and you decide what gets shared and when." Every buyer who is scared will hear that as an offer of control, and control is what they wanted the whole time.

Working the objection until it stops surprising you

The reason this objection kills deals is not that it is hard to answer. It is that it arrives unexpectedly, usually late, usually in front of other people, and the rep answers the technical version because that is the only version they have ever practised.

The fix is repetition. Take the three diagnostic questions above, take the champion-cover language, and say them out loud until they come out without effort. Then have somebody throw the objection at you in all three flavours — specific and technical, vague and nervous, flat and dismissive — and see whether you can tell them apart in real time. That is the actual skill. Not the answer. The classification.

That is what I would go and drill, and it is close to why I built DrillCall — I wanted a way to run the same objection at a rep twenty times with the emotional temperature changed each time, because reading a script does not build the ear for it. If you sell into asset-heavy industries, I would take "our data is a mess" and run it as a repeated rep this week rather than reading about it and hoping it lands, and I would do the same with the manufacturing discovery questions if plant managers are your buyer.

One last thing. Sometimes the data really is a mess, the fear is real, and the answer is genuinely no for now. That is fine. The point of separating the three versions is not to convert all of them. It is to stop spending three months on the one that was always a polite goodbye, so you have the time to do the work on the one that was a real deal wearing a scared face.