Mobile Maintenance App
The plant in every technician's pocket
A breakdown happens on the shop floor, not in an office with fibre broadband. The operator standing next to the stalled machine has patchy WiFi, a phone, and no patience for an app-store install. AssetAI's mobile experience is built for that exact moment — a browser-based app that opens fast, works when the network doesn't, and gets the report into the queue before the technician even reaches the machine.
Installed Like an App, Without the App Store
There is no native iOS or Android app to approve, distribute or update through IT — and that's deliberate. AssetAI's mobile maintenance experience is a progressive web app: your operators open it in the phone's browser once, tap "Add to Home Screen," and from then on it behaves like an installed app — standalone display, portrait orientation, your plant's brand colour in the status bar, its own icon on the home screen.
Four shortcuts sit on that home screen from day one:
- Report breakdown
- Scan asset
- Work orders
- Meter reading
For a plant rolling out maintenance software across a 40-machine unit with contract labour and shift changes, this matters more than it sounds — nobody has to explain how to find the app in a store, sign an enterprise MDM agreement, or wait for an Android/iOS release cycle. It's a link, a tap, and it's on the phone. If you're still weighing whether a browser-based tool counts as a real CMMS, the short answer is: what matters is whether maintenance data gets captured reliably, not which store it was installed from.
What Actually Works Without Network
Plant WiFi in most Indian factories has dead zones — behind large machines, near motor rooms, in basement stores. AssetAI's service worker precaches the app shell (offline page, manifest, icons, icon font) so the interface itself loads even with zero signal. Beyond that, the caching strategy is deliberately split by what the content is:
- Static assets — icons, fonts, shell pages — are served cache-first with a background refresh, so they're instant and stay current.
- Shop-floor pages are network-first but keep a last-good copy on the phone, so a dead-WiFi zone shows the last known state instead of a blank screen.
- Anything else that can't be served either way falls back to a branded offline page, rather than the browser's generic "no internet" error.
This is the mechanism — not a promise that everything works offline. Read on, because what's excluded is just as important as what's included.
Offline Breakdown Reporting: The One Flow Built to Queue
This is the core of the offline design, and it's scoped narrowly on purpose. When an operator reports a breakdown and the phone is offline at the moment of submission, the entire form — including photos — is stored locally on the device. The operator sees a banner confirming the report is queued, not lost. The moment the connection returns, or the next time the page loads, the queue flushes on its own.
A few details make this trustworthy rather than fragile:
- Photos are stored as base64 in the offline queue; if the phone's storage quota is hit, the app drops the photos and retries with text only, rather than failing the whole report.
- A flush is only counted as successful on a 200 or 302 response — anything else keeps the item queued for the next attempt, so a flaky handshake doesn't silently swallow a report.
- Once flushed, the description gets " [offline @ date time]" appended, so the real time the breakdown was witnessed is preserved even though the server timestamp is later.
- Voice input is available for the breakdown description field — except on iOS, where it's deliberately hidden because Safari's speech API is known to stall the page rather than gracefully fail.
For a multi-lingual shop floor where a technician might describe a fault faster by speaking than typing, voice capture (on Android) removes friction at exactly the point where friction causes operators to skip reporting altogether.
Where the Offline Design Stops
Honesty here matters more than marketing copy, so this is stated plainly: only breakdown reporting is queued offline. Work order completion, parts issue, and meter readings all require a live connection. A technician can't close out a job or issue spares from stores while offline and expect it to sync later — those screens simply won't submit without network, because Livewire and API endpoints are intentionally excluded from the service worker's offline handling.
Similarly:
- Authenticated pages — work orders, asset details, meter screens — are never cached, so a logged-in view of "what's on my plate today" will not load offline.
- The service worker only intercepts same-origin GET requests; every POST, and anything cross-origin, passes straight through to the network as normal.
- There is no offline queue for anything other than the breakdown form.
If your plant needs technicians to close work orders inside a shielded basement with no signal, that's a gap worth planning around — schedule connectivity checks, or accept that closures happen once the technician steps back into WiFi range. AssetAI's work order management still runs the full lifecycle; it just needs a network to do it.
Meter Readings and Alerts, Two Honest Notes
Meter readings can be captured from the mobile shortcut, and can also be pushed in through the API from a connected device — useful where a plant already has sensors or PLC taps feeding data rather than relying purely on manual rounds. But meter capture is not part of the offline queue described above; it needs connectivity at the point of entry.
On alerts: there are no push notifications from this app. Alerts and escalations reach your team through the in-app bell, email, and WhatsApp — channels that work reliably across Android and iOS without needing OS-level push permissions or a native app wrapper. If your team's workflow depends on lock-screen push alerts, plan around WhatsApp and email as the actual notification path.
Where This Fits in Your Maintenance Programme
This mobile layer isn't a standalone tool — it's the field-capture front end for the same system running your preventive maintenance schedules, asset registry, and OEE tracking. For plants working toward ISO 55000 asset management discipline or building out TPM practices on the floor, reliable breakdown capture — even in a dead-WiFi corner of the plant — is often the weakest link in the data chain. See how it fits your specific setup on use cases, check pricing, or book a demo and bring your worst WiFi blind spot with you.
Rolling Out Across Shifts and Contract Labour
A PWA install is trivial, but rollout still needs a plan. Contract technicians rotate between plants, shift patterns change every week, and the person who understood the browser install on Monday may be on a different line by Friday. Treat this like any other shop-floor system change, not a link shared on WhatsApp once:
- Walk the actual dead-zones of the plant — near the compressor house, basements, far corners of the shed — before go-live, not after complaints start.
- Have a shift supervisor demonstrate the install on one phone in front of the team rather than emailing instructions.
- Keep a laminated one-pager near the shopfloor QR boards showing the four home-screen shortcuts, since operators forget the exact tap sequence within a week of not needing it.
None of this needs IT approval or an MDM policy, which is the point of skipping the app store — but it does need five minutes of a supervisor's time per shift crew.
Where Plants Get This Wrong
The most common mistake is assuming offline means "everything works offline." It doesn't, and pretending otherwise erodes trust fast. Work order updates, spares issue and meter entry screens are authenticated and need network by design — only the breakdown-report flow queues and self-submits. If a technician tries to close a work order standing next to a machine with no signal, it will simply not go through, and that's expected behaviour, not a bug to escalate.
The second mistake is relying on push notifications that don't exist here. Alerts arrive through the in-app bell, email and WhatsApp — so a supervisor's phone needs those channels genuinely checked, not assumed to buzz on its own.
What to Watch After Go-Live
Once the app is in daily use, a few signals tell you whether it's actually solving the WiFi problem or just moved it:
- How many queued reports carry the `[offline @ date time]` tag in a week — a high count means your patchy-WiFi zones are wider than you thought, worth a network audit.
- Whether photo-dropped, text-only reports are showing up — a sign phones are hitting local storage limits and need clearing.
- Time between an operator's QR scan and the report reaching the maintenance desk, which is the real test of whether the queue is flushing promptly on reconnect.
These aren't vanity metrics; they point straight at whether your plant's WiFi or storage setup needs fixing, independent of the software.
Where This Does Not Fit
Be honest with your team about the edges. If your maintenance model depends on technicians completing work orders, recording parts consumption or logging meter readings while physically offline, this mobile experience won't carry that load — only breakdown capture is queued. Voice input for breakdown descriptions is also deliberately switched off on iOS, because the browser's speech API has a habit of freezing the page, so iPhone users type instead. And if your escalation process assumes a phone notification will wake someone at 2 a.m., build that on WhatsApp or email alerts, not on the browser tab being open. None of this replaces the discipline of a documented maintenance schedule or the criticality thinking behind OEE tracking — it simply makes sure a breakdown report survives the walk from a dead WiFi corner back to a live one.
Mobile Maintenance App FAQs
Does AssetAI's mobile maintenance app work if the shop floor has no WiFi or stable mobile signal?
Yes — a breakdown report is captured on the phone itself first and only pushed to the server once a connection is available. Because the app opens in the browser as an installed-like experience rather than depending on a live server call to even load, the operator can tap "Report breakdown," fill in the details, and the entry sits in a queue on the device instead of failing silently. As soon as the phone picks up WiFi or a mobile signal again, that queued report syncs to the central system automatically, using the same architecture behind the rest of AssetAI's features. This queuing is what lets a report reach the system before the technician has even walked over to the stalled machine, instead of waiting for someone to reach an office terminal with a working broadband connection.
How does the "Scan asset" shortcut help identify the right machine during a breakdown?
It ties the report directly to the correct equipment by having the operator scan the asset's tag instead of typing or searching for an asset code from a small phone screen. The operator taps "Scan asset" on the home screen, points the camera at the machine's tag, and the matching asset record opens straight away, with its history and identity already attached to whatever report or work order is logged next. This reduces the chance of a report being filed against the wrong unit on a floor where several similar machines sit close together. Since "Scan asset" sits on the home screen alongside "Report breakdown," "Work orders" and "Meter reading," there's no menu-hunting involved — it's one tap, consistent with how the rest of the features are laid out for fast, low-friction use during a breakdown.
Can an operator raise a work order from the shop floor without waiting for someone at a desk?
Yes — the "Work order" shortcut on the home screen lets anyone with app access log or update a work order directly, without it first being typed in by someone at a desktop. The moment a fault or task is noticed, the operator opens the shortcut and creates the entry; a supervisor reviewing the queue can then approve, reassign, or schedule it. The same queuing mechanism that holds breakdown reports on the device when there's no signal applies here as well, so a work order raised in a low-connectivity part of the plant isn't lost — it waits on the phone until it can sync. This keeps the work order list current without every entry depending on manual desktop data entry, one of the reasons this workflow is described in AssetAI's use-cases.
How do meter readings taken on a phone feed into preventive maintenance triggers?
The reading logged on the phone becomes the data point a usage-based maintenance schedule checks against, so a job can be generated once a value crosses its set threshold rather than only on a calendar date. The operator taps "Meter reading" on the home screen, enters the current value — running hours, cycles, or whatever unit is configured for that asset — and it's logged with a timestamp against the asset record. If the maintenance plan for that equipment is usage-driven, this is the figure the system compares before releasing a task. Because "Meter reading" sits on the same home screen as "Report breakdown" and "Scan asset," logging a reading takes the same one-tap action as reporting a fault, part of the broader set of features built around the shop floor.
Is this mobile app safe to use on personal phones belonging to contract labourers or temporary staff?
It can be, because access is controlled by login credentials tied to each user's account rather than by which device the app is opened on. Since there's no native app to install from a store and no MDM enrolment required, IT isn't managing a list of approved personal devices — the app is simply a link opened in a browser, added to the home screen. What decides what a contract worker can see or do is their login and the role assigned to that account, not whether the phone is company-issued or personal. This separation of "how the app is opened" from "what the user is allowed to do" is the same logic behind the rest of AssetAI's features, and it's worth walking through account setup directly if you want specifics for your shift and contractor mix — you can book a demo to go over it.
Does using the mobile app affect OEE or downtime reporting, or is that tracked as a separate step?
Reporting a breakdown through the phone is what generates the timestamped downtime entry that later feeds into OEE and other reliability numbers, rather than being a separate manual step. Because "Report breakdown" logs the time the fault was raised as soon as it's queued on the device, that entry becomes the raw downtime data point other parts of the system draw on when calculating metrics such as availability or performance loss. Nobody has to re-enter the stoppage time into a spreadsheet afterward — it's already attached to the asset from the moment it was reported. If you want to see exactly how downtime entries roll into a metric like OEE, the mechanics are laid out on the OEE glossary page.
Can technicians update asset history and spare parts consumption directly from the mobile app, or do they need to sync data back to the desktop later?
Technicians can log work completion, parts used, and labour hours directly on the mobile app. Data syncs automatically when connectivity returns. This ensures your asset maintenance history stays current without manual re-entry, reducing errors and keeping spare parts inventory accurate on the shop floor.
See Mobile Maintenance App on your own machines
A 30-minute demo on your plant, not our slides.