Report a breakdown in 60 seconds — from the machine itself

The mechanics above cover what happens after a scan; getting to that point reliably on an shop floor is its own discipline, especially where connectivity, shift patterns, and asset records are inconsistent. AssetAI treats the QR flow as the front door to the rest of the CMMS — see What is a CMMS for how breakdown records feed maintenance and asset management overall — but a front door only works if it's set up and staffed properly.

Designing the Flow for Real Shop-Floor Conditions

QR breakdown reporting is built to be used by an operator standing next to a stalled machine, often with a phone that isn't always online. A few design choices matter more in practice than they look on paper:

• No login, no app install for the reporting step itself — just a name, the company's scan PIN, and the form. This matters on lines where operators change shift-to-shift and IT can't provision individual accounts for everyone who might need to report a fault.
• Offline capture on the mobile PWA — if the phone has no signal when the operator hits submit, the form and its photos (up to 5) are held on the device with a banner confirming the pending sync, and they go through once connectivity returns. This is scoped to the mobile PWA's precached shop-floor pages; a plain browser scan without the app installed has no offline fallback, which is worth knowing before rolling this out on shared floor tablets.
• Failure mode from a managed master list, not free text, so the report is structured from the moment it's created rather than cleaned up later. This is what makes a failure Pareto possible downstream without a data-cleanup project first.

None of this replaces physical safety practice on the floor — the asset's linked safety measures print on the resulting job sheet, but the scan itself doesn't gate on any permit or safety sign-off, so plants that require a permit-to-work step need to keep that as a separate, manual control alongside the app.

Common Setup Mistakes to Avoid

Most of the friction we see with QR breakdown reporting traces back to two things done wrong at setup, not to the flow itself:

• Stale or missing "responsible" fields on the Asset Registry. Since the work order's responsible party defaults from the asset's technician or owner record, an outdated or blank field routes the job to the wrong person — or no one — the moment it's approved. Getting this right in the registry matters more than any setting inside the reporting flow itself.
• Nobody assigned to watch the approval queue. Normal and high severity reports don't raise a work order until someone approves them, and the flow itself doesn't call, text, or push-notify anyone when a new report lands — there's no paging mechanism behind it. Plants that treat the queue as a background task rather than a shift responsibility end up with reports sitting unactioned, which defeats the purpose of capturing them in the first place.

Getting both right is less about software configuration and more about process discipline — the same discipline referenced in most TPM practice, where failure response speed depends on people owning the loop, not just on having a tool that can record it. For plants scoping this against other shop-floor requirements, the use cases and industries pages cover how QR reporting sits alongside condition monitoring and preventive scheduling in a full maintenance program — or book a demo to see the queue and approval flow on a live plant setup.

QR breakdown reporting turns the moment a machine fails into a structured record instead of a phone call — every scan produces a numbered breakdown report (BD-000001, sequential per company) that feeds straight into AssetAI's work order and downtime tracking, with no separate system to reconcile afterward.

From Report to Work Order

Once an operator submits a report, what happens next depends on severity:

• Normal or high severity reports sit in a queue for approval. Approving one raises a breakdown maintenance (BM) work order pre-filled with the title from the description, priority mapped directly from severity, and the responsible technician defaulted from the asset's record in the Asset Registry.
• Emergency severity skips approval entirely — the work order exists the instant the report is submitted, because waiting for someone to review it defeats the purpose.
• If the machine-stopped flag was checked, the downtime clock starts from the reported time on the breakdown record itself — not when it's approved, not when the work order is created — so downtime-hours and downtime-cost KPIs reflect when the machine actually went down.

The breakdown report and the resulting work order are separate records with their own numbering, linked by the approval action. That separation matters for audit trails: you can always trace a work order back to the exact report and photos that triggered it.

Data Discipline That Pays Off Later

A breakdown report is only useful downstream if it's consistent, which is why the flow constrains a few fields rather than leaving everything free-text:

• Failure mode is chosen from a managed master list, not typed in — this is what keeps a failure Pareto usable months later instead of a pile of inconsistent phrases.
• Closure is gated. A BM (or CM) work order originating from a breakdown report cannot be marked Completed or Closed without a failure cause and a failure remedy recorded on it — enforced in code, not left to policy. Skip that step and the work order simply sits open.
• Severity maps to priority automatically. There's no separate priority field to argue over on approval; whatever severity the operator picked on the shop floor is what the planner's queue reflects.

This is the mechanism that makes RRR and criticality scoring possible later — the analysis is only as good as the discipline enforced at the point of failure, which is what this flow is built around. For plants also tracking OEE, consistent breakdown capture is a prerequisite, not an afterthought.

Where the Flow Has Edges

It's worth being clear about what this feature is not, so it's evaluated correctly:

• Approval for normal/high reports is still a manual step — someone has to open the queue. There's no automatic call, SMS, or push alert behind a scan.
• Offline capture (the form and photos stored on the phone until connectivity returns) is specific to the mobile PWA; a plain browser scan without the app installed has no offline fallback.
• Photos are capped at five per report — there's no video or voice-note capture.
• QR label printing and OCR nameplate capture belong to Asset Registry, not to this flow.

None of this is unusual for a CMMS built for Indian shop floors, where connectivity and device access vary by plant — see /industries for how the same flow plays out across sectors. If you want to see how breakdown data flows into scheduling and reporting on your own assets, book a demo rather than take the spec sheet's word for it.