Smart Glasses for Field Service

The client is a US perimeter security integrator. It designs, installs and services vehicle barriers, barrier arm gates and the control electronics that run them, across several states. I have left the company name out.

Their technicians handle preventative maintenance, repairs and emergency call-outs on barrier systems from many manufacturers, PLC electronics included. The work is outdoors, in hard hats and gloves, often with one technician or a small crew on site. When something unfamiliar turns up, the fastest fix is usually a senior colleague who has seen it before. In the existing workflow that colleague is on the phone, trying to picture what the technician is describing.

What they asked for

In March 2026 their team came to me wanting smart glasses. A technician would start a Microsoft Teams or Zoom call hands-free, and a senior expert back at base would see what the technician sees and talk them through the install, the maintenance visit or the repair. Sessions would be recorded for training and quality control.

We had two discovery calls and I sent a proposal. After a call with their leadership we split the work into phases. The first phase had a fixed scope. I would recommend the hardware and prepare a pilot the client could run themselves. It ran from late April to late May 2026 and produced two documents.

Scoping out AR

Most smart glasses marketing is about augmented reality, with see-through displays, overlays anchored to equipment and AI that recognises parts. The technicians needed none of that. They needed a steady forward-facing camera and audio that works on a noisy site, and the call has to connect the first time with gloves on. If a senior expert can watch the gate operator’s wiring live, that solves the problem they described. An overlay adds cost and complexity to the call.

I wrote the scope around remote video and listed AR overlays, work-instruction apps, computer vision and on-device AI as out of scope for the pilot. I also rejected immersion-first and consumer devices up front, along with anything discontinued or without an IP rating. That removed several candidates early, some of them well-known products that are no longer made.

Setting the criteria

Two criteria carried the most weight. One was how useful a device is on a live video call. The other was how it behaves with PPE, which meant mounting to the hard hats the crews actually wear, working by voice and buttons with gloves on, and fitting alongside safety glasses and hearing protection. Battery life, outdoor durability, workflow simplicity and future fit made up the rest.

A single failed troubleshooting visit or repeat call-out typically costs more than the price gap between devices on the shortlist, so I weighted the criteria toward field use.

On battery, rated runtime and runtime on a continuous video call are not the same number, so I treated hot-swap as the fix and made actual runtime something the pilot had to measure. Hard-hat mounting needed its own procurement work, since one vendor offers dozens of clip designs because helmets differ by brand and country. Extra cables and pocket units snag on gate arms or get left in the van. Microsoft had also ended support for its own Teams client on one platform, so sign-in and tenant compatibility had to be confirmed before anyone placed an order.

I also went through the public user feedback on each shortlisted device. There is very little, because most candid feedback on enterprise devices stays in private channels, so the report kept verified facts apart from vendor claims and from questions only the pilot could answer.

What I recommended

RealWear’s Navigator 520 was the baseline. It is voice-first and built for hard-hat use, has a hot-swap battery, and comes with a mature Teams ecosystem and a documented field record. A Vuzix headset was the lighter alternative, worth testing because full-shift comfort matters and its Teams and Zoom remote-assist kit had launched earlier in 2026. I kept the shortlist to two so the pilot could compare them head to head.

The report also warned that industrial wearable rollouts most often fail when the hardware is bought first and an owner is found afterwards. It described the internal pilot owner the client needed, someone senior enough for the decision to stick and hands-on enough to fix a failed sign-in, and recommended pausing rather than buying if nobody fit. The test plan defined KPIs to compare against the existing phone-based workflow. The decision rule at the end is to pick the device the technicians do not complain about after two weeks of real use.

The follow-up addendum

After reading the report, the client’s team asked what happens once the boxes arrive, how small an order could still give a real answer, and where the video and recordings live. I answered in an addendum instead of reopening Phase 1. It includes a week-by-week sequence from first vendor contact to a decision gate, and what each of the client’s proposed changes to the pilot would mean operationally.

It also says what Phase 1 let the client do on their own and what needed vendor support. Fleet device management, recording retention and linking sessions to field-service tickets are later architecture work. I put that in writing so the pilot would not drift into an integration project.

After delivery

Once the client started buying, they could not get a response from the alternative vendor for two weeks. Pilots often stall this way, with the team waiting for a second quote so the comparison is fair.

I advised them to go ahead with RealWear alone and to count vendor responsiveness as part of the evaluation. I did not want one slow vendor to hold up the pilot. RealWear on its own could still answer the main question, which is whether a hands-free call works on a real site with PPE on.

Where it stands

The client accepted both deliverables, bought RealWear hardware and started an internal pilot in summer 2026, run by their own team. In July they told me it was in its initial stages and needed no further support from me. There are no pilot results yet.

I did not build hardware, write software, deploy devices or run the pilot. The engagement was short and fixed-scope, and it ended with the two documents.

How I work

I work in fixed phases. Here, Phase 1 answered which hardware to buy and how to test it, and nobody had to commit to integration work before the basic call-and-record loop had worked on a real site. I run hardware prototype to production work the same way, testing first what has to hold up in the field.