Foundation · 2 min
Is Your Ecommerce Store Ready for AI?
| Estimated time | 6 min | | Lesson type | Decision guide |
A store is ready for a specific AI use case when the data that use case depends on is accurate enough, the process behind it is understood, the systems can exchange information reliably, success can be measured against a baseline you already record, and one named person owns review and exceptions. Readiness is never global. The same store can be ready for AI-drafted product copy and nowhere near ready for automated pricing.
Foundation · 7 min
What you will learn
- Why there is no such thing as an AI-ready store
- Five readiness checks, and which one most stores fail
- What each check demands for three common use cases
- How to scope a first use case so readiness is achievable
Why “AI ready” is the wrong frame
Readiness belongs to the use case, not the store. Drafting product copy needs accurate attributes and an editor. Demand forecasting needs years of clean sales history. An assistant that builds carts needs live inventory and written service rules. A store can hold one of those and none of the others.
A single readiness score hides the thing you needed to know. Scored assessments average across areas, so a store can look seventy percent ready while being completely unready for the one feature it was about to buy. Averages are the wrong shape for this question.
Connecting a model is not the hard part. Most readiness work is about what happens when the output is wrong: who sees it, how quickly, whether it can be reversed, and who is allowed to stop it. Stores that skip this part are not ready, however clean the data is.
Five readiness checks
Data. The specific fields the use case depends on are accurate and complete enough for the products or periods it covers. Not your whole catalog, the part it will touch. This is where most readiness fails, and it is also the one piece of work worth doing whether or not the AI happens.
Process. Somebody already does this job, and can describe how, including the exceptions. You cannot automate a process nobody can explain, because there is nothing to compare the output against and no way to tell a mistake from an edge case.
Integration. The feature can read current information and return its result somewhere useful without manual copying. A tool that needs a spreadsheet exported to it every Monday is a pilot, not a feature.
Measurement. There is a number you record today, before the AI arrives. Without a baseline, any later claim of improvement is an opinion. Capture it for a few weeks first if you do not have it.
Ownership. One named person reviews quality, handles the exceptions and has the authority to switch the feature off. Not a team, not whoever is free. If no one holds it, that is a readiness failure regardless of how good the data is.
Measurement and ownership are the two most often skipped, and they are the two that decide whether you can tell later that the feature worked. Data gets attention because vendors ask about it. Nobody asks whether you recorded a baseline.
What readiness looks like for three use cases
The same five checks demand very different things depending on what you are building.
| Check | AI-drafted product copy | Demand forecasting | An assistant that builds carts |
|---|---|---|---|
| Data | Accurate attributes on the products you will draft | Two to three years of clean sales and stock history | Live inventory, price and policy a shopper can be told |
| Process | Someone already writes and approves copy | Someone already decides reorder quantities | Your service rules are written down and agreed |
| Integration | Read product fields, write back a draft | Reliable feed from sales and inventory systems | Read and write to cart, orders and customer records |
| Measurement | Time per listing, edit rate | Forecast error against actual sales | Assisted conversion, handoff rate, complaint rate |
| Ownership | An editor who can reject a draft | A planner who can override a number | A service owner on duty who can take over mid-conversation |
Read down a column rather than across a row. The column is your actual readiness list for that use case, and the difficulty rises sharply from left to right.
Signs to fix foundations first
- Inventory counts and reality disagree often enough that staff check manually.
- The same product appears more than once, or key attributes are blank on your best sellers.
- Return, shipping and refund rules are not written down, or the team answers them differently.
- Analytics tools disagree and nobody can say which is right.
- A process runs the way it does because one person has always done it that way.
- Nobody owns exceptions, so unusual cases wait until someone notices.
Start with a bounded use case
Pick one problem with clear inputs, a reversible output and a number you already record. Write down the improvement you expect and the conditions under which you would stop, before anything is switched on. Run it on one category, one product set or one queue rather than the whole store.
This beats buying a broad AI suite and looking for uses afterwards, which inverts the order: it starts from a tool, scopes nothing, and leaves you evaluating several features at once with no baseline for any of them.
Key takeaways
- Readiness is use-case specific. A single score for the whole store tells you nothing useful.
- Clean data is necessary and not sufficient. Process, integration, measurement and ownership all count.
- Record the baseline before the feature arrives, or you will never prove it helped.
- Readiness includes handling failure, not just connecting a model.
- Clean the subset your first use case needs, not the entire catalog.