Monday morning, the lift is down again
The lift at one of your larger blocks stopped on Saturday. By Monday your inbox holds eleven emails, the phones have taken six calls, two leaseholders have posted in the building's WhatsApp group and a director has emailed the property manager directly. Several of these people are angry that nobody has replied.
Someone has already called the lift engineer. But every report is sitting in a different place, and each person is waiting for their own answer.
Why the same fault becomes many jobs
Most block management offices log repairs per report, not per fault. A tenant, a leaseholder and a cleaner reporting the same broken door create three records, or none, depending on who picks up the email. Repair reporting tools such as Fixflo help with the intake, but grouping reports about a shared area still falls to a person.
Residents also cannot see that a job is in hand, so they report again. Every extra report is another interruption and another reply to write.
The cost of handling it report by report
Staff time goes on replying to the same question, often with slightly different information, which then gets compared in the WhatsApp group. Contractors sometimes get called twice. And the history for the block shows a cluster of disconnected reports rather than one fault and its cause, which makes repeat problems harder to see.
It also shapes how residents feel about your firm. A slow or silent response to a shared fault is one of the most common reasons directors start looking at other managing agents.
How we group and update communal reports
We build an intake layer that sits in front of your existing repair process and treats a communal fault as a single job with many reporters.
- One front door: reports from email, web form, phone notes and your repair reporting tool arrive in one queue, with the block identified from the address or sender.
- Fault matching: a language model reads each report and compares it with open jobs at the same block, proposing a match such as 'same lift fault as job opened Saturday'. A person confirms with one click.
- Reporter list: each matched report adds the resident to the job's update list instead of creating a new job.
- Status updates: when the job status changes, for example engineer booked, part ordered, fixed, every reporter gets a short update by email or text through Twilio.
- Block notice: for faults affecting the whole building, the property manager can send one update to all residents of the block.
- History: the job keeps every report, update and invoice together, so repeat faults on the same asset are visible.
| Before | After |
|---|---|
| Each report handled separately | Reports grouped onto one job per fault |
| Residents chase for updates | Everyone who reported is updated when the job moves |
| Contractor sometimes called twice | One job, one works order |
| History scattered across inboxes | One record per fault with the full story |
What the office feels like afterwards
When the lift fails, the first report opens a job and later ones attach to it. The property manager updates the job once and everyone who reported hears about it. Replies to angry emails become rare because people are not left wondering.
Over time the job history per block starts to show which assets fail repeatedly, which is useful evidence for the next budget or a conversation about replacement.
Signs you are handling faults report by report
- The same communal fault generates many emails and calls.
- Residents ask whether anyone knows about a problem you are already fixing.
- Contractors have been sent twice for the same job.
- Updates are written one by one to each person who reported.
- You cannot easily see how often an asset at a block has failed.