How to handle broken equipment: a report-it-broken flow for shared gear (issue management for small teams)
Somebody found it broken and told one person on WhatsApp. It went out again the next day. A reporting flow that keeps faulty gear off the shelf — on paper or in software.
In this article
A wireless pack came back with a cracked battery door. The person who found it mentioned it to somebody in the corridor, and possibly on WhatsApp.
The next day it went out on a job.
That is the failure this article is about, and it is worth being precise: nothing in that story is a maintenance problem. The repair was easy. What went wrong is that a fact known to one person never became a property of the item, so the shelf could not act on it.
Why faults go unreported
Three reasons, all structural, none of them about people not caring.
Reporting is slower than shrugging. If telling somebody means finding the right person, or opening a system, or writing an email, then at 6pm on a Friday it does not happen. The report has to be faster than the guilt.
The finder is often not the owner. A freelancer, a volunteer, a student, a subcontractor. They noticed, and they are the least likely to feel entitled to raise it — especially if they suspect they caused it.
Telling a person is not telling the system. Even a conscientious report to the right colleague dies if that colleague is on holiday on Monday. A fault stored in someone's memory is not stored.
- Someone notices
- Mentions it in a corridor
- That person is off on Monday
- It goes out again
- Someone notices
- Scans it, photo, thirty seconds
- Item comes off the shelf
- Owner decides
- Closed after a test
The flow
Five parts. Each one exists to close one of the gaps above.
1. Anybody can report, in under thirty seconds
Not a form. Not an email. The lowest-friction thing your setup allows: a red tag hung on the item, a "broken" column on the sign-out sheet, a scan and a sentence on a phone.
Thirty seconds is the target because that is roughly the amount of effort a tired person will spend on something that is not their fault.
2. A photograph, wherever possible
One picture, taken at the moment of noticing. It settles what "broken" means without a conversation, it survives the reporter leaving, and it lets whoever fixes it turn up with the right part.
3. The item comes off the shelf immediately
This is the part that actually prevents the second failure, and it is the part most teams skip.
The moment something is reported faulty it must stop being available — physically moved to a "do not use" shelf, or flagged so the booking system refuses it. Not "we'll remember". Anything that relies on the next person knowing will fail the first time the next person is new.
A red tag physically tied to the item is a perfectly good implementation. The rule is that the tag is removed by exactly one process, described below.
4. One named owner, not a queue
Somebody is responsible for getting it fixed — a person, named, not "the tech team". Their job is not to do the repair; it is to decide what happens: fix it, send it out, order the part, or write it off.
A fault with no owner sits on the do-not-use shelf until somebody needs the item badly enough to take the tag off, which is the worst possible way for this to end.
5. It is closed only when it has been tested
The tag comes off after somebody has powered it on, run it, and confirmed the fault is gone. Not when the part arrives. Not when the repair is "done".
Write the close-out on the item's record: what was wrong, what was done, when, by whom. That record is what turns a series of annoyances into a visible pattern — the third time the same item comes back with the same fault, you stop repairing it and replace it.
The paper version
All five parts work without software, and if you are running twenty items that is the right answer:
- Red tags on a hook by the door. Tag has space for: what is wrong, who noticed, the date.
- A "do not use" shelf that is physically separate. Not the back of the same shelf.
- A "broken" column on the sign-out sheet, so the fault is visible to whoever looks for the item next.
- A named owner per category, on a card on the wall.
- A repair log — a notebook is fine — with one line per fault and its resolution.
The weakness of the paper version is not the reporting. It is that the record does not travel: when somebody asks "has this pack been trouble before?", nobody can answer without remembering.
What this is not
Not work orders. A CMMS-style work-order system — assignment, parts, labour, cost centres — is built for a maintenance department with technicians. If you have one, use it. A team of eight does not need a ticket workflow; it needs a flag on an item and somebody who owns it.
Not a blame process. The fastest way to stop fault reports is to make the first question "who did this?". If damage costs somebody something, they will stop reporting it, and you will find out about faults on location instead.
Where Itefy fits
The flow is the substance. What software adds is that steps 1 and 3 happen together, automatically, which is where paper leaks.
In Itefy, anyone with access can report an issue from their phone — scan the item's QR label, describe it, attach a photo, done. There is no separate reporting tool and no form to find.
Then the part that matters: an item marked inoperative stops being available for booking. Not by convention — the system refuses it, and tells the next person trying to book it why. It can still be booked for the repair itself, which is the exception that makes the rule usable. That is the red tag, enforced.
A repair job can be scheduled from the issue in one click, so the fault and the work that fixed it are linked rather than living in two places, and both stay on the item's own history — so "has this been trouble before?" is a question with an answer.
There is a 14-day free trial with no card. If you would rather start on paper, do — the five parts above are the whole idea, and the tags cost nothing.
Frequently Asked Questions
-
Everyone who touches the equipment, including volunteers, students and subcontractors. Restricting reporting to senior staff is the single most common reason faults go unreported — the person who found it is not the person allowed to say so.
-
Good. A false report costs two minutes; an unreported fault costs a job. If you find yourself discouraging reports to reduce noise, you have optimised for the wrong thing.
-
Not at this size. Work orders are for maintenance departments with technicians and parts inventories. A small team needs a flag on the item, a named owner, and a rule that the flag comes off only after a test.