QR Code Asset Tracking

On most Indian shop floors, the operator sees the fault first — a bearing screaming, a belt smoking, a gauge climbing — but has no clean way to report it. So it gets mentioned to a supervisor an hour later, or not at all, and the machine runs till it seizes. QR Code Asset Tracking closes that gap: a label on the machine, a phone camera, and the report is in the system before the operator has walked away.

How the scan works

Every asset carries a QR label encoding a fixed path — `/scan/{company}/{asset-code}`. There's nothing to install and nothing to configure per phone: any camera app or browser opens the asset card directly. This matters more in Indian plants than the spec sheet suggests, because the workforce reporting faults is often contract or rotating labour who will use whatever handset they own, on whatever OS it runs, for as long as they're posted to that line.

Reporting itself needs no user account. The operator enters their name and a company-wide scan PIN — not a personal login, just a shared PIN issued once per site — and that's the entire barrier to filing a report. Supervisors and technicians still get proper accounts, because approvals, work orders, and history need an identity attached. But the person standing at the machine at 2 AM on a night shift doesn't need to remember a password to say something is wrong.

What a report actually captures

The report form is short by design — built for someone reporting from the floor, not filling out a form at a desk.

• Severity: normal, high, or emergency
• Machine stopped: a yes/no flag, because a running-but-abnormal machine and a dead line are different problems
• Description: free text, in whatever language the operator is comfortable typing
• Photos: up to 5, capped at 8 MB each — enough to show the fault from more than one angle without turning into a video upload

On submit, a breakdown number is issued automatically and an approval request opens. Everyone holding the `breakdowns.approve` permission — usually the shift supervisor and maintenance lead — is alerted on WhatsApp and email simultaneously, so approval doesn't wait on someone opening a dashboard. If the severity is marked emergency, approval is skipped entirely and the work order is raised straight away; a machine on fire doesn't need a supervisor's sign-off to get a technician moving.

The duplicate problem, solved quietly

Anyone who has run a maintenance desk in a 200-machine unit knows what happens when three operators notice the same stalled conveyor: three breakdown reports, three approval pings, and a supervisor trying to figure out if that's one fault or three. The scan page checks for an open breakdown on that asset first — if one exists, it shows the existing report instead of letting a second one through. The same fault reported by two operators becomes one breakdown, not two, which keeps the approval queue and the eventual OEE math honest. (If you haven't measured OEE at your plant yet, OEE explained is a reasonable starting point before you lean on breakdown counts as a proxy for anything.)

Meter readings without a sensor budget

The same QR scan doubles as the meter-reading capture point. Point the phone at the hour-meter, and OCR reads the digits — no typing required for the common case, though typing remains an option when the display is cracked or the lighting is bad. One rule is enforced without exception: a reading lower than the last logged value is rejected. Meters only move forward, so a fat-fingered entry or a stuck-at-zero photo doesn't quietly corrupt the maintenance schedule downstream.

Worth being direct about what this isn't: there's no IoT or SCADA integration here. If your controllers already expose runtime data over a protocol, this doesn't read it — someone still points a phone at the gauge. For a lot of Indian plants running a mix of decade-old PLCs and newer machines with no retrofit budget, that's the realistic option anyway. It's not telemetry, and we don't pretend it is.

Knowledge from the last fix, before the first tool comes out

When the asset card opens, it doesn't just show a blank report form — it surfaces the top 3 verified Knowledge Base cards for that specific machine. A technician arriving at a compressor that's tripped before sees how it was fixed last time, before pulling a single panel. On a site with multiple shifts and technicians who don't always overlap, that's often the only transfer of tribal knowledge that happens at all.

Working when the network doesn't

Plant floors lose signal — sometimes from concrete and steel construction, sometimes from the same power cuts that trip the machine in the first place. The scan page is a PWA: a service worker queues the report locally on the phone and submits it automatically once the network returns, tagging the description with the original offline timestamp so the report reflects when the fault actually happened, not when connectivity came back. This is browser-based offline capture, not a native Android or iOS app — there's no app-store install, and that's deliberate, since it's the same reason there's no login: fewer things for a rotating workforce to manage.

Where this fits and where it doesn't

This is built for plants where the delay is getting the fault reported at all — multi-line units with contract labour, shift handovers, and operators who will never reliably hold individual logins. If that's your floor, features covers how this sits alongside work orders and preventive schedules, and use-cases has examples closer to specific industries.

It's a poor fit for a single-machine workshop: there's no duplicate report to guard against and no approval chain to route when one person does everything. And it's not a replacement for proper condition monitoring — if you're chasing TPM-style continuous improvement with real telemetry, this is the reporting layer underneath it, not the sensor layer. For plants deciding whether a full CMMS is the right next step at all, What is a CMMS is worth reading first, and /pricing or /contact can take it from there.

Printed and stuck correctly, a QR label survives years on a factory floor; printed and forgotten, it becomes another sticker nobody trusts. The difference is in the rollout discipline, not the technology.

Getting Labels Onto the Floor Correctly

A QR asset tag has to survive heat, grease, vibration, and the occasional degreaser wipe-down — most plants underestimate this until the first batch of labels fades within a season. Before ordering labels at scale:

• Match the label material to the environment: a foundry floor and an air-conditioned electronics line don't need the same laminate
• Place the label where a phone camera can reach it without someone climbing over a guard or reaching into a live zone
• Number the asset code on the label itself in plain text, so a faded or scratched QR code still has a fallback
• Pilot on one line first — confirm scan reliability under actual shop-floor lighting before printing for the whole plant

None of this is exotic. It's the same shop-floor pragmatism that underlies ISO-aligned asset management generally, adapted for the fact that most Indian plants run mixed-vintage machinery where a label placed for a 2020 machine model may not suit the 1998 model next to it.

The Data Discipline That Makes Reporting Useful

A QR label only produces good data if what happens after the scan is consistent. Two things matter more than they first appear:

• Severity has to mean something. If operators mark everything "emergency" to get faster attention, the emergency-skips-approval path stops being a safety valve and becomes a bypass. Supervisors need to periodically review severity tagging, not just breakdown counts.
• Meter readings need a baseline. Because AssetAI's OCR reads a photographed hour-meter and rejects any reading lower than the last one, a wrong reading logged early creates a ceiling that legitimate future readings can't cross. Get the first reading right, manually if needed, before scanning becomes routine.

These aren't edge cases — they're the two most common ways a QR rollout produces clean-looking data that's actually unreliable. Get them right in the first month and the rest of the system, including the Knowledge Base cards surfaced on every scan, compounds in value rather than accumulating noise.

What to Track Once Scanning Is Routine

Once operators are scanning without being reminded, the label stops being a novelty and starts being infrastructure. At that point, look at:

• Time between "machine stopped" flag and work order creation — this is your real breakdown-response number, distinct from anything self-reported
• How often the duplicate-scan guard fires — a high rate usually means one asset is under-maintained relative to its usage
• Which machines never generate scans — often a sign the label is missing, damaged, or placed somewhere operators can't reach

None of these require a dashboard project. They fall out of data you're already collecting the moment scanning becomes habit — the same data that feeds into broader reliability metrics like OEE, if that's a number your plant already tracks. If you're deciding whether QR-based reporting fits your specific line configuration, our use cases page has more detail, or you can walk through it directly by booking a demo.