How should property teams handle duplicate maintenance requests?
Format: Article.
Link requests only after a person checks the property, unit, issue, and time reported. Keep each message. A repeat of the same message may be a duplicate. But a second resident's report is a new account. Keep it even if both reports seem to concern the same repair.
Aim for one clear work plan, not the fewest tickets. A report may add a new symptom, a contact choice, or a fact the vendor needs. Do not delete it to tidy the queue. Staff should be able to undo a link. A link does not tell you the cause of a problem or how urgent it is.
Separate the report from the repair
Buildium's maintenance guide distinguishes a resident request from the work order that holds the action plan. It also recommends tracking status changes and completion evidence. That distinction is useful here: several reports can inform one work plan without becoming one resident record. [S01]
Use two IDs. A report ID points to the message that came in. A work ID points to the planned repair task. Link the two records rather than replace either one. Keep the exact words and files. Keep the same rules for who can see each report.
Do not label a resident as a duplicate. Label the relationship between specific records. A person who reports the same issue again may be adding new information or asking about stalled work.
Use this duplicate-versus-related decision tree
Use the first two rows to check the location. If either check fails, keep the reports separate for review. Then ask whether the later report adds facts. Only a resend with no new facts can become a proposed duplicate. A person must check the link before it is saved.
| Check | If yes | If no or unclear |
|---|---|---|
| Do property and building IDs match? | Check the unit or shared area | Keep separate; ask for location clarification |
| Does the unit or asset match? | Compare the reported issue | Consider a related building issue, not a duplicate |
| Does the later report add a time, symptom, photo, or changed condition? | Keep the new facts as an update; do not call it a duplicate | Check whether it is an exact resend |
| Is this the same submission resent without new facts? | Ask a person to check a proposed duplicate link | Keep it as a separate report |
| Has a manager confirmed the shared work plan? | Link the approved work ID | Leave a proposed relationship for review |
Matching words are a clue, not proof. “Water under sink” could mean two sinks in nearby buildings. The street address alone does not identify a unit. Check the property, building, unit, and fixture ID if one exists. Use only records the reviewer may see.
Send a possible safety concern to staff through the team's approved response path. Do not wait for the link review to pass on that message. This tree does not decide urgency, housing matters, or repair needs.
Make every link reversible
Use this small link log:
- Original report IDs and proposed work ID.
- Relationship: exact resend, added update, or related issue.
- Matching evidence and facts that differ.
- Reviewer, decision time, and reason.
- Resident-specific communication tasks that remain open.
- Reversal note, if the relationship is later removed.
Before you link reports, save who owns each one and its current state. After the link, check that staff can still open both reports. Check their files too. Neither resident should gain access to the other's private facts. Keep separate follow-up tasks if they need different answers.
To undo a wrong link, remove it and restore the right task owner. Add a note saying why. Keep the wrong match in the history so staff can trace what changed. If staff sent a message based on that match, ask the manager whether to send a correction.
Hypothetical example: two kitchens, one possible pipe issue
At a fictional property, report R41 concerns moisture in building East, unit 204. R42 uses nearly the same words but concerns unit 304. R43 is a second upload of R41 from the same resident, with no changed facts.
The coordinator proposes an exact-resend link for R43. R41 and R42 stay separate. A manager may link them to one task to find the cause. That does not prove they share a cause. A person with the right skills must inspect the issue.
Later, the resident in 204 sends a photo with a new observation. It becomes an update to R41, not another discarded duplicate. Closing a shared investigation would not, by itself, close either resident's unresolved concern.
Check the design before using it
Test two units with the same number in different buildings. Try a repeat upload, a shared-area report, and a changed symptom too. Can staff undo each link without losing the source or giving more people access? Count wrong links apart from checked resends. Fewer tickets alone do not prove better service.
Core Agentic can discuss a custom design for this review queue. It is not a finished property platform. We would first agree on access, system links, and any use of cloud services. Managers decide what to send residents, what to spend, and all housing matters.
Book a Demo to discuss a maintenance-linking workflow that keeps each resident's evidence intact.
Sources
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.