When a factory introduces an equipment breakdown reporting app, the first decision is not the color of the screen. It is where responsibility passes from the operator who observes a problem to maintenance intake, the CMMS work order, and the production team that confirms a safe return to operation. Calls, chat messages, and paper notes often coexist. The same incident may be reported twice while the stop time or hazard is missing. This guide turns the reporting workflow into concrete requirements and acceptance tests for production, maintenance, and IT teams in Thailand.
Define the reporting app’s job before selecting a product
The app converts an operator’s observation into a request maintenance can assess. It does not predict future failures, diagnose root causes with AI, or schedule preventive inspections. A request is valid before the cause is known. Ask the operator to record “abnormal noise,” “motor does not turn,” “burning smell,” or “machine stopped,” rather than to guess which component failed. The maintenance work order is the place to confirm cause, labor, parts, and action.
IBM Maximo’s service request documentation describes recording what service is needed, who needs it, and where, when, and why. Maximo Mobile separately describes technicians executing assigned work orders and recording progress and actuals. This is a useful model for separating an incoming request from maintenance execution; it is not a requirement to buy Maximo. If a CMMS already exists, make the reporting app a light front door linked by request and work order numbers, rather than a second work order ledger.
The workflow has four stages: (1) the shop floor files an initial report, (2) maintenance intake checks duplicates and urgency, (3) a CMMS work order is created or linked, and (4) production verifies return to operation. A serious hazard cannot wait for an app transaction. Follow the site’s emergency stop, isolation, and human notification procedures first. The app records what happened and when.
Capture five facts: asset ID, photo, symptom, stop time, and hazard
More fields do not necessarily produce better reports. During a leak or line stop, operators cannot complete a long form. Start with the five facts below and add optional fields after observing real use.
| Field | Shop floor input | Intake purpose |
|---|---|---|
| Asset ID | Scan an equipment QR label; search if scanning fails | Match the asset register and open work |
| Photo | Show the affected area; allow a reason if photography is prohibited | Support observation, not prove cause |
| Symptom | Short choices plus a free text note | Triage without assuming root cause |
| Stop time | Enter when the stop was observed; retain device entry time separately | Verify the downtime timeline |
| Hazard | Yes, no, or not yet checked | Trigger the site’s human escalation route |
QR scanning must have a fallback. Labels can be dirty, cameras can fail, and similar machines may have similar plates. Search results should show site, building, line, and asset name before selection. If production and maintenance use different display names, share a stable asset ID rather than forcing all attributes into one register. For asset register granularity and request routes, see our equipment maintenance management guide.
Photos can expose customer products, confidential drawings, or faces. Set rules for permitted areas, storage, access, and retention. A no-photo route must work in restricted zones. Test image quality with real shop floor examples: overcompression may hide a leak or a display reading, while unlimited full-size images overload storage and the network.
The observed stop time is not the send time. An operator may call first and enter the report later. An offline device may synchronize still later. Store observed time, device entry time, and server receipt time separately, including the time zone. Define which event starts downtime in the KPI. This avoids silently treating a delayed upload as a delayed failure.
“Hazard not checked” is not “safe.” If shock, entanglement, fire, or chemical release is possible, direct the user to the site’s immediate safety and call procedures. Do not turn a score or push notification into a safety authorization. The US OSHA lockout/tagout guidance is a reference for hazardous energy control in the United States; it is not a statement of Thai law. Confirm local legal obligations and the site’s own safety procedures separately.
IDs and retries
In a weak-signal building, users may tap Send twice. Generate a unique request ID on the device and use it as an idempotency key server-side. Show distinct states for saved locally, sending, received by the server, and failed. Keep a retriable local record until the server returns an intake number. A success animation alone must not imply that maintenance has accepted the request. On shared devices, define logout and local data cleanup so the next user cannot browse the previous user’s photos.
Maintenance intake must resolve duplicates and answer the reporter
One stopped machine can prompt separate reports from an operator, supervisor, and quality team. Automatic deletion based on asset and time can erase a second independent problem. Instead, show likely duplicates to an intake owner, who can merge, relate, or retain them as separate incidents. Preserve each original reporter, photo, timestamp, and hazard statement, plus the decision history. Never overwrite the original observation without an audit trail.
Intake checks whether the asset is correct, a hazard is indicated, the machine actually stopped, and another request is open for the event. If clarification is needed, send a question and display “awaiting clarification.” If accepted, return the intake number, owner, and next update point. “Notification delivered,” “read,” and “work started” must not be the same state. For a three-shift plant, show unresolved intake at handover instead of leaving it in one person’s chat inbox.
Priority combines safety and environmental risk, stoppage, asset criticality, alternative capacity, and product impact. A hazard flag should be a separate escalation condition that cannot be canceled by a low numerical score. Response targets belong to the plant’s staffing and safety procedure. Times in the acceptance table below are illustrative test settings, not market averages or TOMAS TECH client outcomes.
Imagine that an operator observes abnormal spindle noise at 03:10, calls a supervisor, and saves a photo report at 03:14. It reaches the server at 03:23 because the device was offline. The supervisor submitted a second photo at 03:12. Intake should compare observed, entry, and server times and relate the two reports if they describe one event. If maintenance temporarily restores the spindle at 03:35 and it stops again at 03:50, the later event must not disappear merely because the asset ID matches. All times in this example are hypothetical. Test this sequence in FAT with sample data and in SAT with actual devices.
The intake rota matters as much as the screen. A single named recipient can be absent or have an empty battery. Define the primary recipient, fallback, shift change, and an independent route for hazards. Record when a person accepts a request; notification delivery alone is not an acceptance event.
Hand off to the CMMS without creating a second source of truth
Choose the authoritative system by data item. For example, the CMMS may own the asset register and work orders while the reporting app owns the original observation and photo. Do not allow both systems to edit the same work status freely. Map CMMS states into terms useful to operators, such as “received,” “assigned,” “in progress,” and “awaiting production verification.” The shop floor does not need to see every internal CMMS code.
Pass the asset ID, intake number, symptom, hazard, observed stop time, photo reference, reporter, intake owner, priority decision, and shop floor contact. Use the intake number as an idempotency or reconciliation key when an API creates a work order. If creation fails, show “handoff pending,” retry safely, and alert intake. Show “handed to CMMS” only when a work order number is returned. An apparently completed handoff that failed in the background is an operational defect.
If maintenance concludes that the item is a configuration request or belongs to another department, record the reason and next owner and tell the reporter. If an API is not affordable at first, link the request and work order numbers manually so the chain can be audited. For CSV exchange, specify frequency, failed-import handling, and photo link expiry. The maintenance team, not the initial reporter, owns cause codes, replaced parts, and labor entries.
ISO 14224:2016 covers collection and exchange of reliability and maintenance data for petroleum, natural gas, and petrochemical facilities. Its separation of equipment, failure, and maintenance information is informative, but it is not a mandatory standard for every manufacturing plant. Keep a data dictionary: define what “stopped” means, distinguish “no hazard checked” from a blank response, preserve the operator’s original words when intake recodes a symptom, and use a stable symptom code across Japanese, Thai, and English displays. Track historical asset names when an asset is moved or renamed.
Where several systems exist, choose one work order master. Sending each report directly to both CMMS and ERP can create two competing instructions. One possible path is report → CMMS work order → ERP for costs or inventory. Confirm the actual sequence with existing permissions and accounting rules.
Put failure cases in the integration specification
Test a CMMS outage, unknown asset ID, response loss immediately after successful creation, photo upload failure, and a canceled work order. A blind retry after response loss can create duplicate work orders. Reconcile by request key before retrying. Prefer cancellation history to silent deletion, and retain the path from original report to final work order. Include mapping of timestamps, time zones, and display names in the deliverables.
Separate maintenance completion from production restart
A technician completing a work order does not prove that production can restart safely or that the first good product has been made. If the app includes restoration confirmation, an authorized production person should verify it after maintenance completion. Capture operating status, trial-run result, whether quality approval is needed, and whom to contact if the problem returns. Isolation release and restart follow the site’s formal authority and safety procedure. A “restored” app button must never be treated as a remote start or a safety permit.
Do not automatically use the technician’s completion time as the end of downtime. Maintenance completion, trial start, and good production restart are different events. Define which one closes each KPI and retain corrections. Otherwise pre- and post-deployment downtime figures will not be comparable. Decide which timestamp MES or ERP receives before connecting systems.
If a trial fails, define whether to reopen the work order or raise a related event. A recurrence shortly after restoration may deserve its own observed time while remaining linked to the original report. Automatic merging can hide recurrence frequency. Production, maintenance, and quality should agree on the meanings of “completed” and “restored.”
Test offline behavior and device management inside the real plant
Office Wi-Fi quality says little about signal behind machines, in metal-rich areas, or outdoors. Specify which screens and asset records remain available offline, how photos are queued, and what happens after reconnection. Microsoft’s official Power Apps Mobile documentation describes a local data store and synchronization when connectivity returns. This is an example of a product implementation, not a guarantee for every app; translate the required behavior into acceptance tests.
If two devices report the same asset while one is offline, keep both original reports with their own IDs and let intake relate them. If users edit an existing report offline, define conflict rules so stale status cannot overwrite a newer one. Decide whether text may reach intake before a delayed photo. Microsoft’s mobile offline overview discusses conflict detection, but the resolution policy depends on the chosen app and data model.
Device policy differs for personal, company-issued, shared, and dedicated units. NIST SP 800-124 Rev.2 provides guidance for management and protection over the mobile device lifecycle. Set enrollment, authentication, lost-device response, OS updates, photo storage, and access removal when employees change roles or leave. Test whether temporary photos leak into the consumer photo gallery, and how unsynchronized reports are recovered when a device is replaced. For lifecycle cost, charging, and device replacement, see our factory tablet selection guide.
“Works offline” is too vague for an RFP. State how many asset records must be preloaded, what happens when authentication expires, how a hazard is displayed offline, and whom the device tells after it reconnects. Human safety contact must not wait for a sync. Test with gloves, wet hands, dirty QR labels, real shift changes, charging locations, and spare devices. Translate asset names, symptom choices, and safety text into the language operators actually use. Stable codes underneath the displayed words avoid split reporting by language.
Write an RFP around handoffs and exceptions
Checkmarks for “mobile,” “notifications,” and “CMMS integration” do not show whether the workflow works. Specify the real events and ask vendors to demonstrate them. At minimum, cover target assets and users; devices and network; the five first-report fields; hazard escalation; duplicate review; the CMMS master and API; restoration verification; roles; audit trail; offline behavior; photos; and operational support.
Options include the existing CMMS mobile function, a low-code front door, a custom app, or a staged improvement of phone and paper practice. Test an existing CMMS function first where available. Add only the missing front-end behavior. A screen intended for technicians may still be too complex or overprivileged for every operator.
Compare cost over the same period and operating assumptions. Include asset register cleanup, QR labels, devices, mobile device management, Wi-Fi, CMMS API licenses, photo storage, support, changes, and training, not just development. There is no defensible universal market price in this guide. Require the quote to state which system receives which data, within what agreed service target, and who handles a failure. A cheap initial quote can leave manual retry and permission changes outside scope.
Illustrative acceptance tests, not industry benchmarks
| Scenario | Example pass condition | Evidence |
|---|---|---|
| Normal report | Equipment ID, symptom, stop time and hazard status can be submitted, with a photo where permitted, and an intake number returned | Device screen and server record |
| No-photo zone | A reason is recorded and reporting still works | Reason visible to intake |
| Duplicate candidate | Two reports within five minutes are suggested, but can stay separate | Originals and decision log |
| Offline | After a 30-minute disconnection, exactly one request arrives | Request ID and sync log |
| CMMS outage | Original report survives; one work order appears after recovery | Retry log and work order number |
| Restoration | Maintenance completion alone cannot close production verification | User IDs and both timestamps |
Five and 30 minutes are hypothetical test inputs. Set actual thresholds from the plant’s traffic and connectivity. Use FAT for simulated assets, roles, and integration; SAT for real QR labels, devices, network, and shifts; and UAT with operators and intake staff as well as technicians. Agree on evidence before ordering. Include safe retry, log export, recovery from backup, and adding or removing access in the contracted test scope. Expansion to another site changes asset registers and emergency contacts, so separate those as configuration rather than embedding a line name or a person’s name in code.
Measure missing information and handoff delays after launch
Before launch, sample calls, paper records, and chats to establish missing asset IDs, unknown stop times, hazard recording, intake delay, and duplicate counts. Compare with the same definitions after launch. More recorded incidents in month one may mean better visibility, not more failures. Split elapsed time into report-to-intake, intake-to-work-order, work-order-to-maintenance-completion, and completion-to-production-verification. Reasons for holds and exceptions show whether the problem is input, intake staffing, integration, or the last confirmation. Examine night and weekend tails, not only averages.
IT cannot own this process alone. Production owns observation and restart confirmation; maintenance owns intake and work orders; IT owns devices, access, and integration; quality and safety define exception routes. In a short weekly review, examine wrong asset IDs, missing fields, reversed duplicate decisions, and hazard calls. Before adding fields, check whether symptom choices match local shop floor language.
FAQ
Does a breakdown reporting app have to be separate from the CMMS?
No. If the current CMMS mobile entry handles the core report data, photo exceptions, hazard route, duplicate review, and intake reply, use it. Otherwise, consider a thin reporting front door with the CMMS retaining authoritative work orders and history.
Is AI root-cause diagnosis required at launch?
No. First record observed symptoms and times and hand them reliably to maintenance. Cause classification belongs to completed maintenance work. Consider AI only after the data and decision purpose are clear.
Can the app work where factory Wi-Fi drops?
Yes, if local storage and synchronization are designed and tested in the actual building. Specify offline asset records, photo capacity, lost-device protection, and duplicate and conflict handling; capabilities vary by product.
Is a push notification sufficient for a hazardous report?
No. The site’s stop, isolation, evacuation, and direct human contact procedures take priority. The app is an audit and awareness aid.
What costs are commonly missed?
Asset register cleanup, QR labels, devices and MDM, network improvement, CMMS API access, photo storage, shift training, and exception handling. Compare total cost under the same scope and period.
Conclusion
A breakdown reporting app is the entry point that turns observation into maintenance intake, a CMMS work order, and production’s restoration confirmation. The critical design decisions are accurate asset and time data, human hazard contact, reviewable duplicates, visible integration failures, and clear restoration authority. Test them on actual machines, devices, shifts, and weak network areas.
If you are defining the scope between first report and CMMS handoff, contact TOMAS TECH. We can help turn your current shop floor flow into a testable requirement and acceptance scenario even before a product is selected.
Sources
- IBM Maximo Manage: Creating service requests.
- IBM Maximo Mobile overview.
- Microsoft Learn: How offline first functionality works in Power Apps mobile.
- Microsoft Learn: Mobile offline for model-driven apps overview.
- NIST SP 800-124 Rev.2.
- ISO 14224:2016 (petroleum, natural gas, and petrochemical scope; not a general manufacturing mandate).
- US OSHA lockout/tagout program guidance (US reference, not Thai law).
