What to do when a client wants AI and has no usable data
6 minute read. Updated 2026-08-08.
Sell the data work as its own priced phase, named as what it is, rather than quietly building a demo on data that will not survive contact with production, or folding remediation into the AI fee for free. If the client will not fund the data phase once they have seen what is actually there, walk from the build. A model built on data nobody has properly assessed is not a shortcut, it is a second, worse project waiting to happen.
The pattern
A client wants a model, a forecast, an assistant, and describes the data behind it in one confident sentence: we have all our customer data in the CRM. Most of the time this is not true in the way that matters. The data exists, but it is inconsistent, unlabelled, spread across three systems that do not reconcile with each other, or simply not clean enough to build anything reliable on.
This is not a rare edge case. It is close to the default state of data in mid-sized companies that have grown by acquisition, changed systems twice, or let three departments each build their own version of the customer record. Anyone who has run a few of these engagements has seen the pattern before the kickoff call ends.
Two responses that go wrong
The first bad response is to build the demo anyway, on whatever data is easiest to reach, and hope it looks good enough to justify a second phase. It usually does look good, because demos get built on the cleanest slice of data available and small tidy datasets are forgiving. It also tells the client nothing true about what production will actually cost.
The second bad response is to notice the data problem, say nothing, and quietly absorb the extra weeks of cleaning into the original fee to keep the relationship smooth. This trains the client to expect data remediation for free, and it trains you to resent an engagement you priced wrong by week three.
The position: price it, name it, sequence it
The data work is a separate, paid phase with its own deliverable: an honest assessment of what exists, what is missing, and what it would take to make the data usable. This is not an upsell bolted onto the real project. It is the first real piece of the project, because no model decision can be made responsibly before it.
Price it as a fixed, bounded piece of work, not open-ended hours. A Data Engineer's median advertised contract rate over the six months to August 2026 was £500 a day; a two-week assessment at that rate comes to £5,000. Stating it this way gives the client a number they can check, rather than a figure that appeared from nowhere.
Sequence it explicitly: assessment first, decision point second, build third. The client chooses whether to proceed after seeing the assessment, with a real figure attached to what remediation would cost, rather than discovering the true cost midway through a build they have already announced internally.
How to sell it without sounding like an upsell
The difference between an upsell and a sequenced project is whether the first phase is genuinely useful on its own if the client stops after it. Make sure it is. The data assessment should tell the client something they did not know, whether or not you build anything after it.
Say the sentence plainly in the first conversation, not after you have already looked and found problems: I always start with a short assessment of the data, because the fee and the design for the model depend on what is actually there, not what the brief says is there. Said before you have looked, this reads as method, not as a complaint about their systems.
Avoid describing the data as broken or blaming the previous team. State what you found and what it costs to fix, without attributing fault. A consultant who arrives and immediately criticises the existing setup reads as difficult, whatever the criticism's accuracy.
When to walk
If the assessment shows the data cannot support the outcome the client wants within a budget they will actually approve, and they still want to proceed straight to a build, that is the moment to walk from the build, not the moment to compromise on quality quietly. Shipping something that will fail in production is worse for your reputation than losing the fee.
The trade-off here is genuine. Walking away costs you revenue now. Staying costs you a project that could fail publicly with your name attached to it later. Weigh it by asking honestly who will be blamed if the model is wrong once it meets live data, and whether that person will be you.
In most cases the right call is to walk from the build, not from the relationship. Offer the assessment as the complete, useful piece of work it was, and leave the door open for when the data situation changes, which sometimes happens faster than clients expect once the true cost is written down.
What good looks like
The engagements that go well tend to be the ones where the client remembers being told the truth early, priced fairly for it, and given a real choice at the decision point. That memory is worth more than the extra weeks of fee you might have earned by staying quiet about the data.
Treat the data assessment as a product in its own right, not as a preamble to the real work. Written up clearly, it is often the single most useful document a client receives from the whole engagement, whatever happens after it.
What to do about it
- Never assume a client's description of their own data is accurate; check before quoting.
- Price the data assessment as its own bounded phase with a named deliverable.
- Say you always start with a data assessment before you've seen anything, so it reads as method, not criticism.
- Give the client a genuine decision point after the assessment, with a real remediation cost attached.
- Walk from the build, not necessarily the relationship, if the data cannot support the ask within budget.
- Never absorb data remediation into the original fee quietly, even to keep the relationship smooth.
Questions people also ask
How do I bring up bad data without sounding like I'm padding the project?
Say it before you've looked, as a standing method: you always start with a short paid assessment because the fee and design depend on what's actually in the data, not on what the brief describes. Said in advance, this reads as professional practice. Said after you've already found the problems, it reads as an excuse to add fees.
What if the client refuses to pay for a data assessment phase?
That refusal is useful information on its own. A client unwilling to fund finding out whether the project is buildable is unlikely to fund fixing what the assessment would find. Consider declining the engagement rather than quoting a build fee against data you have not actually seen and cannot vouch for.
Should I ever just build the model on the data as it stands, to save time?
Only if you tell the client plainly what that decision costs: a model that may not generalise beyond the sample used, with a real chance it fails once it meets live data. If they accept that trade-off with full knowledge, proceed. If they have not understood it, they have not actually agreed to it.
How do I price a data assessment if I don't know how bad the data is yet?
Fix the scope to time, not to outcome. A two-week assessment at a stated rate, for example the median Data Engineer contract rate of £500 a day advertised over the six months to August 2026, gives £5,000 for two weeks. You are pricing the investigation, not the fix, so the scope stays bounded regardless of what you find.
Where the figures come from
Every rate and salary quoted in this article is a median or percentile of figures advertised in UK job postings over the six months to 8 August 2026. They are not rates paid, and the gap widens at the top of a range.
- IT Jobs Watch, UK contract rates, 6 months to 8 August 2026, read 2026-08-08.
- IT Jobs Watch, UK permanent salaries, 6 months to 8 August 2026, read 2026-08-08.