RFP template for electronic shelf labels

A request for proposal (RFP) for electronic shelf labels is the document you hand to every vendor so that they answer the same questions, in the same format, on the same scope. This template organises it in eight sections: requirements, radio, integration, data, service levels, batteries and end of life, price breakdown, and references.

Use it before you ask for quotes. If you already have quotes, it still helps you see what each one leaves out. Everything below can be copied into your own document. The template contains no manufacturer-specific requirements, and this site is published by Keonex (a company that sells and installs electronic shelf labels), which did not design it to fit its own product.

How to use this template without turning it into paperwork

An RFP is worth writing only if it changes what you get back. Three ideas before you fill it in.

Describe your situation, not your solution. “We need 2.9-inch labels” is a solution. “We have 40,000 SKUs, chillers at -20 °C and a POS that exposes no API” is a situation, and it lets the vendor show they can handle it. If the first feels more comfortable, you probably have not done the needs assessment in the implementation guide yet.

Ask what can be checked. Words like “robust” or “scalable” cannot be scored. “State the maximum number of labels per gateway according to the datasheet and attach it” can.

Demand the same format. Each section below ends with a response instruction: a table, a yes/no with an annex, a figure with a unit. Leave answers as free text and comparing them becomes archaeology.

The numbers you put in the price section should come from your own earlier calculation; if you do not have one, start with the total cost calculator. The other tools are listed in the tools index.

Document structure

Before the eight technical sections, the RFP needs a short operational cover:

A practical rule: run a question round with shared answers. If one vendor asks something and only that vendor gets the reply, you end up with offers against different documents.

1. Solution requirements

Here you fix what the system must do, not how. Split it into must-have and nice-to-have; mixing them lets every vendor comply with “almost everything”.

What you provide: estimated number of labels per store and shelf type, size mix if you know it, environmental conditions (minimum temperature in chillers, humidity, direct light), whether there are variable-weight products or unit-price display, and the languages and scripts that must render on screen.

What you ask the vendor:

Real ranges of sizes, colours and display types are described on the technology page; use them to spot unusual answers. And if your plan includes showing the previous price during sales, add an explicit requirement: the platform must keep the price history needed to prove it, in line with Directive (EU) 2019/2161 as published on EUR-Lex. Each member state transposes that directive in its own way, so check the national rule that applies to your stores.

2. Radio and coverage

This is where a weak RFP costs the most, because radio is the least visible part and the hardest to fix once the installation is done. The general overview of the sector describes it as a balance between range, speed, battery life and reliability; your RFP should force each offer to say where it sits.

What to ask:

• Technology and band. Radio protocol, frequency band, and whether it is standard or proprietary. A Bluetooth profile for electronic shelf labels exists, published by the Bluetooth SIG, but that does not mean one manufacturer’s equipment talks to another’s: get it in writing.
• Coverage survey. Who performs it, with what method (site visit, floor plans, measurements) and what it delivers: gateway map, safety margin, critical zones.
• Number and position of gateways. Proposed quantity per store, power (PoE or mains), cabling required and who installs it.
• Capacity. Maximum labels per gateway and time to complete a bulk update, with the starting assumption (for example, how many labels change at once).
• Coexistence. How it behaves next to Wi-Fi, other Bluetooth equipment, refrigeration machinery and metal displays in your store.
• Coverage guarantee. A written commitment that, if labels fall outside coverage after installation, the vendor adds gateways at no extra cost.

If a vendor will not commit to coverage before seeing the store, that is a reasonable answer; quoting a fixed price without that visit is not. The pilot project exists partly to confirm in your own store what the survey predicted.

3. Integration with your systems

The label displays what the system sends it; the real problem is how that data travels from your ERP or POS. This section is completed with your IT team, not procurement.

Describe your environment before asking: ERP, POS and versions, where the master price lives today, how often it changes, whether prices vary by store or zone, and whether the system exposes an API, files, a database or none of those.

What to ask:

Ask for integration references with your same system, not “similar systems”. And ask what happens when your ERP is upgraded: if every version change means a paid project, that cost belongs in the offer. The principle guiding your team should be consistency between shelf and checkout, covered in till price differs from shelf price.

4. Data ownership and portability

This section tends to be left to the end of the negotiation, and it is the one that weighs most when you want to change vendor. The label platform accumulates your catalogue, your templates, the label-to-product pairings and the change history. Who owns that, and how you leave with it, must be written down.

