We sell this category, so treat our enthusiasm accordingly. The useful part of this page is not the pitch — it is the vocabulary. If you finish it able to ask a supplier “which level is this, and who approves a price change?”, it has done its job.
What does “AI ESL” actually mean?
A conventional electronic shelf label is a small e-paper screen that displays whatever price your point-of-sale system sends it. It removes paper and manual re-tagging, but the intelligence still lives upstream in the POS. An AI ESL adds a layer above the hardware: an engine that decides what the number on the shelf should be.
That shift — from display to decision — is the whole distinction. The label is still e-paper, still battery-powered for years, still updated wirelessly. What changes is where the price comes from.
The problem is that this definition is not policed by anyone. There is no standards body certifying what qualifies, no test a product has to pass, and no shared vocabulary between vendors. In practice the phrase gets attached to everything from a scheduled price import to a genuine demand model. That ambiguity is not usually malicious — it is what happens to any term that starts selling well — but it makes vendor comparison almost impossible unless you bring your own scale.
Five levels of AI at the shelf edge
Borrowing the logic of driving-automation levels, here is a scale you can hold a supplier to. It is our framing rather than an industry standard — but it is specific enough to be argued with, which is more than the phrase “AI-powered” offers.
| Level | What decides the price | Who acts | What to verify |
|---|---|---|---|
| 0 — Paper | A person, then a printer | Staff, physically | Nothing. This is the baseline you are replacing |
| 1 — Mirrored ESL | Your POS or price master | Nobody — the label just echoes | That the sync is genuinely one-way and real-time. This is where most value already sits |
| 2 — Rules-based automation | Rules you wrote: time of day, expiry window, stock level | The system, deterministically | Can you read, edit and audit every rule yourself, without the vendor? |
| 3 — Model-assisted recommendation | A model proposes; you approve | The system proposes, a human ships it | What data trained it, what it optimises for, and whether you can see why it proposed a price |
| 4 — Closed loop in guardrails | A model, inside hard floors and ceilings you set | The system, with audit trail and kill switch | Scope limits, override latency, and who is accountable for an incorrect price |
This is AiESL’s framing, offered as a comparison tool rather than a standard. If a supplier disputes the level you place them at, that is a productive argument to have before signing.
Two observations worth sitting with.
Level 1 is not a failure. Most of the measurable benefit of electronic labels — the labour saving and the elimination of shelf-versus-register mismatches — is captured at Level 1, with no model anywhere in the system. Our work on pricing accuracy and on calculating payback both rest on Level 1 mechanics. If a supplier tells you the business case depends on the AI layer, ask them to show you the case without it.
Level 2 is where most operations should stop, at least initially. Rules are deterministic, explainable to a regulator, and debuggable by your own team at two in the morning. “Mark down this category 30% four hours before expiry” captures a large share of the perishable opportunity and requires no model at all. Reaching for Level 3 before Level 2 is running reliably is the most common sequencing mistake we see.
The four layers of an AI ESL system
Whatever level you operate at, the same four layers are present. What changes between levels is only how much decision-making sits in the second one.
- Data inputs — product, price and stock from your ERP and POS, plus demand history and, if you use it, competitor data. How this connection is built, and what breaks it, is covered in connecting ESL to POS, ERP and databases.
- Decision layer — at Level 1 this is a pass-through. At Level 2 it is your rule set. At Levels 3 and 4 it is a model evaluating margin targets, elasticity, expiry windows and competitor moves. The mechanics of that loop are in how AI dynamic pricing works.
- Approval and guardrails — which changes run automatically, which need sign-off, and the floor prices and margin limits nothing may cross. This layer is the one buyers under-specify and later wish they had not.
- The shelf edge — approved prices propagate to every connected label through gateways, normally in under a second. How many labels one gateway can actually serve in your update window is a separate sizing question, covered in gateway capacity.
What the engine decides — and what it does not
The most common misunderstanding is about scope. People hear “AI pricing” and picture a system setting every price in the store from first principles. That is not what any deployed system does, and it is not what you would want.
| The engine typically does | The engine typically does not |
|---|---|
| Time markdowns on perishables against expiry and remaining stock | Set your base pricing strategy or brand positioning |
| Propose competitive responses within limits you defined | Decide which products to stock, or negotiate with suppliers |
| Flag prices that look wrong against their own history | Fix bad master data. A wrong price in your system stays wrong |
| Sequence and schedule promotional changes | Invent promotions your commercial team has not approved |
The third row matters more than it looks. Electronic labels are faster and more consistent than paper, which means an error in your price master reaches every facing in every store immediately and identically. Automation does not improve data quality — it removes the delay that used to let someone catch the mistake. That is a good trade, but only if you treat your price master as the critical system it has now become.
What has to be true before it is worth buying
Most retailers asking about AI pricing are not yet in a position to use it, and the honest answer is to fix the prerequisites first. Four things have to hold:
- One authoritative price source. If pricing currently lives in several places that disagree, an engine will faithfully automate the disagreement. Consolidate first.
- A working integration. The engine needs current product, price and stock data. If your stock figures are unreliable, expiry-based markdowns will be too.
- Enough price-change frequency to matter. A store that re-prices a handful of lines a month has little for a model to optimise. The same variable also decides your payback, which is why the ROI calculator asks for it first.
- Someone who owns pricing policy. Guardrails are a commercial decision, not a technical setting. If nobody in the business can state the floor price for a category, there is nobody to sign off what the engine may do.
If those four hold, Level 2 is usually reachable quickly and Level 3 is a sensible next step. If one or more does not, the productive project is that one — not the AI layer.
Which claims are evidenced, and which are not
We have written elsewhere that the three benefits usually sold together rest on very different quality of evidence. That applies with particular force here, because the AI layer is attached to the weakest of them.
| Claim | Level required | Evidence |
|---|---|---|
| Less manual re-pricing labour | Level 1 | Modellable and reproducible. Arithmetic with visible assumptions |
| Fewer shelf-versus-register mismatches | Level 1 | The problem is measured by regulators; the fix is structurally sound but has not been measured against paper in any official study |
| Margin uplift from better-timed markdowns | Level 2–3 | Plausible, operation-specific, rarely published. Measure it in your own pilot |
| Margin uplift from demand-based optimisation | Level 3–4 | The least evidenced claim in the category. Treat any vendor percentage as a hypothesis |
The pattern is uncomfortable for anyone selling the AI layer, including us: the benefits with the best evidence need the least intelligence. The right conclusion is not that the AI layer is worthless — it is that it should be justified by a measured pilot in your own stores, while the Level 1 case carries the investment. The full argument for that sequencing is in how to calculate ESL ROI.
What AI ESL is not
It is not personalised pricing, and the distinction is legal as well as ethical. Dynamic pricing means the price on the shelf changes over time; every shopper standing in front of that shelf sees the same number. Personalised pricing means different shoppers are quoted different prices for the same item based on profiling. Electronic shelf labels are physically incapable of the second thing — a shelf-edge display shows one price to whoever walks past.
This matters because the two get conflated in press coverage, and because they sit in different regulatory positions. In the EU, Directive (EU) 2019/2161 amended consumer protection rules to require that traders inform consumers when a price has been personalised on the basis of automated decision-making. Shelf-edge dynamic pricing is not that — but if a system ever did tie a price to an identified shopper, a disclosure duty would attach. Worth knowing which side of the line your roadmap sits on. The European Parliament’s study on personalised pricing sets out the distinction in more depth.
It is also not a black box, and should not be bought as one. Good systems are rule-bounded: you set the limits, every change is logged, and most price moves still pass through human approval. The AI proposes; your policy disposes. And it is not a substitute for judgement about shopper perception — the reaction to large retailers adopting electronic labels has been about trust, not technology, as we covered in the Walmart rollout analysis.
How to govern it
Pricing automation is a governance problem wearing a technology costume. You do not need a bespoke framework for this; a published one will do.
The NIST AI Risk Management Framework, released in 2023 and voluntary, organises AI risk management into four functions — Govern, Map, Measure and Manage — and is deliberately general enough to apply to a shelf-pricing engine. NIST has indicated the framework is being revised, so check the current version, but the structure translates cleanly:
- Govern — who owns pricing policy, who may change guardrails, and who is accountable when a price is wrong.
- Map — which categories are in scope, what the engine is allowed to optimise, and what the failure modes are.
- Measure — how you will know the AI layer is adding value, decided before go-live rather than after.
- Manage — the override path, the kill switch, and how an incorrect price is corrected and reported.
If you cannot answer the Govern questions today, you are not ready for Level 3 — regardless of what the software can do. That is a conclusion against our own short-term interest, and we would rather state it than deal with the consequences of not having.
Is it right for your stores?
| Your situation | Sensible target | Why |
|---|---|---|
| Multi-store, thousands of SKUs, frequent price changes | Level 1 now, Level 2 within months | The labour and accuracy case alone usually justifies it; rules capture most of the rest |
| Significant perishable or short-shelf-life range | Level 2, then pilot Level 3 on one category | Expiry-driven markdown is the clearest margin opportunity and the easiest to measure |
| Small estate, low price churn | Level 1 | Little for a model to work with. Revisit when churn or wage costs rise |
| No single price source, or unreliable stock data | Fix that first | Automation will propagate the existing inconsistency faster and more consistently |
Because the platform runs on open middleware, you can start at Level 1 on hardware you already own and add the decision layer later — which is the sequencing we would recommend even if it were not our own architecture. If you are choosing between hosting the software yourself or using a vendor cloud, the control and continuity questions are in cloud versus your own server.
The vocabulary, in plain terms
Most confusion in supplier conversations comes from a handful of terms used loosely. These are the ones worth pinning down before a demo.
| Term | What it actually means | Why it matters to you |
|---|---|---|
| Price master | The single system your business treats as authoritative for what a product costs | If you have more than one, you do not have a price master. Everything downstream inherits the disagreement |
| Guardrail | A hard limit the engine may never cross — floor price, ceiling, maximum change per day | This is a commercial decision, not a setting. Somebody in the business has to own the numbers |
| Elasticity | How much demand for an item moves when its price moves | Models lean on it heavily. Ask what data it was estimated from — and whether that data came from your stores |
| Closed loop | A price change that reaches the shelf without a human approving it | The single most important thing to establish. Ask which categories are closed-loop and who can stop it |
| Human in the loop | A person approves each change before it ships | Slower, and usually the right default for a first deployment |
| Audit trail | A record of every price change: what, when, why, and on whose authority | Your evidence if a price is challenged. Verify you can export it without vendor help |
| Dynamic pricing | The shelf price changes over time; everyone sees the same number | What shelf labels do |
| Personalised pricing | Different shoppers are quoted different prices from profiling | Not what shelf labels do, and regulated differently. Do not let the two be blurred in a demo |
The AI ESL reference map
This page is the concept. These are the specifics, grouped by the decision you are making.
| If you are working out… | Start here |
|---|---|
| What the hardware is and does | What are electronic shelf labels · Types of ESL |
| Whether the numbers work | Calculating ESL ROI · ROI calculator · What ESL cost |
| What it replaces | ESL vs paper labels · Pricing accuracy evidence |
| How the pricing engine works | AI dynamic pricing with ESL |
| How it connects to your systems | POS, ERP, API and database integration · Cloud vs your own server |
| How to size the deployment | Labels per gateway · Coverage planner · Battery life |
| Whether to avoid lock-in | Open vs closed ESL systems · Comparing manufacturers |
| What it looks like in your format | Grocery · Warehouse · Pharmacy · Walmart case |
Sources
- AI Risk Management Framework — US National Institute of Standards and Technology. Voluntary framework released January 2023, organised around Govern, Map, Measure and Manage; NIST has indicated it is being revised.
- Directive (EU) 2019/2161 — EUR-Lex. Amends EU consumer protection rules, including the requirement to inform consumers where a price has been personalised on the basis of automated decision-making.
- Personalised pricing — study for the European Parliament, 2022. Background on the distinction between dynamic and personalised pricing.
- On the five-level scale: this is AiESL’s own framing, published as a comparison tool. It is not an industry standard and no body certifies it. We publish it because the alternative — comparing suppliers on the undefined phrase “AI-powered” — is worse.