Practical guide
Managing owners' requests: from receipt to closure
An administrator receives requests from owners constantly: a fault report, a question about an expense, a request for a document, notice of a change of residence. When these requests arrive on scattered channels, across calls, emails, messages and verbal notes, it is almost inevitable that something gets lost or goes unanswered for weeks, fuelling discontent. Handling requests well means giving them an orderly flow: a single point of receipt, a status that follows their progress, a reasonable response time and a record of every step through to closure. This is not bureaucracy, but the way to leave no one behind and to be able to show how each request was handled.
Why requests get lost
Dispersion is the main cause of unanswered requests. A call received while out, an email that slips to the bottom of the inbox, a message read but not noted: without a single collection point, the administrator's memory becomes the only register, and memory is not enough when many condominiums are managed and requests overlap.
The second problem is the absence of status. A request received but not yet taken on, taken on but not yet resolved, resolved but not communicated to the owner: without a way to distinguish these moments, you cannot see at a glance what is missing and what is done. The result is that some requests stall not by intention, but because no one sees them anymore.
A flow with clear statuses
The remedy is to give every request an explicit lifecycle, with a few well-defined statuses anyone can read. A simple but complete flow usually goes through these steps:
- Received: the request has entered the system, with date, sender and subject.
- Taken on: the administrator has assigned the request to themselves or a collaborator and acknowledged receipt.
- In progress: the request is being handled, for example awaiting a quote or a check.
- Resolved: the requested action has been completed.
- Communicated and closed: the outcome has been communicated to the owner, who knows how their request ended.
Communicating the acknowledgement, not just the solution
Much discontent arises not from slowness itself, but from silence. An owner who reported a problem and gets no feedback imagines their request was ignored, even when the administrator is already handling it. A simple acknowledgement message, confirming receipt and giving a time horizon, radically changes perception and reduces repeated chasing.
Communicating the outcome, at closure, completes the cycle. Knowing not only that the problem was solved but also how gives the owner the sense of having been heard and closes the request cleanly. Requests left without a closure communication tend to resurface as new reports or complaints at the meeting.
Distinguishing individual requests from common matters
Not all requests have the same nature. Some concern the owner's individual position, for example a question about their own balance or personal data, and must be handled in the reserved channel, without exposing personal information. Others concern a common matter, such as a fault in a shared service, and their handling and outcome can be communicated to all interested owners.
Keeping the two levels separate also matters for privacy. A request that starts as individual, for example a dispute over an instalment, should not be taken onto a collective channel, while information of common interest should not remain confined in a private exchange with a single owner. A good management system lets you classify the request and address its communication to the correct audience.
Tracking to improve and to account for the work
An orderly archive of requests, with a record of when they arrived, how they were handled and when they were closed, serves two purposes. In the short term it lets the administrator show their diligence if an owner disputes not having received an answer. Over time, it offers a basis for understanding which problems recur most often, which services generate the most reports and where structural intervention is worthwhile.
In AmministraPro, owners' requests and reports converge into a single flow with statuses, assignments and acknowledgement and closure communications, distinguishing what is individual from what is common. The features for managing requests and communications are described at /funzioni and the plans can be compared at /prezzi.
Frequently asked questions
Why do many owners' requests go unanswered?
Almost always because of dispersion and lack of status. When requests arrive on scattered channels, across calls, emails and messages, without a single collection point the administrator's memory becomes the only register and something inevitably slips. Without a status distinguishing requests received, in progress and resolved, some stall not by intention but because no one sees them anymore.
Is resolving the request enough, or must the outcome be communicated too?
The outcome must be communicated. Much discontent arises from silence, not slowness: the owner who gets no feedback thinks they were ignored even if the administrator is already handling the problem. An acknowledgement message at the start and a closure communication at the end complete the cycle, reduce repeated chasing and give the person the sense of having been heard.
Which statuses are needed to handle a request well?
A few clear ones are enough: received, taken on, in progress, resolved, communicated and closed. Each status shows at a glance where the request stands and what is missing to complete it. An explicit lifecycle keeps requests from lingering in a grey zone where it is unclear whether anyone is dealing with them.
Can an individual request be handled on a collective channel?
No. Requests concerning the owner's individual position, for example a question about their own balance or data, must be handled in the reserved channel, without exposing personal information to others. Requests about common matters, such as a fault in a shared service, can instead be handled and communicated to all interested owners. Keeping the two levels separate also protects privacy.
What is the point of keeping a history of requests?
Two things. In the short term it lets the administrator show their diligence if an owner disputes not having received an answer, with a record of when the request arrived and how it was handled. Over time, it offers a basis for understanding which problems recur, which services generate the most reports and where to intervene structurally instead of chasing emergencies.
Try AmministraPro
Accounting, thousandths-based cost splitting, meetings, communications and artificial intelligence in a single Italian software, compliant with UNI 10801 and GDPR.