Work Order Management
Every job planned, assigned, tracked and costed
A machine goes down, a technician fixes it in forty minutes, and by evening nobody can say whether it cost ₹800 in spares or ₹8,000, or whether this is the third time the same bearing has failed this quarter. The work order is supposed to be the one record that answers both questions — what did this repair cost, and why did it happen — but on paper or in a spreadsheet it rarely does either. AssetAI's work order module ties cost, cause and closure together on a single record, without pretending to be a dispatch board or a scheduling tool.
One Work Order, Four Types, No Ambiguity
Every job on the floor fits one of four types — Preventive, Corrective, Breakdown or Predictive — with four priorities from Low to Emergency, and moves through eight statuses from New to Closed. A new work order defaults to Corrective, Medium priority, New status, so a technician logging a quick fix doesn't have to think about classification before they've even looked at the machine — they can correct the type later if it turns out to be a full breakdown.
Numbering is sequential and unique per company (WO-000001 onward), so there's no confusion between two work orders raised in the same shift by two different shift supervisors. And work orders are never deleted. If one was raised by mistake or the wrong asset was picked, you cancel it — the record stays, which matters when an auditor or an OEM warranty claim asks for a complete history rather than a curated one.
This module handles the work order itself. If you're looking for how preventive schedules get generated or how breakdowns get triaged before they become work orders, those are covered separately under Preventive Maintenance and Breakdown Maintenance.
The Cost of the Repair, on the Repair
Most CMMS tools treat the work order as a task list and cost as an afterthought pushed into a separate purchase order or spreadsheet. Here, every work order carries three kinds of line items — parts, services priced from the service master, and labour charged as technician hours at that user's hourly rate. Each line takes quantity, unit cost, discount percentage and UOM, and the line amount is always quantity × unit cost × (1 − discount/100), rounded to two decimals, recomputed on save. The total splits automatically into parts, services and labour, so a plant head reviewing repair cost doesn't have to ask whether ₹12,000 was mostly a contractor's service bill or an internal technician's time.
What this doesn't do: it won't reserve stock against a line item from this screen. Spares issue and reservation live in requisitions — the work order tells you what was consumed and its cost, not where the stock came from. For plants running tight spares budgets with long import lead times on bearings or drives, that separation is deliberate: procurement and consumption are different conversations, and conflating them on one screen tends to slow both down.
Getting the Right Technician on the Job, Fast
Picking an asset on the work order lists technicians whose skills match what that asset requires, ranked by how many skills line up. A one-click assign adds that technician as a pre-costed labour line at their hourly rate — no separate step to look up who's certified on a particular VFD panel or who's done the OEM's welding course. On a shift with contract labour rotating in and rotating out, or a night shift with fewer supervisors around to make that judgment call, this shortens the gap between "machine is down" and "the right person is on it."
Assigning a technician also fires a notification to them directly — they don't find out from a phone call or a name scrawled on a whiteboard. Raising a new work order opens an approval request, and completing one opens a separate inspect-and-close approval, so a supervisor signs off on the repair before it's truly done, not after the paperwork has gone cold.
What this doesn't do: there's no crew or shift capacity view, and no drag-and-drop dispatch board. If your maintenance operation is closer to a field-service business juggling multiple crews across sites throughout the day, that's a different problem than the one this module solves — see use cases for where AssetAI fits and where it doesn't.
Failure Cause and Remedy, Captured Every Time
A machine failing three times in a quarter isn't usually a mystery of engineering — it's a gap in the record. Someone remembers the cause was a worn seal in June, forgets to write it down in September, and by December nobody can build a failure Pareto because two of the three records are blank. This module makes that gap structurally difficult: a Breakdown or Corrective work order cannot be marked Completed without both a failure cause and a failure remedy recorded, drawn from master lists rather than typed freeform. This is enforced in two separate places in the workflow, so it isn't something a rushed technician can skip past on a busy shift.
The taxonomy — failure mode captured at report, cause and remedy confirmed at closure — follows the structure used in ISO 14224 for reliability data, which is what makes the resulting Pareto chart trustworthy rather than a list of whatever word each technician felt like typing that day. The closure tab also takes repair evidence photos (up to 8 per work order, 8 MB each), fault type, description, root cause and closure remarks, so an audit or an insurance claim has more to work with than a one-line note.
What It Deliberately Leaves Out
Two timestamps — Start and Complete — are written once and never overwritten, and they're what drive your MTTR calculations. Starting a work order also moves its linked breakdown record to in-progress automatically, so the breakdown log and the work order don't drift out of sync. But there's no offline-first app for technicians to punch these on the shop floor without connectivity — the work-order screen is web, which matters if your plant has patchy Wi-Fi in the far corners or technicians who only have a shared terminal near the maintenance office.
There's also no support for work-order dependencies, parent-child jobs, or a single work order spanning multiple assets. Each work order is one asset, one job, start to finish. If your maintenance planning genuinely needs multi-asset jobs sequenced against each other, that's outside what this module is built for — worth checking against /features and /pricing before you commit.
For plants that need to answer "what did this repair cost" and "why does this keep happening" from the same record, without needing a scheduling suite bolted on top, book a demo and we'll walk through a live work order end to end.
Work orders across PM, breakdown and corrective — with priority, status and cost.
What You Can't Do — By Design
Some of the most useful decisions in AssetAI's work order module are about what has been deliberately left out. A work order can never be deleted; if one was raised in error or the job is cancelled, the record is reversed with a Cancelled status rather than erased. For plants operating under ISO-aligned quality systems, or preparing for audits against ISO standards, this is not a limitation — it's the point. Every job that was ever opened stays visible in history, which is what makes downtime and cost trends defensible when someone asks how a number was calculated.
The module also stays deliberately flat. There are no parent-child job hierarchies, no multi-asset work orders, and no cross-work-order dependencies to configure. Each work order maps to exactly one asset and one job. This keeps the record simple to audit, but it also means teams running large shutdowns or multi-trade jobs should plan to log each asset's work separately rather than expecting a single ticket to represent a whole campaign — a consideration worth factoring in during use case planning.
Similarly, there's no crew or shift capacity scheduling and no drag-and-drop dispatch board — assignment happens through the skills-based technician match, not a visual planning board. And the work order screen is web-based rather than a native offline-first app, so technicians need connectivity to start, update or close a job. For most Indian plant floors, where Wi-Fi or plant-issued tablets are increasingly standard, this is a reasonable trade-off against the complexity of syncing offline edits back into a system that's meant to stay audit-clean.
Where Spares Fit In
Notably, there's no per-line stock reservation from the work order screen itself. Parts appear as costed line items on the work order, but issuing spares against a job is handled through requisitions, keeping inventory movement and job costing as two distinct, reconcilable trails. This separation matters in plants where store control is tight — it means a technician can plan and cost a job without directly touching stock levels, and store staff retain a single, unambiguous point of issue rather than parts leaving the shelf from multiple screens.
Notifications That Keep the Workflow Moving
Because a work order in AssetAI touches several people — the requester, the approver, the assigned technician — the system pushes notifications at the moments that matter rather than relying on someone checking a list. Assigning a job notifies the responsible technician directly. Raising a new work order opens an approval request, so nothing gets worked on without sign-off. And marking a job complete opens a second approval — an inspect-and-close step — before it's truly finished. This two-gate approval pattern (open and close) is a practical way to keep supervisors in the loop without requiring them to babysit every status change, and it complements the failure-taxonomy discipline that feeds MTTR and OEE reporting elsewhere in the platform.
Together, these constraints and mechanisms are why manufacturing teams evaluating a CMMS for Indian plants — where industry conditions range from heavy discrete manufacturing to process plants — treat work order rigor as a starting requirement, not a nice-to-have. If you want to see how this fits your specific asset base, book a demo and we'll walk through your plant's failure modes and approval chain directly in AssetAI.
Work Order Management FAQs
How does a work order in AssetAI actually show whether a repair cost ₹800 or ₹8,000?
The work order carries both a labor entry and a spares entry on the same record, so the total cost isn't scattered across a spares register and a technician's memory. When a technician logs spares used against the job, the line item cost attaches directly to that work order number; labor hours logged against the same WO add to it. Because both entries sit under one WO-000001-style ID, anyone pulling that record later sees the full cost breakdown rather than having to cross-reference a separate purchase register. This is part of what the work order module is built to hold — cost and closure on one record, not two systems that need reconciling after the fact.
How do I find out if the same bearing or motor has failed more than once this quarter?
You check the work order history against that specific asset ID, since every WO is linked to one asset rather than floating as a standalone job card. Because work orders are never deleted — only cancelled with the record intact — a search on an asset shows its complete repair history, not a curated version of it. Reviewing that history lets a reliability engineer see if the same failure type or corrective work order keeps recurring on that machine, which is the basis for deciding whether it needs a preventive maintenance schedule instead of repeat corrective fixes. The pattern only becomes visible because the records are cumulative and tied to the asset, not the shift.
Can a machine operator raise a work order themselves, or does it have to go through a supervisor?
Any user with permission to log a work order can raise one — the module doesn't force every request through a single gatekeeper before it exists as a record. A new work order defaults to Corrective, Medium priority, New status, which means an operator flagging a problem doesn't need to classify it correctly upfront; a supervisor or maintenance engineer can reclassify the type or raise the priority once they've assessed it. This keeps the reporting step fast for whoever notices the fault first, while still letting someone with more context correct the record before it moves further through its status flow toward assignment and closure.
What has to be filled in before a work order can be marked Closed?
A work order moving to Closed status needs the cost entries (labor and spares) and a record of what was actually done, so the closed record answers both what it cost and why it happened — not just that someone marked it done. Because work orders are never deleted, a closed record with missing cause information stays as a permanent gap in the asset's history rather than disappearing. This matters when the same record is pulled later for an OEM warranty claim or an internal audit against ISO standards, where a complete, closed work order history is expected rather than a summary reconstructed from memory after the fact.
Does raising a work order automatically deduct spares from stock, or is that a separate step?
Spares logged against a work order draw from the same inventory record the plant tracks stock in, so the part used and its cost are captured on the WO without a separate manual stock adjustment. This is what lets the cost side of the work order — the ₹800 vs ₹8,000 question — get answered directly from the part's recorded unit cost rather than an estimate written down after the job. It also means the inventory count reflects what actually left the shelf against a specific job, which is one of the connections covered across AssetAI's features rather than something the work order module does in isolation.
Can a technician update a work order from the shop floor instead of filling a paper job card later?
Yes — a work order can be updated from wherever the technician is working, moving through its status stages and logging cost and cause as the job progresses rather than being reconstructed from memory at the end of a shift. Updating in real time is what keeps the cost and cause fields accurate, since a technician noting the spare used and the fault reason immediately is more reliable than a paper card filled in after the fact. This is the practical difference a CMMS is meant to make over a spreadsheet or paper log — not a new process, just the same repair information captured at the point it happens instead of afterward.
If a work order is assigned to Technician A but Technician B actually does the job, how do we track who actually performed the work?
AssetAI lets you reassign the work order before closing, or add Technician B as a co-worker in the labor log. The system records actual labor hours against whoever logs time. This matters for preventive maintenance history—you need accurate technician records to spot skill gaps or training needs.
See Work Order Management on your own machines
A 30-minute demo on your plant, not our slides.