Most ESL projects fail before the first label goes up on a shelf. Not because the technology does not work. Because the project was scoped as a pricing project when it is actually a store operations project, because the network and infrastructure prerequisites were underestimated, or because the hardware vendor was signed before the integration vendor was evaluated.
I led a Vusion ESL deployment across 300+ locations that reached near-100% pricing accuracy and saved 18 to 22 labor hours per store per week. The outcome was good. The road to it was not as clean as the demos suggested. The deferrals I had to make (like pulling an availability indicator off the label until the upstream availability pipeline was ready, and standing up an interim tablet solution instead) were the kind of decisions that do not appear in any procurement scorecard but land squarely in year-one operational reality.
This guide covers the three platforms most commonly on the shortlist for North American multi-site retail, the evaluation framework I would use today, and the procurement mistakes that kill ESL programs before they scale.
Why ESL projects fail before they start
Treating ESL as a pricing project. Procurement buys the platform. Merchandising scopes the pricing workflows. IT handles the integration. Nobody scopes store operations: installation load, exception handling when a label will not update, shelf resets during planogram changes, battery replacement on the cadence the vendor documented versus the cadence the stores actually experience. The labor model is the single largest driver of ESL success or failure in years two and three, and it almost never gets the attention it needs during selection.
Underestimating the network and infrastructure prerequisites. ESL platforms run over proprietary RF networks, gateways, and in some cases back-end connectivity that has to coexist with the existing store network. The pilot store usually has current infrastructure. The chain does not. Rollout hits stores with older switches, WiFi contention, and building materials (thick concrete, structural steel) that the pilot never tested. Network readiness is a separate workstream that needs its own budget and timeline.
Signing the hardware vendor before the integration vendor. The ESL platform is the hardware and the management software. The integration that pushes pricing, promotional overlays, compliance information, and availability data from the source systems (ERP, POS, merchandising, OMS) to the ESL management layer is almost always a separate vendor or in-house build. Signing the hardware vendor without scoping the integration work produces a timeline gap that surfaces as the first chain-wide delay.
The three platforms
Vusion (SES-imagotag)
Most mature in North American retail, deepest integration ecosystem, highest price. Vusion is the incumbent on most shortlists for multi-site retailers over 100 stores, and the reference checks are easy to find because the deployed base is broad.
The operational note I would pass to anyone selecting Vusion: the Phase 1 to Phase 2 path matters. Phase 1 is usually price labels, promotional overlays, and compliance tags, which the platform handles well out of the box. Phase 2 is where the platform earns its price: QR code integration, availability indicators, location-aware workflows, planogram integration. Those capabilities exist and they are deployable, but they require an engineering intake process on the Vusion side that needs to be scoped into the program, not bolted on at go-live. I have watched retailers defer Phase 2 capabilities until the upstream systems (in my case an availability data pipeline that was not ready) caught up, which is the right call even if it is not the answer in the vendor’s roadmap deck.
Template architecture is the other underappreciated decision. Vusion templates can be managed at the corporate level, store level, category level, or by SKU attribute. Deciding who owns templates and at what level they are governed is a decision that looks small in selection and large in operations. Chain-wide template sprawl is a real outcome when the governance is not explicit.
Hanshow
Strong global footprint, aggressive pricing, and the technology itself is credible. The honest question with Hanshow in North America is the integration and support maturity at the scale most multi-site retailers need. Reference deployments exist in the region but are shallower than Vusion’s, and the partner ecosystem for integration work is thinner.
I would consider Hanshow as a serious contender when the integration surface is relatively clean (fewer source systems, cleaner product data, less reliance on custom promotional overlays), when the hardware refresh cadence can be modeled against the vendor’s roadmap rather than a decade-plus incumbent footprint, and when the retailer has enough internal technical capacity to absorb the integration work rather than relying heavily on partner ecosystem depth.
The pricing conversation with Hanshow is usually more aggressive than with Vusion, which matters at scale. The pricing conversation is also rarely the decisive factor at the 5-year TCO level, because the hardware is consistently one part of a larger envelope.
SOLUM
The challenger. Technology is credible, the engineering is sharp, and the platform has deployment references in North America that have held up. The honest question is the bench depth: deployment scale, partner ecosystem, and the length of the reference list for multi-site retail specifically. These are bench-depth questions, not technology questions.
I would consider SOLUM when the retailer has internal integration capacity, is comfortable with a challenger ecosystem, and values a platform that is still small enough to have direct engineering engagement from the vendor during the rollout. That last point matters more than it sounds. With Vusion, the engineering attention goes to the largest customers. With SOLUM, a mid-market multi-site retailer can often get engineering attention that a Vusion deployment of the same size would not command.
Evaluation framework
Six decisions decide which platform fits. None of them are on the typical RFP scorecard, and all of them matter more than the feature checklist.
Integration model: edge versus cloud. How does the ESL system consume pricing, availability, and promotional data? Does it run against a local cache at the store or against a centralized cloud service? The answer shapes network resilience, outage behavior, and the degree to which each store is self-sufficient during connectivity issues.
QR code strategy. Are QR codes static product identifiers, dynamic payment and financing offers, or a mix? Dynamic QR codes have integration implications that static codes do not. I have worked through QR code integration constraints involving rotating codes from payment financing partners (the kind that rotate every few minutes for anti-fraud reasons), which do not fit a standard ESL template management model and need to be scoped explicitly.
Template governance. Who owns templates, at what level (enterprise, region, category, SKU), and how does template change propagate to stores? The answer determines whether the ESL platform scales cleanly across 300 stores or accumulates template sprawl by store two hundred.
Hardware refresh cadence. ESL hardware has a lifecycle. Batteries fail. Display drift occurs. Form factors evolve. The refresh cadence needs to be modeled into the 5-year TCO and the labor model. Retailers who do not plan for refresh discover year-four surprises that were foreseeable at selection.
Labor model. Installation, label replacement, exception handling, battery replacement, planogram reset participation. The labor model decides whether ESL is a net labor save (as it was in my Vusion deployment: 18 to 22 hours per store per week) or a net labor add. The difference is in the procurement scope and the store operations readiness.
Store-level support escalation path. When a label fails mid-sale, who gets the call, what is the SLA, and is the SLA structured at the label level, the category level, or the store level? This decision is usually deferred to the implementation phase, which is where it becomes expensive to correct.
Ten demo questions
Force every serious vendor demo into the retailer’s actual scenarios, not the vendor’s sandbox. Ten questions that surface the decisions a scorecard will not.
Walk me through a price change from the ERP to the shelf edge, end to end. Test the integration architecture and the latency profile.
Show me how promotional overlays behave when the same SKU is on promotion in two stores at two different prices. Test the template and pricing data model.
Demonstrate what happens when the store loses backend connectivity for four hours during a promotional weekend. Test offline behavior and local cache strategy.
Show me the label behavior when the battery is at 20% remaining capacity. Test the refresh cadence and the maintenance operational model.
Walk me through a planogram reset in a representative store. Test the labor model for shelf moves, relabeling, and verification.
Show me the integration with a dynamic financing offer that rotates every three minutes. Test QR code integration and template flexibility under real payment-financing partner constraints.
Demonstrate the audit trail for a price change that went to the shelf but did not match POS. Test the reconciliation capability, which matters operationally when a customer points at a label.
Show me how templates are managed at the enterprise level and overridden at the category or store level. Test the governance model.
Walk me through the rollout plan for 250 stores starting from three pilot sites. Test the vendor’s actual experience with multi-wave rollouts, not the marketing case study.
Show me a post-go-live operations report from a comparable retailer. Test willingness to share real data, which is the single most reliable signal of what the relationship will feel like in year two.
Procurement mistakes
Locking the hardware vendor before the integration vendor. The integration work is usually 25 to 35% of the 5-year envelope. Signing the hardware contract first removes the negotiating position on the integration scope.
Treating rollout as IT’s problem rather than store operations’. The rollout is labor-intensive at every store. If store operations is not a named owner, the labor cost surfaces as variance against plan rather than as scope.
Ignoring the template governance question until go-live. Template sprawl accumulates fast. The governance model has to be explicit before store one goes live.
Underestimating store labor for exception handling. A small percentage of labels will misbehave on any given day. At 300 stores with 8,000 labels per store, the aggregate exception volume is substantial. If the labor budget does not contemplate it, stores find time by pulling from other tasks that now get underdone.
Signing a multi-year hardware deal before a seasonal pilot cycle completes. ESL behavior in a representative store during a peak sale cycle is different from ESL behavior in the same store during a normal week. Signing before the pilot has seen a full seasonal cycle means the TCO model is incomplete.
Post-selection quality signals
Four signs the implementation is on track by day 90.
The integration runs without manual reconciliation between ERP and shelf edge. If a category manager is manually adjusting pricing overlays daily, the integration is not production.
Exception volume trends down after the first 30 days in each new wave. Flat or rising exception volume beyond 30 days usually indicates a structural issue rather than a settling curve.
Store associates know the escalation path and use it. If exceptions are being absorbed quietly by associates working around the platform, the visibility is wrong and the operational reality is drifting from the reported state.
Template governance is holding. Template count is stable or declining as duplicates get consolidated. Template count growing faster than SKU or category growth is the early signal of sprawl.
Frequently asked questions
Which ESL platform is the right choice?
No single answer. Vusion is the most mature in North America, with the deepest integration ecosystem and the highest price. Hanshow has a strong global footprint and aggressive pricing, with honest questions around North American support maturity. SOLUM is the credible challenger, technology-solid but with a shorter bench of multi-site retail references in the region. The right answer depends on integration surface, hardware refresh appetite, and how patient you can be with a challenger ecosystem.
How long does an ESL rollout typically take?
Pilot phase is 2 to 4 months. First wave of production stores is another 3 to 6 months depending on network readiness and store-labor load. Chain-wide rollout across 200+ stores commonly runs 12 to 18 months. Shorter timelines usually indicate either a single-category rollout or a rollout that is going to hit network and support issues at scale.
What is the true TCO for ESL over 5 years?
Hardware is 30 to 45% of the 5-year envelope. Integration and software is 25 to 35%. Store-level labor for installation, label replacement, and exception handling is 15 to 25%. Ongoing support and battery replacement in years three through five is the remainder. Most procurement models focus on the hardware number and underweight the labor and integration, which is why post-pilot budgets often need to be revisited.
The ESL platform you choose matters less than the operational scoping around it. A good selection of the wrong platform produces a deployment that will frustrate stores for a decade. A clean selection of the right platform, scoped with honest labor modeling and an explicit governance model, produces the near-100% pricing accuracy and the 18 to 22 labor hours per store per week that make the business case real. The difference between the two outcomes is rarely the vendor.