SAP says both smart glasses pilots ship by year end

EssilorLuxottica is running two Joule use cases through smart glasses, and one will be much harder to ship than the other. SAP's own account of the work, by Stefanie Glenk and published September 21, 2026, says both are in a test phase, both were developed in two weeks, and the teams are targeting commercialization of both pilots by the end of the year.

The company owns Ray-Ban, Oakley, Varilux and Crizal along with retail banners including Sunglass Hut, LensCrafters, Vision Express and Apollo, and runs 15,000 stores on SAP S/4HANA Retail. The first use case gives field technicians real-time guidance and documentation support. The second lets a retail-floor associate reach customer profiles, order history, inventory and ordering by natural voice.

This is a first-party SAP publication about a project SAP is a partner in, so weigh it accordingly. It carries no named executive quotes, and the end-of-year commercialization target has no independent confirmation. Read it for what was built and hold the date loosely.

Two weeks buys a demo, not a rollout

The two-week figure is believable, and it tells you less than it sounds. Joule already carries the connectors and the language handling. A small team with a retail S/4HANA system, a device and a tight script can get a working flow in front of an audience inside a fortnight. Nobody is overstating anything by reporting that.

What two weeks does not buy is the work filling the other eleven months. Device management across a 15,000 store estate. Network behaviour in a shop with thick walls and shared wifi. What the glasses do when a session drops halfway through an order. Audio quality on a Saturday afternoon with three conversations inside a metre. A demo has one user, one store and one happy path.

So the fair reading of the two-week claim is that integration was never the risky part. Our guide on moving an agent pilot into practice covers what starts after the demo lands, and most of it has nothing to do with the model.

The technician case is the one with a clean path

Field technicians have both hands occupied and a machine in front of them. Reading a procedure off a phone means putting a tool down first. A wearable earns its place there without anyone arguing the business case, because the alternative is a printed sheet on the floor.

The data side is calmer too. The technician is looking at an equipment record, a service order and a documentation step, and the only person in the frame is the technician. Nobody outside the company is being recognised. That removes most of the argument before it starts.

Documentation support is the part to watch for quality rather than consent. Voice-captured notes written back into S/4HANA have to land on the right order with the right status, and a mis-heard part number becomes a wrong record somebody finds a month later. Same failure mode we flagged when Joule supplied business context to drones and humanoids.

Recognising a customer through a wearable is the hard part

The Sapphire Madrid demo had the glasses identify a returning customer and surface purchase history and add-ons. That is the moment a store associate stops being a person holding a tablet and becomes a person whose eyewear knows who you are. The SAP article describes the capability and says nothing about consent or notice.

How the glasses identified that customer is not stated, and the method changes the answer a lot. A 15,000 store network spans many jurisdictions with different rules. Some regulators will treat automated recognition of a named shopper as biometric processing needing an explicit legal basis. Works councils will have their own view on staff wearing a recording-capable device for a full shift.

None of that means the use case cannot ship. It means there is a body of work between the demo and the shop floor that the SAP article never mentions, and the people who will slow it down sit in privacy and legal seats rather than on the project team.

Voice is another headless path into S/4HANA

The architectural point survives whatever becomes of these two pilots. Joule on a pair of glasses is a client. What comes back is decided by the roles and authorisation objects you already have. Whatever an associate sees through the glasses is whatever that associate could already pull up on a store terminal.

That cuts both ways. If a store manager role quietly accumulated read access to customer data across a whole country because somebody widened an authorisation object in 2019 to close a support ticket, the glasses inherit that too, and now it is read aloud on a shop floor in front of the customer. The access was already wrong. The wearable makes it audible.

We made the same argument about headless access into Salesforce, and the SAP version has the same shape. Each new surface is one more consumer of an authorisation model designed when the only consumer was a screen with one person at it. Count your surfaces, then audit the roles behind them.

Ask who the glasses are allowed to recognise

Put the hardware and the model to one side. The question that decides whether it ships is what happens the moment the device identifies a person who never asked to be identified. Write down who that person is, what tells them it happened, which legal basis you rely on in each country, and what the device does when they say no.

Then run the two-week figure in reverse. If a working prototype took a fortnight, ask your team to name what the rest of the year is for. A list nobody can produce on request is a sign the pilot has not been scoped, and the end-of-year date is a hope with a calendar attached.

SAP's commercialization target is SAP's own statement about SAP's own project, with no second source on it, so file it with that caveat and check back in January. If the technician use case is live by then and the shop-floor one is still in test, you will have learned more than either pilot was designed to prove.