AI Copilot for Retail Operations: Answers From Your Data, Decisions You Can Check

Ask a general chatbot why margin fell in your fifth store last week and it will tell you what usually lowers margin in retail: supplier prices, promotions, shrink. All true, and none of it about your fifth store. An AI copilot for retail operations is worth having only when it answers from your stores' own numbers, says when it does not know, and turns what it finds into a suggestion someone can check, act on and measure.

This guide takes those requirements one at a time, starting with the data.

Why a general model cannot answer for your stores

A language model knows a great deal about retail and nothing about your chain. It has not seen yesterday's receipts, this week's deliveries or the cost price of anything you sell, so its answer to a question about your stores is a description of stores in general.

Connecting the model to your database is not enough on its own. Spider 2.0, a benchmark built from real company data and the questions analysts ask of it, gave one of the strongest models an agent that could explore the database and write queries; it solved 21.3% of the tasks¹. Among the main obstacles the authors name is finding the right tables and columns in very large databases. A model that cannot tell which column holds net sales will return a confident number from the wrong one.

Give the AI a data model, not just a database

What fixes most of that is meaning, written down before the AI arrives. In one test on an insurance company's database, GPT-4 answered 16.7% of business questions correctly when it worked from the raw tables, and 54.2% when the same database was described to it through a model of what each table and relationship means². The authors build such models for a living, so read it as one careful test rather than a law; the direction matches what anyone who has cleaned retail data would expect.

For a store chain the data model is the dull work: one definition of a sale, one business day, one list of stores and one category tree, so that every question is answered on the same terms. The guide to consolidating POS data across stores covers it step by step. A copilot sitting on top of that work can answer "why did margin fall" by reading margin as the chain defines it, for the store and the week asked about.

A copilot that says "I don't know" is worth more

Language models are trained and scored in ways that make guessing pay. Researchers at OpenAI argue that models hallucinate because training and evaluation reward guessing over admitting uncertainty: on a test that gives no credit for a blank, a guess always scores better³. In a business tool the scoring runs the other way. An answer that says last Tuesday's data from one store has not arrived costs a minute; a made-up figure for that store can cost a wrong decision.

So the rules for the copilot's answers should be explicit, and checked on every answer:

From a finding to a suggestion a person can check

A finding is "store 5's margin fell". A suggestion is "move these units of a slow line from store 5 to store 2, where it sells", with the evidence next to it: what the copilot saw, against what baseline, and what the move should change. The evidence is what lets a manager decide quickly, and it changes how well they decide. In two preregistered experiments, one in factory quality inspection and one in radiology, people working with an AI that showed why it reached a prediction caught 96.9% of its wrong predictions, and people working with an unexplained AI were 3.6 times more likely to overrule a prediction that was right⁴.

Evidence helps only if someone reads it. A review of 35 studies on automation bias, the habit of accepting what a system recommends, found that explanations often make a system more acceptable without making decisions more accurate, and that asking people to verify reduces complacency⁵. So the check belongs in the process, not left to goodwill: the person who accepts a suggestion confirms the evidence before it goes ahead.

Let the manager decide, and keep a record of overrides

Store managers know things no dataset holds: a building site opening next door, a supplier who is about to be late. In a convenience store chain that introduced replenishment recommendations in some stores and left others unchanged, the stores with the system reached a 2.9% higher service level without holding more stock, and managers spent 36.5% less time on daily orders. When managers overrode the system, interviews showed they were usually anticipating demand it had not yet seen⁶.

Overrides are not always right, though. A study of a supermarket chain's automated replenishment found that after a stockout, managers tended to order less than the system proposed, which led to stockouts of their own making⁷. Record every override with its reason, and look at them together once a month. The pattern tells you whether the system or the habit needs fixing.

Measure the effect against stores that did nothing

When a suggestion is accepted and carried out, sales before and after will differ, but so would they have without it: a holiday, the weather, a competitor's promotion. The standard method compares the stores that acted with similar stores that did not, over the same weeks. It rests on one assumption, that the two groups would have moved in parallel without the action⁸, so check that they did move together beforehand.

The same applies to the copilot itself. If it is worth what it costs, the stores using its suggestions should pull ahead of comparable stores, and you should be able to see by how much. The dead-stock guide shows one kind of suggestion, a store-to-store transfer, end to end.

How marql AI works

marql AI answers from the chain's own sales, stock and cost data. The data a question needs is fetched by fixed queries before the model writes anything, and the model can call further tools that read the same tables. It cannot change anything in the chain's systems from the chat; the only thing it can create there is a task. Its instructions forbid inventing numbers and require it to say when a period has no data, and after each answer the numbers in it are checked against what the tools returned. Store names are replaced with codes before a question reaches the model provider, a store manager sees only their own stores, and it answers in six languages.

Every morning at six, local time, it sends a short brief: yesterday's revenue, margin and receipts, the strongest and weakest store, the day's weather and the past week's anomalies, each measured against the store's own normal pattern. For each store it also works out how sales have moved with the weather over the past 90 days, and uses that in the brief and in its answers, so a rainy-day dip is not mistaken for a problem in the store. When a person accepts a proposed action, the Impact Ledger freezes the baseline and, at the end of the window, compares the stores that acted with at least four similar stores that did not, or with the store's own history when there are not enough of them. The marql AI page shows the questions it answers.