Guide6 min read
How to take maintenance requests over WhatsApp without losing them
Ask a facilities supervisor where requests come from and the honest answer is usually a WhatsApp group. It works because everyone already has it and because a photo explains a fault better than a form. It fails for reasons that have nothing to do with the app.
By the FM360AI team
Why a WhatsApp group stops working
- Nothing has an owner. Twenty people saw the message, so everyone assumes someone else has it.
- Nothing has a state. There is no way to tell open from done without scrolling and asking.
- Several problems share one message. The light and the leak are reported together and only the light is fixed.
- Nothing can be counted. You cannot say how many requests arrived, how long they waited or which building generates most of them.
- Urgent and trivial look the same. A sparking socket sits between two messages about a squeaky door.
What not to do: ban it
The usual reaction is to announce that requests must now go through a portal. Adoption drops, the group carries on unofficially, and supervisors spend their time retyping messages into the system. The reporting habit is worth keeping. What needs to change is what happens after the message is sent.
A design that works
- Give people one number to message, not a group. A direct message to a facilities number is private to the reporter and unambiguous about where it goes.
- Turn every message into a ticket automatically. If a person has to decide whether to log it, some will not be logged.
- Split messages that contain more than one problem. Each issue needs its own owner and its own finish.
- Classify on arrival. Category, priority and location should be filled in before a supervisor sees the ticket, so their job is to check and assign rather than to type.
- Acknowledge with a ticket number. The reporter needs to know it landed, and needs something to quote if they follow up.
- Decide who may report. Either anyone who has the number, or only recognised staff with everything else held for review.
- Treat safety differently. A report of exposed wiring at nine at night should not wait for the morning queue.
- Close the loop. Tell the reporter when the job is done and ask whether it was done properly.
What to measure once it is running
| Measure | What it tells you |
|---|---|
| Requests by source | Whether people are using the channel you intended |
| Time from message to assignment | How quickly triage happens |
| Time to completion against target | Whether service levels are realistic |
| Unassigned tickets | Work that nobody owns right now |
| Reopened tickets | Jobs that were closed but not fixed |
| Feedback rating | What the people who reported think of the result |
Practical points
- Ask reporters to say where the problem is. A photo of a tap does not say which washroom.
- Tell people what to expect. If messages are processed every few minutes and routine reports wait until working hours, say so.
- Keep the original message and media on the ticket. The technician should see what the reporter saw.
- Review the rejected and unclear messages weekly for the first month and adjust your rules.
How FM360AI does it
FM360AI links to a WhatsApp number your team controls. Incoming text, photos, video and voice notes are read by AI, split into separate issues and created as tickets with a category, priority, area and SLA drawn from your own configuration. The reporter receives the ticket number, and a completion message with a feedback link when the ticket is closed. In strict mode, messages from unknown numbers go to a review queue instead.
FM360AI connects by pairing a WhatsApp number, as WhatsApp Web does, not through the WhatsApp Business Platform API. Intake is one-way: there is no chatbot or status lookup by message.
