Condominium Requests: Managing Reports and Tickets

A water leak reported by phone in the morning, repeated on WhatsApp in the afternoon by another owner, and finally by email from a third owner asking "any news?" — it is the most common scenario in a studio running several condominiums, and it is also why reports are where the most time gets lost without anyone having done anything wrong in particular.
Three channels, one queue
Phone, WhatsApp and email are not the problem. The problem is when they stay three separate channels, each with its own memory: what comes in by phone is known only to whoever answered, what lands on WhatsApp gets lost in the scroll after two days, what arrives by email waits for someone to read it. The same leak, reported three times by three different people, looks like three different problems until someone puts them together.
A single queue does not mean forcing owners onto one channel — that is unrealistic and would not help anyway. It means that whichever channel a report arrives through, it ends up in the same place, with a status anyone in the studio can check without having to ask the colleague who took the call.
The flow that holds up
A structure that works, regardless of the tools behind it:
- A report with a photo and the floor. A photo of the problem and where it is (floor, staircase, unit) removes the slowest step: the phone call where someone tries to describe in words where the leaking pipe is.
- Classification. Type of problem and urgency. An active leak does not wait in the same queue as a stairwell light that needs replacing.
- Assignment to a supplier, with a deadline. The report moves to whoever has to act, with an indicative deadline — it does not stay generically "with the studio".
- Closing with confirmation to the owner. It is not enough for the supplier to have fixed it: the report closes when whoever opened it gets an explicit confirmation. Without this step, the owner calls back to ask whether anything was done, and the queue has added a channel instead of removing one.
The step that gets skipped most often is exactly the last one. A studio can fix an issue the same day and still leave the owner wondering whether anyone knows, simply because nobody closed the loop.
A concrete example makes the point. Monday morning brings three reports on the same building: an intercom that doesn't ring (reported by email), a burnt-out garage light (WhatsApp), and a leak under the sink in the common areas (phone call, worried tone). Without a single queue, each one ends up with a priority decided by whoever received it — often in order of arrival, not real urgency. With explicit classification, the leak moves ahead first not because it "sounded serious on the phone" but because it is the one where the damage keeps getting worse over time; the intercom and the light stay tracked all the same, each with its own deadline, instead of disappearing behind the day's loudest problem.
Why a single queue also cuts down duplicate requests
A secondary, and not small, effect of visible status: when an owner can see their report is "assigned to a supplier" instead of feeling ignored, the second follow-up call becomes rare. The building's WhatsApp group, by comparison, keeps no state of anything — it distributes messages, it doesn't close them — which is why an active group and a studio that keeps getting phone calls often coexist: the two do not replace each other.
What to measure
Three numbers are enough to know whether the process holds, and they are more useful than a general sense of "how responsive we are":
- First-response time. From when the report arrives to when someone takes ownership of it — not resolves it, takes ownership. It is the number owners notice before any other.
- Closing time. From opening to actual closure, not to "assigned to a supplier".
- Reopenings. Closed reports that come back open within a few days. It is the most uncomfortable indicator and the most honest one: a fast closure that reopens twice is not a fast closure, it is a badly handled report counted twice.
Without these numbers, "we handle reports well" stays an impression, not something you can show an owner who is complaining or bring to the assembly.
Two legal touchpoints: preservative acts and ordinary maintenance
There are two direct statutory references on this topic, and they cover different things. Art. 1130, no. 4, of the Civil Code requires the administrator to "compiere gli atti conservativi relativi alle parti comuni dell'edificio" — carry out preservative acts on the common parts: for example the urgent measures needed to stop damage to common parts from getting worse, the leak that risks flooding the floor below, not the stairwell light bulb. Art. 1130, no. 3, covers different work: "riscuotere i contributi ed erogare le spese occorrenti per la manutenzione ordinaria delle parti comuni dell'edificio e per l'esercizio dei servizi comuni" — collecting contributions and paying for the ordinary maintenance of common parts and the running of common services, the scheduled, budgeted, non-urgent work that a report can still trigger (the stairwell light that needs replacing, for instance). Which one applies depends on the underlying work, not the channel the report arrived through; and neither sets a response deadline or a duty to act on every report received. Worth knowing because it marks what is genuinely regulated by law, not only by operational common sense.
What the app actually does
On the Base plan, Unitify includes the classificatore AI delle segnalazioni (AI report classifier): reports arrive already categorized by type, instead of having to be read and sorted by hand one by one. On the Pro plan, the AI concierge also covers requests that today come in by phone, bringing them into the same queue as everything else instead of leaving them on a separate channel.
What stays with the administrator is the decision: which supplier to assign, when something is genuinely urgent, how to respond to a disputed report. No tool decides for you whether a problem is a preservative act or can wait for the next scheduled maintenance round — that judgment stays a judgment, not an automation.
The rest — photo and floor already attached, status visible to the whole studio, closure confirmed back to the owner who reported it — is exactly what we covered writing about what a resident condominium app needs to do.
If your studio's reports still live across three separate channels, book a demo to see how a single queue works.
Frequently asked questions
Which channels do owners use to report a problem?
In practice, almost always three — phone, WhatsApp and email, often for the same report at the same time. The problem is not which channel to use, it's that they stay three separate channels with no shared status.
What does a good reporting flow need?
Four steps: the report arrives with a photo and the floor it's on, it gets classified by type and urgency, it's assigned to a supplier with a deadline, and it closes with an explicit confirmation back to the owner who reported it.
What should be measured to know if the process works?
First-response time, closing time, and reopenings — reports closed but not actually resolved, which come back open within a few days.
Is the administrator legally required to act on every report?
Depends what the owner is reporting. Art. 1130, no. 4, of the Civil Code covers preservative acts (atti conservativi) — for example urgent measures to stop damage to common parts from getting worse; art. 1130, no. 3, covers collecting contributions and paying for the ordinary maintenance of common parts and the running of common services instead. Neither sets a response deadline or a duty to act on every report.