What to ask:

• Ownership. The RFP should state that the data is yours and the vendor processes it only to provide the service.
• Location and processing. Where it is hosted (country or region), which sub-processors are involved and with what safeguards. If the platform holds personal data (system users, for example), your legal team should review the data processing agreement.
• Export. Open, complete format, including templates and pairings, not just the price catalogue. Ask whether it is a platform feature or a service on request, and what it costs.
• Exit. Deadline for handing over the data at termination, deadline for subsequent deletion, and written confirmation.
• Switching provider. If the platform is a cloud service, it may fall under the switching rules of the EU Data Act (Regulation (EU) 2023/2854, EUR-Lex), which according to a Wikipedia summary started to apply on 12 September 2025 and provides for switching charges to be abolished on 12 January 2027. Whether it affects your contract is for your legal advisers; the RFP only needs to ask the vendor to state its position.
• Security. User authentication, access logs, backups and what happens in an incident. A simple question: can they give read-only access to one of your auditors?

5. Service levels (SLA) and support

Manufacturers advertise availability but rarely say what happens when it is missed. An SLA without consequences is an intention.

A question that helps separate proposals: what happens if the system goes down on a Saturday at ten in the morning with a promotion running? Ask for the answer to describe the procedure, with role names, not just a phone number.

6. Batteries and end of life

Labels run on batteries, and the lifetimes manufacturers quote depend on how many daily updates they assume. The technology page collects the published ranges; your RFP should ask for figures with assumptions, not general promises.

What to ask:

• Battery life per model, with the number of updates per day, the temperature and the display type it was measured with.
• Battery type and whether staff can replace it or the whole label must be swapped. Regulation (EU) 2023/1542 governs the design and waste management of batteries, including replaceability of portable batteries with its exceptions (EUR-Lex); ask the vendor to declare how it applies to each model, without assuming that it does.
• Warning. Whether the platform shows battery level and alerts in advance, and how far ahead.
• Warranty. Length of the label warranty, whether it covers the battery, and what counts as normal use.
• Replacement. Who swaps exhausted labels or batteries, within what time, and at whose cost after the warranty.
• Take-back and recycling. Who collects used equipment, with what documentary proof, and whether the cost is included.
• Platform lifespan. Until when the vendor commits to keep compatibility with the models you buy. A label that lasts ten years is of no use if the software stops supporting it after five.

To compare with leasing, a rental with replacement included changes this whole section; both schemes are explained in rent or buy.

7. Price breakdown

Ask for the offer in a fixed structure, and reject single-figure offers. If each vendor groups costs differently, you cannot tell where the differences lie.

Also request a five-year and a ten-year scenario in the same structure, and the assumptions for price updates (revision clauses) in writing. With those figures you can feed the total cost calculator, which compares buying and renting using your own assumptions. One point to make clear in the RFP: the prices in the document are for evaluation; the contract must contain the final ones.

To see which ranges are reasonable, the vendor comparison describes who is who in the market, though it does not replace offers. Prices circulating online are not a binding reference.

8. References

A reference is worth something only if you can call it. This section must require references that are verifiable and relevant to your case.

What to ask:

• Three to five customers with a profile similar to yours (sector, size, pricing system), with a contact who agrees to talk.
• Installation date and number of stores and labels in each; ask them to distinguish pilot from roll-out.
• Which integration they use and who developed it.
• One reference that had problems and how they were solved; a vendor with none is probably not telling you everything.
• Permission to visit an installed store, if the customer agrees.

Questions for the reference call: how long it took to stabilise, what was not in the offer and appeared later, how support works in practice and whether they would buy again. Record the answers with the same script for every call.

Evaluation: how to score the answers

Set the weights before you receive offers. A starting split, to be adapted:

These are example weights, not a recommendation of this site. A store with heavy refrigeration will raise radio; a chain with its own ERP will raise integration. What matters is that they exist before the envelopes are opened. For finalists, the next step is the pilot, with written success criteria, before signing the roll-out.

What a legal adviser should review

The template organises technical and commercial information; it is not a contract. Before signing, have a lawyer review: the data ownership and processing clause, liability for pricing errors, exit conditions and payment terms. If you buy with public funds or grants, specific procurement rules apply that this template does not cover.