5 ways to automate maintenance fault reports

#1 - The basic check-in

Who it's for: Single-site businesses logging the odd fault, where one person spots a broken bit of kit and needs to get it in front of whoever fixes things.

What it is: A maintenance fault report is a short structured log that takes a broken bit of kit or fixture from "someone noticed" to "someone is on it". Four steps on a phone: name what's broken, drop a location pin, set the urgency, and describe what it does or does not do. Each completion is one fault on the record, ready for the person who picks up repairs.

In practice: Take a three-site garden centre. A till assistant notices the card reader at the plant counter has gone dead mid-shift. Instead of shouting across the floor or leaving a note that gets thrown away, they open the canvas, type "card reader at plant counter", drop a pin on the till, set urgency to High because it stops sales, and type "screen is black, no power light". Submit. The fault is now a dated record the duty manager can see, not a memory that fades by closing time.

Why it works: The report is the handover. A fault that lives in someone's head, or on a sticky note, depends on that person remembering to pass it on. A logged fault does not. The moment it's submitted there is a dated record with a location and an urgency, so the person who fixes things can sort the urgent from the can-wait without chasing anyone for detail.

Steps included:

• 1 text input (what's broken)
• 1 location step (GPS pin)
• 1 single-choice step (3 options: Low, Medium, High)
• 1 text input (what it does or does not do)

#2 - With written guidance

Who it's for: Sites where several people report faults to one team, and where "urgent" means different things to different people.

What it is: The basic check-in plus two guidance panels woven through the canvas. One panel explains what actually counts as urgent so the High flag stays meaningful. The other explains what to try before reporting, so a tripped switch gets reset on the spot instead of becoming a call-out. A new starter on their first week judges urgency the same way as the shift supervisor, without anyone having to brief them.

In practice: Take a 30-room hotel. Housekeeping, reception, and the kitchen all report faults to one maintenance person. Without guidance, everything gets marked High: a flickering bulb in a corridor and a leaking pipe under the kitchen sink look identical on the list. The "what counts as urgent" panel sits right above the urgency choice and tells the reporter that High means it stops the work today or it's a safety problem. The "what to try first" panel reminds them to flip a tripped switch back before logging it. The maintenance person opens a list where High actually means High, and the bulb waits its turn.

What it adds to the basic check-in:

1. A "what counts as urgent" panel that sets the bar for the High flag, so urgent faults stand out instead of getting lost in a list where everything is High.
2. A "what to try before you report" panel that catches the quick fixes a reporter can do themselves, like resetting a switch or swapping a bulb.
3. A consistent standard across reporters, so the same fault gets the same urgency whoever logs it.

Why it works: Written guidance sits inline at the moment the reporter is about to act. The reader sees the urgency standard the instant before they pick High, Medium, or Low, not in a handbook they skimmed on day one. It is on the screen at the moment of the decision, which is the only moment it changes the outcome.

Steps included:

• 1 guidance panel (what counts as urgent)
• 1 text input (what's broken)
• 1 location step (GPS pin)
• 1 single-choice step (Low, Medium, High)
• 1 text input (what it does or does not do)
• 1 guidance panel (what to try before you report)

#3 - With a signature

Who it's for: Businesses needing a signed fault record for the asset history, where each piece of kit carries a log of every fault and who reported it.

What it is: The basic check-in plus a reporter signature at the end. Four things on a single fault: a description, a location, an urgency, and a signed confirmation that the report is accurate. The signature ties the record to a named person, which is what an asset history needs when a piece of kit has been repaired five times and someone is deciding whether to replace it.

In practice: Take a commercial laundry running three plants of industrial machines. Every machine has a service history that follows it for its working life. When an ironer trips out, the shift lead logs the fault, sets urgency to High, describes the burnt contactor, and signs the report on the touchscreen. The signed record attaches to that machine's history. Two years later, when the plant manager reviews whether to refurbish or scrap the ironer, the history shows six signed faults, each with a named reporter, and the replace decision makes itself. No "who said this broke again?" because every entry is signed.

What it adds to the basic check-in:

1. A signature step at the end of every report.
2. A named, signed confirmation on the same record as the description and location.
3. A fault history that holds up when a repair-or-replace decision needs a defensible paper trail.

Why it works: The signature is what attaches the fault to a person. The description and location say what broke and where; the signature adds who reported it and that they stand behind it. On an asset history that may be read years later by a manager, an auditor, or an insurer, a signed entry carries weight that an anonymous one does not.

Steps included:

• 1 text input (what's broken)
• 1 location step (GPS pin)
• 1 single-choice step (Low, Medium, High)
• 1 text input (what it does or does not do)
• 1 signature (sign-off)

#4 - With photo evidence

Who it's for: Multi-site businesses wanting photo proof for the engineer, so the person who turns up already knows what they are dealing with.

What it is: The basic check-in plus a photo step. The reporter takes a close shot of the broken part or faulty item, and the photo lands in the fault record alongside the location pin and the description. A photo of a cracked valve or a model number on a dead motor tells the engineer more in one glance than a paragraph of typing, so they arrive with the right parts the first time instead of making a second trip.

In practice: Take a regional gym chain with eight sites. A duty manager at one branch finds a treadmill throwing an error code and grinding when it runs. They log the fault, set urgency to Medium, type "error E5, grinding noise under the belt", and take a close photo showing the error code on the display. The fault routes to the contracted engineer, who reads the code straight off the photo, recognises the belt fault, and loads the right belt before leaving the depot. One visit instead of two, because the photo did the diagnosis before anyone drove anywhere.

What it adds to the basic check-in:

1. A close photo of the broken part or faulty item, so the fault is shown as well as told.
2. Visual detail an engineer can act on, like an error code, a model number, or the exact part that has failed.
3. Fewer wasted call-outs, because the engineer can prepare from the photo instead of diagnosing on arrival.

Why it works: A description is what the reporter thinks is wrong. A photo is what is actually there. The two together let the engineer plan the fix before they leave, which is what turns a two-visit repair into a one-visit repair. Captured on the same device at the moment of reporting, the photo cannot be vague the way words can.

Steps included:

• 1 text input (what's broken)
• 1 location step (GPS pin)
• 1 single-choice step (Low, Medium, High)
• 1 text input (what it does or does not do)
• 1 photo of the broken part

#5 - With Poppi checking the photo

Who it's for: Multi-site teams where the photo gets taken but nobody reviews it. Head office teams that cannot look at every site's photos on the day they are taken.

What it is: A photo-checked fault report is the basic check-in plus a photo of the broken part that Poppi (AI) reviews the moment it's saved. Poppi answers one question about that photo, set by you: does the photo clearly show the specific fault being reported? A single named spot is something an AI can actually judge, where a wide shot of a whole area is not. If the answer is no, Poppi posts what it spotted to the team chat, so the photo gets retaken while the reporter is still there.

In practice: A regional facilities team manages five buildings. A maintenance worker finds a crack in a window and takes a photo. Poppi reads it: the crack is clearly visible, sharp and centred. Verdict yes, and nothing changes. On another day a photo shows a corner of the building with poor lighting and the crack is lost in shadows. Poppi answers no and posts the reason to the team chat ("The photo is too dark and doesn't show the damage clearly"). The worker steps back into better light, takes a second photo, and this time Poppi says yes.

What it adds to the basic check-in:

1. A photo of the broken part that gets checked the moment it's saved, not just stored
2. A team chat message with Poppi's reason the moment a photo fails the check
3. The manager stops being the only person who ever looks at fault photos

Why it works: The check happens in the seconds between the photo being taken and the reporter moving on. That's the only moment the photo is cheap to retake. A manager reviewing photos the next morning can only flag that one was unclear; Poppi catching it instantly gets it right before the reporter leaves the site.

Steps included:

• 1 text input (what's broken)
• 1 location step (GPS pin)
• 1 single-choice step (Low, Medium, High)
• 1 text input (what it does or does not do)
• 1 photo of the broken part
• 1 Poppi decision (judges the photo against your question)
• 1 Poppi action (posts to the team chat if the photo fails the check)

How to pick the right version

You do not need to know our product to choose. Every version here is the basic check-in plus one addition, so pick the additions your team actually needs.

Do other people report faults, or is it just you?

If you report faults yourself and know what counts as urgent, the plain list is enough: #1. The moment rota staff or multiple people report, the guidance needs to sit on the screen so everyone judges urgency the same way: #2.

Does the fault record need a name against it?

If a fault is logged and fixed and nobody looks back at it, a record is enough. Skip this one. If the fault feeds an asset history that gets read when a repair-or-replace decision comes up, the signature ties each entry to a reporter: #3 adds a signature.

Do you need photo proof?

A typed description is what the reporter thinks is wrong. A photo is what is actually there. If the person who fixes it works on the same site and can walk over to look, the words are enough. If the fault goes to an engineer who has to travel to it, they want to see the broken part before they pack the van: #4 adds a close photo.

Does anyone actually look at the photos?

If a manager genuinely reviews every photo the day it arrives, #4's record is enough. If photos get taken and filed unseen, #5 has Poppi (AI) check each one as it's saved, and tell the team chat when a photo is too dark or unclear to judge the fault.

Need more than one addition? Open the version with the addition that matters most in the playground and add the others as steps. That's how the product works anyway: every option here is one step added to the same form.

Related workflows

• 4 ways to automate damage reports
• 4 ways to automate hazard spotting
• 4 ways to automate near-miss reports
• 4 ways to automate tool and asset checkout
• 4 ways to automate job completion sign-off

Conclusion

A maintenance fault report is a short structured log that takes a broken bit of kit from "someone noticed" to "someone is on it". Every version above is the same basic check-in plus one addition: guidance, a signature, a photo, or an AI check on the photo. Pick the ones your team needs and combine them in the playground. A photo at reporting time turns a two-visit repair into a one-visit repair; a signature keeps a defensible asset history; guidance stops everyone marking everything urgent.

→ Build your own maintenance fault report on Pilla.