Can residents report a fault by tapping a tag in their building?
Yes, and it is one of the few uses a resident has a reason to repeat. One identifier per piece of equipment turns a vague complaint into a located report. The care goes into the form: a fault report about a lift does not need to know who is standing in front of it.
A report that knows where it is
The expensive part of a fault report is not writing it, it is working out what the resident meant. The light on the third landing, the door that sticks, the second lift: a managing agent spends real time turning those into an address, an asset and a contractor.
A tap removes that. The tag carries an identifier for one piece of equipment, and the report arrives with the building, the location and the asset already attached, which the asset tag page covers for the general case.
It also removes the argument about whether a fault was already reported, because two reports against the same identifier are visibly the same fault.
What gets a tag
The things residents complain about and can point at: lifts, entrance doors, bin stores, lighting on each landing, a laundry machine, a gate. Each one gets an identifier, and the register holds what it is and who maintains it, which the fleet page plans and the maintenance page details for the contractor's side of the same tag.
Common parts are metal, damp and cleaned with strong products, so the construction is the one used for equipment rather than a paper label, and a tag that has to survive a pressure washed bin store belongs in a plate.
Put the tag where the fault is, not at the entrance. A single tag in a lobby for a whole building brings back the guessing this was meant to remove.
What the form should ask
What is wrong, and nothing else by default. The asset is known from the tag, the time is known from the request, and neither needs a name.
Offer contact details as an option, for the resident who wants to be told when it is fixed, and say plainly what the address will be used for. A fault reporting system that quietly builds a list of who complains about what is a different system from the one residents were offered, and the public tag duties page sets out what the page owes the person who tapped.
Anyone can tap a tag in a common part, including a visitor and a passer by if the door is open, so treat the form as public and design it that way, which the landing page page describes.
Closing the loop
Show the status of that asset when the tag is tapped again. A resident who taps a broken light and reads that it was reported on Tuesday and is booked for Friday does not report it again, and does not phone.
That one behaviour is what makes the system worth its cost. Without it, a tap is a suggestion box and the reports stop within a month.
Keep the tags in the maintenance round. A tag that has fallen off is a fault that goes unreported, and the replacement page covers keeping a population of tags alive over years.
Frequently asked questions
Does the resident need an application?
No. The tag holds a web address and the form opens in a browser, which is the only design a mixed population of residents will actually use.
Should the form ask who is reporting?
Not by default. The asset and the time come from the tap, and a name is only needed if the resident wants to be told when it is fixed.
One tag per building or per asset?
Per asset. A single tag in the lobby brings back the guessing about which light on which landing.
What stops false reports?
Nothing, and it matters less than it sounds: duplicate reports against one identifier are visibly duplicates, and a status shown on tap removes most of them.