One Pipe, Forty Tickets: Killing Duplicate Work Orders
When one event triggers dozens of identical reports, your team dispatches vendors against duplicates and buries the one report that was actually different. Here is the fix.
The short answer
Duplicate maintenance requests after a storm happen because dozens of residents report the same event separately. The fix is clustering: group near-identical reports (same building, same symptom, same window) into one incident record, dispatch one vendor, and update every reporter from that single record instead of triggering forty truck rolls.
9:14 a.m., one broken pipe, forty tickets
A riser fails on the third floor of Building C. Water sheets down the stairwell. By 9:14 a.m. your queue shows 40 open work orders and they are still coming in: "water in hallway," "leak stairwell C," "ceiling dripping unit 314," "why is water everywhere," three of them in Spanish, two left as after-hours voicemails, one filed as an emergency and one filed as "low priority, whenever."
It is one incident. Your queue thinks it is forty. A dispatcher who is moving fast (and everyone moves fast during a surge) starts assigning vendors against the queue as it reads. That is how you end up with two plumbers, a water-mitigation crew, and a drywall vendor all rolling to the same address for the same puddle, while the resident on floor five with a genuinely separate ceiling leak sits at ticket 38, invisible under the pile.
The duplicate surge is not a software bug. It is a predictable human behavior: when something visible and scary happens, people report it in parallel, through every channel they have, and they do not check whether their neighbor already called.
Key takeaways
- One visible event reliably spawns dozens of near-identical reports across phone, email, portal, and text.
- Dispatching against a raw queue triggers duplicate truck rolls and buries the one report that is actually different.
- Clustering reports into a single incident record fixes both problems at once.
- A human still confirms the cluster and owns the split decision when a report does not belong.
What does dispatching against duplicates actually cost?
The short version
Dispatching against duplicates costs you in three places: wasted trip charges and vendor goodwill for phantom calls, dispatcher hours spent triaging noise, and reputation damage when the one genuinely different report gets missed inside the pile. During a storm all three spike at the same time.
The obvious cost is the trip charge. A vendor who shows up to a job another vendor already handled still bills you for the roll, and if you send three crews to one puddle, you eat three rolls for one repair. During a regional storm event vendors are scarce and their time is the most expensive it will be all year.
The quieter cost is your dispatcher's attention. Every minute spent reading, deduping, and re-reading a 40-ticket pile by hand is a minute not spent on the incident that needs a person: the life-safety call, the angry owner, the second real leak. Attention is the resource that collapses first in a surge, not vendor availability.
The most expensive cost is the miss. When ticket 38 is a separate leak in a different stack and it drowns in a pile of duplicates for the first incident, the resident who filed it correctly gets no response for hours. That is the report that turns into a bad review, an insurance dispute, or a call to the owner asking why they pay you. The duplicate surge does not just waste money. It hides the one thing you most needed to see.
How clustering turns forty tickets into one incident
Clustering is the practice of grouping incoming reports that describe the same underlying event into a single incident record, so you dispatch and track it once. It is the opposite of the default, where every report becomes its own ticket the moment it lands.
This is the specific job we built Mason Maintenance to do during a surge. Mason reads each incoming report as it arrives, no matter the channel, and asks a narrow question: does this describe an event already open? It compares building or stack, the symptom (water, power, elevator, smell), and the time window, and when the answer is yes, it attaches the report to the existing incident instead of spawning a new ticket.
- 01
Normalize the report
Pull the structured signal out of messy input: which building, which floor or stack, what symptom, when. A voicemail, a portal form, and a text about the same leak should reduce to the same three or four facts.
- 02
Match against open incidents
Compare the new report to incidents already open in the same location and time window. "Water in stairwell C" and "ceiling dripping 314" in the same fifteen minutes are almost certainly one event, not two.
- 03
Attach or open
If it matches, attach it as a reporter on the existing incident. If it does not match cleanly, flag it as a possible separate issue and route it to a human rather than guessing.
- 04
Dispatch once
The incident, not the ticket count, drives dispatch. One plumber, one mitigation crew, assigned against one record with every reporter's unit attached so the vendor knows the full footprint.
The honest limit: clustering is only as good as its willingness to say "I am not sure." An agent that force-merges everything to keep the queue clean is dangerous, because it will bury real second issues. The right behavior is aggressive on the obvious duplicates and conservative on the ambiguous ones, kicking those to a person. We cover where this line sits in AI work order triage.
Keeping forty reporters informed from one record
Quick answer
Clustering only helps residents if every reporter still gets updates. The fix is to keep each person attached to the single incident record and push status to all of them from that one place, so "we see it, a crew is en route, it is resolved" reaches everyone without forty separate manual replies.
The failure mode of naive deduping is that 39 people get merged and then hear nothing, because the system treats their reports as noise. That feels worse to a resident than the duplicate itself. They reported a real problem and got silence.
Clustering done right keeps every reporter as a named contact on the incident. When the vendor is dispatched, all of them get the same acknowledgment. When it resolves, all of them get told, in their own channel and language. One record, one source of truth, many notifications. The resident does not know or care that their report was the 31st. They only know they were heard and updated.
| What happens | Raw ticket queue | Clustered incident |
|---|---|---|
| 40 reports of one leak | 40 open tickets | 1 incident, 40 reporters attached |
| Dispatch | Risk of 3+ overlapping rolls | 1 vendor assigned to the incident |
| Resident updates | Manual, inconsistent, often skipped | One push to all reporters, each channel |
| A genuinely separate 2nd leak | Buried at ticket 38 | Flagged as possible new issue for a human |
| Dispatcher time | Hours reading and deduping by hand | Confirming clusters and owning edge cases |
When a duplicate is actually a second real problem
This is the part that keeps clustering honest, and it is where a human has to stay in the loop. Not every report that looks like a duplicate is one. During the exact event that spawns forty copies, a second, unrelated failure often happens somewhere else in the building, and the pressure to "just clear the pile" is precisely when it gets missed.
The rule we hold Mason to: cluster confidently only when location, symptom, and timing all line up. When one of those is off (a leak in a different stack, a different symptom like a burning smell, a report that lands two hours after the incident was marked resolved), the report does not get merged. It gets surfaced as a candidate separate issue, and a person decides.
“The whole value of deduping is speed, but the whole risk is confidence. We would rather the agent over-flag ten borderline reports for a human to glance at than silently swallow the one that was a different pipe. Merging is cheap to undo when a person is watching. A missed second leak is not.”
Todd Paton, Partner, One Home Agent
Checklist
0/6Signals that a "duplicate" is really a second issue
Why this matters most from June through November
The duplicate surge is a year-round annoyance and a hurricane-season crisis. A single storm hits every property in your portfolio at once, so the surge is not one incident of forty reports, it is dozens of incidents of forty reports arriving in the same afternoon, across communities, while vendors are stretched thin and residents are frightened.
According to the Insurance Information Institute, hurricanes and related wind and water events drive a large share of catastrophe losses in coastal states, and Florida sits in the direct path most seasons. The operational reality behind that statistic is a call queue that goes vertical for 48 hours and does not care that your dispatcher is one person.
That is the argument for having the clustering layer running before the storm, not standing it up during one. The teams that handle a surge cleanly are the ones where the dedup and multi-reporter updates are already routine on an ordinary Tuesday leak. Build the muscle in the calm months. See our hurricane communication plan for property management for the wider playbook.
Bottom line
The duplicate storm surge is a solved problem, but only if you solve it structurally: cluster reports into incidents, dispatch against the incident, update every reporter from one record, and keep a human owning the split-versus-merge call. Do that and forty tickets become one truck roll and forty people who feel heard.
See what your maintenance queue looks like without the duplicates
We build Mason Maintenance and the rest of our operations agents on your own communities and workflows. The first one is free, and you keep it. Let us show you how clustering handles your next surge.
Explore PM operations agentsFrequently asked questions
One visible event, like a stairwell leak or a common-area outage, is witnessed by many residents at once. Each person reports it independently through phone, portal, email, or text without checking whether a neighbor already reported it. A single incident can therefore generate dozens of near-identical work orders within minutes.
Sources & further reading