4 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.

Available on: Basic.

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)

When to upgrade:

1. Add written guidance (#2) once more than one person reports faults, so urgency is judged the same way by everyone.
2. Add photo evidence (#3) once the engineer needs to see the fault before turning up, so they arrive with the right parts.
3. Add a signature (#4) once the fault record feeds an asset history and needs to show who logged it.

#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.

Available on: Standard.

What it is: The basic report 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 previous template:

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)

When to upgrade: Move to Maintenance Fault Report #3 once the words alone are not enough. Once the engineer needs to see the fault to know what part to bring, a typed description like "makes a clicking sound" leaves too much to guesswork.

#3 - 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.

Available on: Standard.

What it is: The guided report plus a photo step. The reporter takes a clear shot of the broken part, 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 snap a photo of the display showing the code and a wide shot of the machine. 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 previous template:

1. A photo step after the description, 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 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)
• 1 photo step (the fault)

When to upgrade: Move to Maintenance Fault Report #4 once the fault record feeds an asset history and needs to show who logged it, signed at the moment.

#4 - With photo and 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.

Available on: Standard.

What it is: The photo-evidenced report plus a reporter signature at the end. Four things on a single fault: a description, a location, a photo, 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, photographs 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 photo and 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 previous template:

1. A signature step at the end of every report.
2. A named, signed confirmation on the same record as the description, the location, and the photo.
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, location, and photo 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 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)
• 1 photo step (the fault)
• 1 signature step (reporter sign-off)

When to upgrade: The next variations layer Poppi on top. A Poppi briefing that surfaces the open faults on a piece of kit before you log a new one. A Poppi gate that decides whether a fault is urgent enough to alert the duty manager. A Poppi action that posts a High-urgency fault straight to the maintenance team's channel. Coming in the next post update.

How to pick the right version

You do not need to know how the canvas builder works to pick the right version. You only need to answer three questions about how your team runs.

Is it just you running this, or do other people report faults too?

If it is just you, the basic report (#1) is enough. You know what counts as urgent and you know what to write, so you do not need the canvas to coach you.

If anyone else reports faults (a colleague, a new starter, staff across departments), go to #2 onwards. The guidance panels are what stop everyone marking everything as urgent and what catch the quick fixes before they become call-outs. You write the guidance once; everyone reads it inline.

Do you need a photo as proof, or is the typed description enough?

If the person who fixes things works on the same site and can walk over to look, the typed description is enough. Go to #1 or #2.

If the fault goes to an engineer who has to travel to it, the description alone is rarely enough. They want to see the broken part before they pack the van. Go to #3. The photo at the moment of reporting gives the engineer what they need to arrive with the right parts.

Do you need someone to sign off the report?

If the fault is fixed and forgotten and nobody will ever look back at it, a record is enough. Stick at #3.

If the fault feeds an asset history that gets read again when a repair-or-replace decision comes up, the signature is the lock. Go to #4. The signature ties each fault to a named reporter on the same record as the photo and the location.

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", with a location, an urgency, and a description on every entry. The version a multi-site business runs sends the engineer a photo of the fault, which turns a two-visit repair into a one-visit repair and keeps a signed history on every machine.

Pick the version that matches how your team reports today, not the most sophisticated one you can imagine running someday. Open each template in the playground above and log a real fault with it this week.