QR Codes on Equipment: Manuals, Service History and Asset Tags
Start with the thing that is true and gets glossed over in every pitch for this: a QR code does not store anything. It is a printed address. Scanning the label on a boiler does not retrieve its service history — it opens whatever page you pointed the code at, and if that page does not exist, or nobody has updated it since 2019, the code has faithfully delivered you to nothing.
That is not a criticism of the idea. The idea is genuinely good, because the problem it solves is real and boring: the engineer standing in front of the machine does not know which manual, which serial, which spreadsheet tab or which filing cabinet. One scan replaces all of that. But the value is entirely in what you point at, which means the work is document work, not QR work. This site makes the code. The record lives wherever you already keep records.
Two different codes wear the same sticker
Before anything else, decide which of these you are printing, because they are different jobs and mixing them is the most common structural mistake:
One code per model. Every unit of the same product carries the same code, and it opens the manual, the spec sheet, the parts diagram, the safety instructions. This is cheap — one address, printed a thousand times — and it is the right answer for anything where the useful information is identical across units. It is also the code a manufacturer puts on a product before it knows where it will end up.
One code per unit. Every physical asset gets its own address, and it opens that asset's own history: install date, serial, warranty, who serviced it and when, which faults it has had. This is the one people actually mean when they say "maintenance QR code", and it costs more — a unique code and a unique destination per asset, which means a real asset register behind it.
The failure is a per-model code sold internally as a per-unit one. Somebody scans the pump expecting to see that this pump was serviced in March, gets a generic PDF, and stops scanning. From then on the labels are decoration.
The hybrid that usually wins: per-unit codes, whose destination shows the unit's own record and links to the model documentation. One scan, both answers, and the expensive part is the register you were going to need anyway.
The asset outlives the software
A boiler, a lift, a compressor, a fire door — these are ten, fifteen, thirty-year objects. The label you stick on today has to still resolve to something long after the tool that generated it, the person who set it up, and possibly the company that sold it have all moved on. That is a longer horizon than almost any other use of a QR code, and it changes the calculation.
The trade-off is genuinely two-sided. A static code encodes the address permanently, in the pattern itself — no service in the middle, nothing to keep paying for, and no ability to change it when your document host moves. A dynamic code encodes a short address that forwards, so the destination is a setting rather than a print run — but it works for exactly as long as that forwarding keeps running. Static vs dynamic QR codes covers the general case.
For long-lived assets there is one principle worth more than the choice itself: encode an address on a domain you own. A static code pointing at yourcompany.example/a/00412 is re-pointable forever without reprinting a single label, because you control what that path serves — you have kept the flexibility without depending on anybody's forwarding service. If you use a dynamic code instead, understand that you have bought convenience with a dependency, and that a thousand etched plates are a bad place to discover it.
The counsel of despair — print the serial number in text next to the code — is not despair. Do it anyway. It is the fallback that survives everything, and it costs nothing.
The label fails before the code does
The QR code is not the fragile part. The thing it is printed on is. A label on a machine lives somewhere a business card never goes:
- Abrasion — hands, tools, trolleys, cleaning. Paper on a handrail is gone in a season.
- UV — anything outdoors or under strong light fades until the contrast the code needs is not there. Faded is unscannable long before it is unreadable to a person.
- Solvents, oil and cleaning chemicals, which is most of a plant room and all of a kitchen.
- Heat, which yellows adhesives and lifts corners.
- Curved and textured surfaces. A code wrapped around a pipe is distorted, and distortion eats the error correction you were relying on for the dirt.
Match the medium to the environment — engraved or etched plates, anodised metal, industrial polyester labels — and be aware that the shiny metal finishes that survive best are also the ones that throw glare into a camera. Test on the actual surface, not on the sample.
Then size it for how it will be read: at arm's length, in bad light, by somebody wearing gloves who is not going to spend thirty seconds on it. The same lever as everywhere else applies and applies harder here — a shorter encoded address means fewer, larger modules, and larger modules survive dirt, distance and a scratched surface. QR code design that still scans covers contrast, quiet zone and how much logo a code can carry; an asset tag should carry none.
Plant rooms do not have signal
This is the one that silently kills the whole system, and it is predictable. Basements, plant rooms, lift shafts, walk-in cold stores, the back of a warehouse, a roof behind parapet walls — the places equipment lives are the places phones do not work. A code that opens a web page is useless to somebody standing in a room with no bars.
Three responses, in order of how much they cost:
- Print the asset ID in human-readable text beside the code, so the engineer can note it and look it up when they are back in signal. This alone rescues most of it.
- Keep the destination small. A lightweight page loads on one bar; a heavyweight portal does not load at all.
- Do not design a workflow that requires the scan to complete. If the job cannot be signed off without a page load, the job gets signed off on paper and typed in later, or not at all.
The same connectivity argument in a different setting is in QR codes at events and trade shows — the venue changes, the failure does not.
A code on a wall is a public address
Two security questions that are easy to skip and awkward to fix later.
Everything behind an unauthenticated URL is public. A code on the outside of a building, on a delivery cage, on a hire item that leaves your site — anyone can scan it. If what it opens names your suppliers, your site layout, your access arrangements or the fault history of a security system, you have published that. Either put it behind a login, or make the public destination a thin one and keep the detail on the authenticated side.
A sticker can be replaced. A QR code on a public-facing asset is a printed address that anybody with a label printer can cover with a different printed address — the same swap that is covered from the scanner's side in are QR codes safe. Two cheap defences: use a permanent or tamper-evident label rather than something that peels off cleanly, and train people to check the domain the scan lands on. If your codes always land on your own domain, that check takes a second and it works.
What the scan data is, and the one thing it must never be
Scan analytics tell you a code was scanned: how many times, roughly when, roughly where, on what kind of device. On an asset tag that is genuinely useful in narrow ways — which labels are being used and which have been ignored since the day they went up, whether a documentation set anybody asked for is actually being opened, which sites engage with the system and which quietly abandoned it.
Here is the line that matters: a scan is not evidence that work was done. It records that a phone read a square. It cannot tell you who held the phone, whether they looked at the page, or whether the pump was serviced — and a scan log is not a maintenance record, not an inspection record, and not a compliance record. Anyone who suggests otherwise is selling an inference. The record is the record you keep; the code is how somebody finds it. How to track QR code scans covers what the numbers do support.
Where to start with twenty assets rather than two thousand
Do not begin with the register. Begin with the ten assets people actually ask questions about, give each one a destination that answers the question they ask, and put a label on. If in a month the labels have been scanned, you have learned that the idea works here and you can widen it. If they have not, you have learned that for the cost of ten stickers, which is the cheapest possible way to find out.
The equivalent decision on the product side — a code that ships out on the thing itself and has to work in somebody else's hands — is the same shape, and the product packaging template is where that starts.
The short version
- The code is a pointer. If the document behind it is not maintained, the label is decoration.
- Decide per-model or per-unit before you print anything. Per-unit needs a real register behind it.
- Encode an address on a domain you own, so the destination stays re-pointable for the life of the asset.
- Print the asset ID in text as well. It is the fallback that survives everything.
- Choose the label for abrasion, UV, solvent and heat — the label fails long before the code does.
- Assume no signal. Keep the destination light and never make a job depend on a page load.
- An unauthenticated URL is public, and a sticker can be swapped. Decide both deliberately.
- A scan is never evidence that a service was performed. Do not let it near a compliance record.
