Corrective Maintenance

When a machine goes down, the work order that follows has to answer two questions with numbers, not opinions: what did this repair actually cost, and why did the asset fail. AssetAI's corrective maintenance module is built around those two requirements rather than around a generic ticketing flow — it's the same CMMS engine used for preventive work, typed as BM or CM so breakdown history stays separable from planned jobs.

What a repair actually costs, line by line

A corrective work order isn't closed with a lump-sum estimate — it's built from three kinds of lines, each priced on its own logic:

• Parts consumed on the repair, at whatever unit cost applies
• Services priced straight from the Service master, so an outside vendor's callout isn't guesswork
• Labour costed at the technician's hourly rate, added as a quantity of hours rather than tracked against a clock

Every line follows the same arithmetic — quantity × unit cost × (1 − discount%) — and the total is recomputed automatically because lines are deleted and rewritten on every save; blank lines are simply skipped. This is deliberate: AssetAI does not derive labour cost from start and complete timestamps, because that produces a job duration, not a costed hour. If your plant needs a genuine labour time clock or crew timesheets, this module is the wrong fit — it's built for repair costing, not attendance. Where it fits well is exactly the kind of plant discussed under industries and use cases: high-mix manufacturing where a breakdown pulls in a contractor's service charge, a spare part, and an internal technician's hours in the same event, and someone downstream needs all three on one line item.

Failure coding is not optional, and that's the point

Every BM or CM work order carries a failure taxonomy — mode, cause, and remedy pulled from master lists, plus free-text fields for root cause, action taken, and closure remarks. None of this is cosmetic reporting. A hard closure gate, enforced in two separate code paths, blocks completion or closure of any BM or CM work order that's missing a coded cause and a coded remedy. A technician can't skip the field and a supervisor can't override it by mistake — the check runs twice.

This matters for two reasons beyond compliance. First, failure mode and cause data only becomes useful in aggregate — Pareto analysis on recurring failure modes, or feeding OEE calculations, depends on every closed record having clean, comparable codes rather than half of them saying "fixed it" in free text. Second, it's a discipline problem as much as a data problem: without a gate, closure discipline erodes under shift pressure, and the taxonomy quietly stops being trustworthy. Standards bodies covering maintenance and reliability, including guidance referenced in ISO frameworks and the broader TPM literature, treat failure coding as foundational to any reliability program — AssetAI enforces it at the point of closure rather than leaving it to a later audit.

If you're weighing this against a lighter breakdown log, the features page lays out how corrective maintenance sits alongside preventive and predictive work orders, and pricing covers what's included at each tier. For a walkthrough on your own floor, book a demo.

Who gets pulled in, and when they're told

Raising a corrective work order isn't the end of the paperwork — it's the start of an approval trail. A new work order lands in status New and automatically opens an approval request; if it's rejected, the work order is cancelled and the rejection remark is appended to the record rather than lost. Once a job is approved and handed off, assigning a new responsible person fires a notification to them directly — nobody finds out they own a breakdown repair by stumbling across it on a shared spreadsheet. This matters more in Indian plants than the workflow diagrams suggest: shift handovers, contract labour rotating between lines, and technicians working across multiple reporting managers all make "who's on this" a question worth automating rather than asking on the floor.

Getting the right technician on the job

Instead of assigning corrective work by whoever's free, AssetAI ranks technicians against the asset's required skills and suggests the best match — a one-click add drops them onto the work order as a pre-costed labour line at their hourly rate. This doesn't replace a supervisor's judgment; it narrows the list before the judgment call is made, which matters when a breakdown call comes in at 2 a.m. and the person on shift doesn't know the full skill roster. The same form surfaces the asset's required tools and safety measures up front, and the printable job sheet — job details, safety measures, tools checklist, sign-offs — travels with the technician to the machine rather than staying in a supervisor's office. None of this is about capturing how long a repair actually took; hours are still typed as a line quantity, not derived from a clock. It's about making sure the person assigned is qualified, briefed, and equipped before they touch the asset.

Evidence, inspection, and closing the loop properly

Corrective and breakdown work orders in AssetAI go through a second check before they're truly done. Hitting Complete stamps the completion time and opens a closure inspection — someone other than the repairing technician has to look at the coded cause, the remedy, and the photos before the job is allowed to close. Up to eight repair evidence photos (8 MB each) attach on the Closure tab, and if the inspection is rejected, the work order returns to In Progress with "Inspection returned: ..." appended to the remarks, so the technician sees exactly why it bounced back rather than a bare status change. Combined with the hard rule that no BM or CM work order closes without both a failure cause and a failure remedy, this turns closure from a formality into a checkpoint — one that most plants running on paper or spreadsheets skip entirely, not because they don't value it but because nothing forces it.

This discipline is what separates ad-hoc firefighting from a maintenance function that can actually feed reliability analysis — the same failure-mode data that underpins OEE losses and reliability-centred thinking in TPM. If you're evaluating what a CMMS should cover before you commit to one, the what is a CMMS primer and the full features list are a reasonable place to start; if you want to see the module against your own breakdown log, book a demo.