Is Your Data AI-Ready, and How Would You Know?
“AI-ready” is not a grade a vendor awards you. It is a checkable property of your own records: the decision you want a system to make has to already be written down in your data, often enough and with enough context that a model can learn it from history. Most operations we look at are closer to that than they fear and further from it than a demo suggests. Below is the check we would run, written so that you can run it first, on your own exports, without hiring anyone.
What “AI-ready” actually means
Four properties, and “clean” is not one of them.
The decision is in the data. If you want to know how much to order of each item, you need order history at item level, not monthly revenue totals. If you want to flag customers drifting into payment trouble, you need invoice dates and actual payment dates per customer, not an aging summary. The most common readiness failure is not dirty data. It is data that never recorded the thing you now want predicted, at the resolution you want to act on.
The history covers a full cycle. A year or more of history that reflects the business is enough to start, even if it lives in an ERP and a set of spreadsheets. The period has to contain your seasonality at least once, or the model learns your peak as if it were your normal.
The same entity is the same entity everywhere. One customer, one item, one supplier, carrying an identifier that survives the trip between the ERP, the ordering system and whatever spreadsheet the sales team actually maintains. Where the join needs a human to recognize names, that join is work, and it is usually the largest single line in a readiness estimate.
The record is written when the thing happened. A delivery date typed in at month end tells you about the paperwork, not the delivery. Timestamps that reflect the event are what make a model’s sense of “before” and “after” trustworthy, and they are what a forecast is built on.
Check it yourself, before you hire anyone
Six questions, answerable in an afternoon with exports you already have. No tooling beyond the spreadsheet you use every day.
- Name one decision. Pick something currently decided on gut feel and write it as a sentence with a number in it: how many units of this item to order, which accounts to call this week, how many hours to quote. If you cannot get a number into the sentence, stop here. That is the thing to fix first, and no amount of data work fixes it.
- Find where that decision leaves a trace. Export the table that records it: order lines, invoices and payments, work orders, event logs. One table is enough to start.
- Count per entity, not in total. Two million rows is meaningless; what matters is the median item, customer or machine. How many observations does a typical one have, over how many periods? Entities with thin history ride on family-level patterns rather than their own, which is normal and worth knowing before anyone promises item-level precision.
- Try the join by hand. Take twenty records from the second system and match them to the first on whatever identifier you believe is shared. Count how many matched without a human deciding. That percentage is the single most useful number in this whole exercise.
- Check the clock. Sort by created date and look at where the rows cluster. Bursts at month end, long flat stretches, or a step change on the day you switched systems all mean the history has seams in it. Seams are workable, but they change the scope.
- Name who acts on the answer. Which person, in which screen, on which day of the week. A prediction nobody is scheduled to act on is a report, and reports do not change outcomes.
If questions 1 to 5 have answers and question 6 has a name, your data is ready enough to be worth scoping. That is a lower bar than most vendors imply, on purpose.
What fixing it costs, and what drives that cost
We do not publish a price list, because a price list would require guessing your scope before seeing it. What we can publish is what moves the number. On the data side there are four drivers, in rough order of weight:
- How many systems have to be joined. One system is arithmetic. Three systems with three different customer identifiers is a project.
- Whether identity is consistent. Question 4 above is the cost driver. A match rate in the nineties is housekeeping; a match rate in the sixties means someone builds and maintains a reconciliation.
- Whether history has to be reconstructed. Recovering a period that was never recorded properly is the most expensive kind of readiness work, and it is often better replaced by scoping the model to the period that is sound.
- Where the answer has to land. A report emailed out is cheap. A recommendation that appears inside Priority or SAP in front of the buyer at the moment of ordering costs more, and is worth more, because that is the one that changes decisions.
A closed network changes the picture again: self-hosted models, controlled file import and nothing leaving the boundary. It is a legitimate and common requirement here, and it affects cost. The full breakdown of how stages are priced, and why scoping is priced separately, is on the AI pricing page.
When the honest answer is “not yet”
Three patterns account for most of the “not yet” verdicts we give, and each has a different first step.
The decision was never recorded. You want to predict something the business has been deciding in people’s heads or in a WhatsApp thread. Nothing in the export contains it. The fix is cheap and slow: start recording the decision and its outcome now, in one field, and revisit in a cycle or two. This is the most common finding and the least welcome one.
The history has a seam through the middle. A new ERP, a re-coded item catalogue, a merger. The data is fine on both sides and incomparable across the join. The fix is a choice, not a build: scope the model to the sound period, or spend the effort mapping the old codes to the new ones, and only if the older period is genuinely needed.
The data is ready and the organization is not. Nobody owns the decision, or three people own it and disagree. A model here would produce a well-calibrated number that no one is authorised to act on. This one is not a data problem, and we will say so rather than build around it.
There is an order-of-work point underneath all three. AI agents built on top of a scattered operation automate the scatter. Centralizing first is what makes the layer above worth building, which is why data readiness sits inside our business AI transformation practice rather than beside it.
Where data work sits in our engagements
Readiness is not a product we sell on its own. It is the first stage of the work, and it is bounded on purpose: characterization maps the business problem, the workflows around it, and the data that actually exists, then agrees the success metrics in business terms before anything is built. It ends with a written scope, and it is allowed to end with “not yet, and here is what to fix first”. You keep the findings either way. How we work sets out the three stages and the exit point at each one.
Two things worth being plain about. We integrate into the systems you already run rather than proposing to replace them, and the models, code and data pipelines transfer to you on delivery. And we are a small senior team, not a data-platform integrator: if what you need is a multi-year, organization-wide data program, we are the wrong size for you on purpose, and you will hear that in the first call rather than in month nine.
The place to start is one decision currently made on gut feel. A scoping conversation of twenty to thirty minutes is usually enough to tell whether the data behind it can carry a model, and roughly what it would take.
How much history do we actually need?
A year or more of history that reflects the business is enough to start, even if it lives in an ERP and a set of spreadsheets. A second year is worth more than it sounds, because it is what lets a model tell a trend apart from a season. What matters more than the length is that the period contains the decision you want predicted, recorded at the resolution you want it made.
Do we need a data warehouse before we can use AI?
Usually not, and treating one as a prerequisite is how initiatives stall for a year before producing anything. You do not need a data team or a warehouse project before talking to us. A first useful system normally runs on exports and read access to the systems you already have. A warehouse becomes worth building when several decisions need the same joined data, not before.
What does it cost to get our data AI-ready?
It depends on how much of the work is joining versus reconstructing, and a number quoted before anyone has looked at the data is a guess. What can be said up front is what drives it: how many systems have to be joined, whether the same entity carries the same identifier in each of them, whether missing history has to be rebuilt, and where the answer has to land. The pricing page sets out how the stages are priced.
Our data lives in Priority and a pile of spreadsheets. Is that a problem?
It is the normal starting point for an Israeli mid-market operation, and it is why our designs integrate into the systems you already run rather than replacing them. We have scoped and built against Priority, SAP, monday.com and Hashavshevet environments, alongside data warehouses and spreadsheets that behave like databases. Spreadsheets are a readiness problem only when they hold facts that exist nowhere else and nobody agrees on which copy is current.
Can our own IT team do this instead of hiring anyone?
For a good part of it, yes, and we will say so. Exports, joins and access are ordinary IT work. The part that is not ordinary is deciding what the system has to learn, and testing honestly whether the history can carry it. That is the question a characterization stage exists to answer, and it is answerable in weeks rather than in a platform program.
What is the return on data-readiness work on its own?
On its own, close to nothing, and we would rather say that than sell it as a phase. Readiness work pays only through the decision it makes possible: a purchasing decision made with less error, a fading customer caught while there is still time to call. That is why we scope readiness to a named decision with a success metric attached, and why we do not sell a standalone data-cleanup engagement.