Tenant communication
How to communicate building-wide repair problems
Communicate shared building repair problems with one incident record, consistent updates, private exceptions, and a clear path from first report to closure.
A broken lift, heating outage, entrance fault, water interruption, or shared leak can generate many tenant reports within minutes. If each report becomes a separate investigation, staff repeat the same work and residents receive different answers about one problem.
The better model is one building incident for shared facts, linked to private requests where individual circumstances still matter.
Confirm the scope before broadcasting
The first report may describe a personal issue. Before treating it as building-wide, check:
- which homes or shared areas may be affected;
- whether monitoring or other reports show the same symptom;
- whether there is an immediate safety risk;
- whether the issue affects an essential service;
- whether a current planned-maintenance activity is related;
- what is confirmed and what remains under investigation.
Do not wait for complete certainty before sharing urgent safety advice. Clearly label what is known, suspected, and still being checked.
Create one source of truth
The building incident should contain:
- a specific title and affected location;
- start time or first known report;
- current impact;
- priority and safety instructions;
- internal owner;
- contractor or specialist involvement;
- next operational action;
- next tenant-update deadline;
- linked personal reports;
- timeline of published updates;
- resolution and monitoring notes.
Staff answering calls or messages should use this same record. That reduces contradictory estimates and prevents residents from having to collect information from neighbors.
Link duplicate reports without dismissing them
When a tenant reports a known incident, confirm that their message was received and linked. Do not simply close it as a duplicate.
Example:
We have linked your report to the heating interruption affecting Riverside Tower. The heating contractor is investigating on site. Shared updates will appear here, with the next update by 14:00. Reply to this request if your household has an urgent individual need.
The linked report can record the affected unit and any private follow-up while the incident remains the public source for common updates.
Send the first update with useful facts
A strong initial message answers:
- What service or area is affected?
- Which building or part of the building is in scope?
- What should residents do now?
- What action has the housing team taken?
- When will the next update arrive?
- How can a resident report an urgent exception?
Avoid guessing a completion time. If no estimate is available, say so and commit to the next information point.
We are investigating a loss of hot water in Buildings A and B. The heating contractor is travelling to the site. You do not need to submit another general report. Contact the emergency line if there is active leakage or another immediate safety risk. We will publish the next update by 11:30.
Set a communication rhythm based on impact
Update frequency should reflect urgency and resident impact, not only how often new technical information arrives.
| Situation | Example update rhythm |
|---|---|
| Immediate safety issue | Initial warning, then updates at short defined intervals |
| Essential service unavailable | Update when attendance is confirmed and at each promised checkpoint |
| Significant shared inconvenience | Scheduled updates even when investigation continues |
| Stable non-urgent defect | Update when the next action or appointment changes |
These are workflow examples, not universal service standards. Define the actual intervals in your incident policy.
Every update should include the current status and next checkpoint. Use the approach in repair status updates during delays when the technical solution remains uncertain.
Keep private circumstances private
The shared incident should not expose names, unit-specific medical information, photos from inside a home, access arrangements, or complaint details.
Use linked private requests for:
- a resident who depends on a lift for mobility;
- medical or safeguarding concerns;
- damage inside one home;
- alternative access or temporary support;
- a tenant who cannot use the normal communication channel;
- a separate fault that only appears similar.
The incident can state that individual support is available without identifying who requested it.
Coordinate channels around the incident
Different residents may rely on email, portal messages, phone, printed notices, or on-site staff. Multiple channels are useful when they all draw from the same incident record.
Decide:
- which channels are used for each priority level;
- who approves urgent safety messages;
- how call-center staff see the latest update;
- whether building notices need translation or simplified language;
- how residents without digital access are reached;
- how outdated notices are removed or marked resolved.
Do not let a WhatsApp message, personal mailbox, and lobby notice develop separate versions of the incident. The article on WhatsApp for property management explains the risks of fragmented records.
Distinguish incidents from planned maintenance
Planned work can be communicated in advance with scope, access requirements, schedule, expected disruption, and reminders. An unplanned incident starts with uncertainty and needs a faster update loop.
When planned work creates an unexpected outage, link the incident to the maintenance communication but do not silently edit the original announcement. Residents need a visible explanation of what changed. See how to communicate planned building maintenance for the preparation workflow.
Close publicly and follow up privately
When service is restored:
- State what was restored and when.
- Explain whether monitoring or follow-up work continues.
- Tell residents how to report a remaining personal issue.
- Keep linked private requests open where necessary.
- Record the technical and communication timeline for review.
Example:
Hot water service was restored at 16:20. The contractor will monitor the system remotely overnight. If your home still has no hot water after running the tap for several minutes, reply to your existing request so we can check the unit separately.
This closes the shared incident without assuming every private symptom disappeared at the same moment.
Review the incident after closure
Look beyond technical repair time. Review:
- time from first report to incident creation;
- duplicate reports received before and after the first update;
- whether each promised update was delivered;
- inconsistent messages across channels;
- private cases that required separate support;
- contractor and internal handoff delays;
- tenant questions the updates did not answer.
Use those findings to improve templates, escalation, and channel coverage for the next event.
Property manager communication software can connect building incidents, private tickets, announcements, and a shared timeline without becoming a complete property management suite. Sicket is designed for this building-scoped communication. Review the product overview or schedule a demo to see it in practice.
