An electronic shelf label project can start too early. A retailer may already be collecting brochures, comparing label sizes, or booking vendor demonstrations while the harder questions are still unresolved: Which system is the source of truth for shelf prices? How are products identified at the shelf? Who owns exceptions? Which store types and fixtures must the system support? What evidence will make a pilot meaningful?
This page is a readiness checklist for the stage before vendor comparison. It does not rank ESL suppliers, score products, or build an RFQ. Its purpose is to help retail operations, IT, merchandising, and procurement create a stable project baseline so that later vendor answers are being compared against the same problem.
If your project already has a clear baseline and you are ready to evaluate solution options, use the electronic shelf label solution selection guide. If you are still defining the operating problem, data ownership, store conditions, and acceptance evidence, start here.
Use a readiness gate before you build a vendor shortlist
Readiness is not the same as having a budget or a target launch date. A project is ready for structured vendor evaluation when the buyer can describe the current workflow, the required outcome, the data path, the physical environment, the operating owners, and the conditions that must be proven before rollout.
| Readiness area | Ready enough to enter selection | Warning sign |
|---|---|---|
| Business problem | The team can name the shelf-edge process that needs to change and why | The project objective is only "go digital" or "match competitors" |
| Price and product data | The authoritative source and key identifiers are known | Different teams use different price files or item identifiers |
| Exception process | Overrides, failed updates, replacements, and urgent corrections have owners | The normal update path is defined but exceptions are not |
| Store environment | Representative fixtures, departments, temperature zones, and store variants are documented | The project assumes one shelf type represents the whole estate |
| Integration boundary | Source systems, interfaces, network ownership, and security stakeholders are identified | The buyer expects "API support" to resolve architecture later |
| Operating ownership | Merchandising, IT, store operations, support, and procurement responsibilities are named | Everyone supports the project, but nobody owns specific failures |
| Pilot baseline | The team knows which workflows and store conditions must be represented | The pilot is being planned as a product demo rather than a decision test |
A warning sign does not mean the ESL project should stop permanently. It means the uncertainty should be resolved or explicitly carried into the selection process instead of being hidden inside supplier assumptions.
Define the shelf-edge problem before you define the technology
Start with the current operating process. Map what happens when a price, promotion, product description, or shelf location changes today. Record the source of the change, who approves it, how it reaches the store, who updates the shelf, how completion is checked, and what happens when the displayed information is wrong.
This current-state map prevents a common planning error: treating an ESL as a replacement for a piece of paper rather than as one endpoint in a controlled retail data process. A store may need faster price execution, tighter alignment between systems and shelf displays, better promotion control, less repetitive printing and placement work, or more consistent multi-store execution. Those are different operating problems and they create different requirements.
Write the project objective in a form that can later be tested. "Install digital labels" is not an acceptance outcome. "Create a controlled path from approved product data to the correct shelf position, with visible exception handling and reconciliation" is much closer to one.
For the end-to-end update mechanics, the separate guide on how electronic shelf labels work from source data to a verified shelf update provides the technical context without turning this readiness page into a system-architecture article.
Lock the source of truth and the product-to-shelf identifier chain
Before asking a vendor how its platform integrates, the retailer should know which system is authoritative for each field that matters at the shelf. That may include selling price, unit price, promotional state, product description, barcode data, store-specific overrides, or other fields required by the retailer's operating model.
The next question is identity. What connects an item in the source system to the item the store intends to display at a specific shelf position? The answer may involve a retailer SKU, barcode, GTIN, internal location identifier, planogram reference, or a combination. The important point is that the mapping must be explicit and maintainable.
GS1 describes the GTIN as an identifier for trade items. A GTIN can therefore be part of a clean product identity chain, but the retailer still needs to define its own relationship among the trade item, store assortment, shelf position, local price, and label binding. An industry identifier does not by itself solve location or workflow ownership.
| Data question | Readiness output |
|---|---|
| Where does the approved price originate? | Named source system and data owner |
| Which identifier follows the product through the update flow? | Identifier map with examples from real assortment data |
| How is a physical shelf position associated with a product? | Binding or location process, including moves and replacements |
| Which store-level overrides are allowed? | Approved exception list and authority |
| What proves the shelf reflects the intended state? | Reconciliation or audit requirement |
If the team cannot answer these questions using a small sample of real data, vendor selection is likely to produce confident integration statements that are difficult to compare because each supplier is solving a different version of the data problem.
Map exceptions before you automate the normal path
A clean demonstration usually shows one correct product mapped to one working label. Retail operations are defined by everything that happens outside that normal path. Readiness work should therefore document the exceptions that the future system must expose and recover from.
- A price is approved upstream but the shelf display does not change.
- A product moves to a new shelf position.
- A label is replaced and must be rebound correctly.
- A promotion starts or ends while a local override exists.
- A store temporarily loses the path needed to receive new updates.
- The source data is correct but the template renders the wrong field.
- A staff member finds a shelf value that disagrees with the intended state.
For each exception, name the detection method, the owner, the allowed workaround, the escalation path, and the evidence needed to close it. This makes later vendor conversations much more useful. Instead of asking "Does the platform have monitoring?", the buyer can ask how the proposed system identifies and resolves the exceptions that already exist in the operating model.
Survey fixtures and store variants before you ask for label models
A product catalogue cannot tell you whether a deployment fits the actual estate. Build a representative physical inventory first. The goal is not to measure every shelf before the first vendor call; it is to identify the variants that could change mounting, readability, durability, communication design, installation effort, or operating procedure.
Useful survey categories include standard shelf rails, peg hooks, baskets, refrigerated and frozen areas, fresh-food fixtures, endcaps, promotional stands, unusual shelf lips, high-contact zones, and departments where customers or staff regularly move products. Record how much of the estate each variant represents and which variants must appear in a later pilot.
Do not force a universal ESL size range or environmental rating into the readiness document. The exact model and operating limits should come from model-level supplier documentation for the proposed configuration. The buyer's job at this stage is to describe the installed condition accurately enough that the supplier cannot assume a simpler environment.
Separate network readiness from a wireless-protocol preference
Retailers sometimes start with "We want Bluetooth" or "We do not want Wi-Fi" before documenting the network boundary. Protocol preference is not a substitute for architecture readiness. First identify how the store reaches the ESL management service, who owns the relevant network segments, which security reviews are required, where gateways or access points can be installed, and what happens when the upstream connection is unavailable.
The Bluetooth SIG publishes an Electronic Shelf Label Profile that specifies how a GATT client can control and update ESLs using Bluetooth. That is useful evidence that a standardized Bluetooth ESL profile exists; it is not evidence that every ESL platform uses that profile or that every implementation has the same network design.
Document the constraint before choosing the method. A readiness baseline might say that store IT requires managed network ownership, controlled outbound connectivity, named credential responsibility, documented logging, and a defined outage behavior. The supplier can then explain how its architecture meets those constraints.
Security requirements deserve their own review. The site's ESL cybersecurity procurement guide covers that deeper task; this page only requires the security stakeholders and review gates to be identified before selection.
Name operating owners before the system creates new work
ESLs can reduce some manual shelf tasks, but they also create a managed device and software process. The readiness question is not "Will labor go down?" It is "Which work changes, which work remains, and who owns the new exceptions?"
| Operating responsibility | Questions to settle before vendor comparison |
|---|---|
| Merchandising / pricing | Who approves source data, promotions, overrides, and template content? |
| Store operations | Who handles physical replacement, shelf moves, visual audits, and urgent corrections? |
| IT / integration | Who owns interfaces, credentials, monitoring, changes, and incident escalation? |
| Network / security | Who reviews connectivity, segmentation, access, logging, and supplier support paths? |
| Procurement / legal | Who owns scope, evidence, service terms, lifecycle obligations, and commercial changes? |
| Support | Who receives faults after go-live and how are unresolved cases escalated? |
A RACI chart can be useful, but only if it names real responsibilities rather than simply listing departments. If the buyer cannot say who owns a failed shelf update or a replacement label, that ambiguity will reappear later as a support or contract dispute.
Build a representative pilot baseline before the first demo
A readiness-stage pilot plan should define what must be represented, not yet prescribe a vendor's detailed test procedure. Choose store conditions that expose meaningful variation: different fixture types, departments, data flows, exception patterns, user roles, and network conditions that exist in the intended deployment.
The buyer should also decide what evidence will be needed to judge the pilot. Examples include an approved source-data change, a traceable product-to-label binding, an update record, a shelf verification, a deliberately induced exception, a recovery record, and ownership of any defect found. The exact metrics and acceptance thresholds should be defined later for the selected architecture rather than invented at readiness stage.
This distinction keeps the pilot from becoming a polished demo. A demo proves that the supplier can make the system work under a chosen condition. A decision pilot should prove that the proposed system can support the buyer's representative conditions and expose failures in a way the operating team can manage.
Create a readiness dossier that every vendor receives
Before structured solution selection begins, package the baseline into a small set of artifacts. Vendors should not need to discover fundamental project facts independently and then price different assumptions.
- Current-state workflow: how shelf data changes today, including approval and verification.
- Source-of-truth map: authoritative systems, data owners, identifiers, and known overrides.
- Exception register: important failure and recovery scenarios with owners.
- Store-variant inventory: representative fixtures, departments, environmental conditions, and physical constraints.
- Architecture boundary: systems to integrate, network/security stakeholders, buyer-provided infrastructure, and known constraints.
- Operating responsibility map: who owns data, hardware, software, support, security, and store actions.
- Pilot baseline: representative conditions and the evidence the buyer expects to collect.
This dossier is deliberately not an RFQ. It gives every supplier the same starting facts. After a shortlist exists, those facts can be converted into formal proposal requirements, commercial boundaries, evidence requests, and acceptance obligations.
Use Green, Amber, and Red as a decision gate
A readiness gate should be simple enough to drive action. Avoid a false-precision score. Classify each readiness area by whether the buyer has a stable answer, an explicitly owned uncertainty, or a blocking gap.
| Status | Meaning | Action |
|---|---|---|
| Green | Baseline is documented and the owner is clear | Carry the requirement into vendor selection |
| Amber | Uncertainty remains, but it has an owner and a plan to resolve it | Make the uncertainty visible in vendor questions and pilot scope |
| Red | The missing answer would make supplier proposals fundamentally incomparable or make acceptance impossible | Resolve the gap before treating vendor selection as decision-ready |
Typical red conditions include no agreed source of truth for shelf prices, unstable product-to-shelf identification, no owner for pricing exceptions, an unrepresented store environment that materially changes installation, or no agreement on what evidence will prove a successful pilot. Those are project-definition problems, not vendor-selection problems.
What should happen after readiness is clear?
Once the baseline is stable, the next task is to compare solutions against it rather than restart discovery with every supplier. The ESL solution selection guide covers that next stage. Teams that need broader system context can also review the electronic shelf label solution framework.
The practical boundary is simple: readiness defines the problem and the evidence you need; selection compares solution options; procurement converts the shortlist into contractual scope; implementation proves the chosen design. Keeping those stages separate makes every later decision easier to compare and easier to audit.
