Software choice
Support response times: what to ask the vendor
When the support of condominium software states a response time, it is essential to understand what it refers to. The time to first response is different from the resolution time, that is, from when the problem is actually closed. A vendor can reply within minutes and then take days to resolve, or set different priorities based on urgency or the plan subscribed to. For a manager working to fixed deadlines, such as notices of meeting or closing the annual statement, this distinction makes the difference. This guide explains how to read the stated times, which questions to ask during selection, and how to verify them concretely during the trial period.
Questions on response times to ask before choosing
- Does the stated time refer to the first response or to full resolution of the problem?
- Are there different priorities for urgent requests and ordinary ones?
- Do the times change based on the subscription plan or the number of condominiums managed?
- During which hours and days are the stated times valid, including holidays and evenings?
- What happens if a problem stays open beyond the expected time: is there an escalation path?
- For synchronous channels, is an average wait time before reaching an operator indicated?
- Are the times documented in writing in the contract or do they remain a generic promise?
First response and resolution: two different measures
The first mistake to avoid is confusing the speed of the first reply with the actual solution of the problem. Support that confirms receipt of a request within minutes is reassuring, but if it then takes days to resolve, the practical benefit for the manager is limited. Conversely, a vendor that states realistic resolution times and meets them is more reliable than one promising immediate replies without indicating when the problem will really be closed.
When a vendor communicates a response time it is therefore worth asking explicitly whether it refers to first response or resolution, and for which types of request it applies. A configuration query and a blocking fault do not have the same profile, and serious support distinguishes between the two.
Priorities and urgency: not all requests are equal
A good support system classifies requests by urgency. A problem that prevents generating minutes during a meeting in progress must have higher priority than a question on how to customise a letter template. Checking whether the vendor provides priority levels, and how it assigns them, helps you understand whether it will react at the genuinely critical moments.
Some vendors offer priority lanes to higher plans or to firms managing many condominiums. This is legitimate, but must be known in advance: if fast times apply only to the most expensive plan, the manager must weigh this against the overall price and not only against the software's features.
Hours, days and the seasonality of condominium management
Response times only make sense within a defined time window. Support that promises fast replies but is active only during office hours does not cover evening or weekend meetings, which in condominium practice are the norm. It is worth asking during which hours the stated times are valid and how requests received outside those hours are handled.
Seasonality should also be considered: condominium management has predictable peaks, such as the months when statement-approval meetings are concentrated. A vendor that sizes its support with these peaks in mind maintains its times even when the volume of requests rises, whereas one that ignores them risks slowing down precisely when the manager most needs fast answers.
How to verify the times during the trial
Stated times should be put to the test. During the free period it is worth opening real requests on different channels and at different times of day, noting how long passes to the first response and to resolution. It is a simple test that reveals more than any sales promise, because it shows the actual behaviour of support under ordinary conditions.
Another element to observe is what happens when a problem is not resolved at first contact: the existence of an escalation path, forwarding the case to a higher level of competence, is a sign of a mature organisation. AmministraPro publishes on its /funzioni and /prezzi pages the detail of the plans and what each includes on the support side, so that support conditions can be compared together with cost before signing up.
Frequently asked questions
What is the difference between first-response time and resolution time?
First-response time is how long passes from the request to support's first reply, while resolution time is how long it takes to actually close the problem. A vendor can reply within minutes and then take days to resolve. Before choosing software it is worth asking explicitly which of the two the stated time refers to, because for a manager working to deadlines what matters most is when the problem will really be solved.
Is it normal for response times to depend on the subscription plan?
Yes, it is a widespread practice: many vendors reserve priority lanes or faster times for higher plans or for firms managing more condominiums. This is not a problem in itself, but it must be known in advance. If the speed a firm needs is available only in the most expensive plan, the cost of support should be weighed together with the overall price list and not separately from the software choice.
Why do coverage hours matter as much as the stated times?
Because a fast response time only applies within the window in which support is active. Condominium meetings are often held in the evening or at weekends, when many support services are closed. A vendor that promises short times but operates only during office hours does not cover the most delicate moments. It is essential to ask during which hours the times apply and how out-of-hours requests are handled.
How can I verify response times before subscribing?
The most concrete way is to test them during the free period, opening real requests on different channels and at different times of day and noting the actual first-response and resolution times. Also observe what happens when a problem does not close at first contact: an escalation path to a higher level of competence is a sign of well-organised rather than improvised support.
Should response times be written into the contract?
Where possible, yes, because a time documented in writing is more reliable than a generic promise. Not all vendors formalise service parameters in the contract, but the mere willingness to put support conditions in writing is already a sign of transparency. In the absence of written commitments, practical verification during the trial remains the most useful tool for understanding how support really behaves.
Try AmministraPro
Accounting, thousandths-based cost splitting, meetings, communications and artificial intelligence in a single Italian software, compliant with UNI 10801 and GDPR.