Voice agents for condominiums: maintenance requests
Identify the location and record an issue without predicting diagnosis or repair time.
- Author
- Tigy AI team
- Published
- Updated
A voice AI agent for residential property management can organize maintenance requests: identify the location, record observed issues and explain next steps. In Tigy AI, approved instructions and documents define this administrative triage. A tool connected to an external system can create or retrieve work orders when authorized. Technical diagnosis, emergency prioritization and repair timing belong to responsible staff or systems.
Define request types
Separate maintenance information, new issues and follow-up. Write scope into instructions and attach approved channel and opening-hour documents. The agent should not diagnose risk, assess installations or promise emergency service.
Collect location minimally
For a fictional lighting case, request property and shared-area identification, a short description and an approved return channel. Confirm location before recording to avoid sending staff to the wrong building. Personal or apartment details belong only when necessary.
Use the responsible system
With a configured connection, the agent can register an issue in the maintenance system. The team responsible for that system must check access and required details. Announce a case number only after registration is confirmed. Without the connection, explain the available way to request review and do not claim that a work order was opened.
Explain continuity
Use published, current property-manager timing when applicable. Accepted registration does not prove dispatch or completed repair. Priority and safety questions should follow the responsible team’s approved channel.
Test similar issues
Test ambiguous locations, repeat requests, write failure and non-administrative demands. Compare delivered staff context with the confirmed report. Review duplicates and location corrections before expanding.
Which fields make a maintenance report actionable?
Record the property, building section or shared area, equipment where known and observed description. Include authorized contact details only when needed for continuity. “Section A’s gate does not open” helps locate the issue; “burned-out motor” adds a diagnosis not established by the call.
Property managers define categories, destinations and priority criteria. The agent confirms reports and follows approved procedures without improvised repair instructions. With integration, verify the created reference; with collection only, explain remaining receipt or review according to the actual process.
Record observations without announcing a diagnosis
Maintenance calls often begin with a sign: an unlit lamp, a gate that will not open, or a perceived leak. That report alone does not establish the cause or required repair. The agent should identify location, equipment, and useful observations while distinguishing what the resident noticed from what staff verified. “The resident reports water in the corridor” is more accurate than “the pipe burst” when no inspection has confirmed a cause.
At a fictional residential building, someone says a gate does not respond. The agent may ask which entrance is involved and when the issue was noticed. If incident lookup exists, it can help identify an open record. No incident record does not prove the equipment works. Explain what was checked and record the report through the approved process without assuming the remote control or motor is responsible.
Ask about observable signs and avoid improvised technical instructions. Intake should help staff understand where to act, rather than instruct residents to dismantle equipment or perform repairs. For categories requiring specific safety or emergency procedures, use only guidance approved by the operation and an existing channel. Do not invent a protocol during the call or treat general service instructions as authorization to give equipment-specific advice.
Define fields distinguishing similar incidents: building section, shared area, equipment, and approximate time where needed. Do not ask everyone for a complete address if context already identifies the property. Lean, accurate intake is more useful than a lengthy narrative filled with unverified hypotheses. Confirm the elements used to locate the issue before recording the request. Staff should be able to recognize both the physical location and the nature of the reported observation without assuming a technical finding has already been made.
Use approved criteria for priority and routing
The intensity of a complaint should not be the only priority criterion. A resident may speak urgently about an issue handled through scheduling; another may calmly describe a situation requiring a specific channel. Define categories and alternatives with the property-management team. The agent should acknowledge the report and apply approved guidance without performing technical assessment beyond its assigned role.
In a fictional example, an unlit lamp in a circulation area and a failure in access equipment may follow different routes. Instructions should explain which information determines the category. When a case does not match available categories, record the uncertainty and use the defined alternative. Asking one short question or routing for triage is preferable to inventing a priority merely to complete the call.
Separate routing from confirmed attendance. A tool may create a request for management, but that does not prove a technician is on the way. Provide returned reference and state. Mention a deadline only when approved and applicable. A prediction from an older record should not become a promise for a new incident, even when the reported problems sound similar. Residents need to know whether they have created a request, joined an existing incident, or received a verified update.
Test incomplete descriptions, corrected locations, several problems in one call, and callers demanding higher priority. The integration should validate fields and destination; the conversation should explain the outcome clearly. Where approved urgent guidance applies, make it available without requiring a long collection sequence first. The operation should decide that behavior beforehand and verify it through specific tests. Accurate routing matters more than sounding decisive about a category the available evidence cannot support.
Relate new reports to already open incidents
When shared-area equipment fails, several residents may call about the same issue. Creating an independent repair request for every report can duplicate work and make state tracking harder. If the integration supports lookup, check corresponding incidents before opening another record. Matching should consider location and problem type, rather than merely a similar word in the description.
The gates for sections A and B may have different faults. Confirm which equipment the caller means before linking a report. If a known incident covers the correct equipment, the agent may explain authorized state and add an observation when that operation exists. Do not dismiss a report as duplication if the resident describes an additional effect staff should know about. A related report can contain useful new evidence even when the underlying incident is already recorded.
Agree with the team on how to handle a registration that takes time to confirm. The agent should explain that it is waiting, without opening another request because the resident insisted. Ask the integration owner to check that the system avoids duplicate issues when it receives the same request again. An instruction to be careful does not replace this control.
Test existing incidents, different equipment with similar names, unavailable API results, and new information about open records. Distinguish “an incident is recorded” from “the problem is resolved.” If a tool reports completion, do not assume the current report is invalid: the resident may be describing recurrence. Record the checked state separately from the new report so management can investigate. This distinction prevents an old resolution from silencing a legitimate report of a problem happening again.
Prepare a record the service provider can use
The next professional needs to know where the issue is and what was observed without reading a complete transcript to find those points. Define a summary containing location, category, confirmed report, checked information, and recorded action. Do not present agent hypotheses as diagnosis. If a provider needs contact details for access, collect them through the approved procedure and explain why they are required.
For fictional maintenance in a shared area, a resident should not receive a promise of an apartment visit when only external equipment is involved. Access arrangements and responsibility should come from the property's procedure. The agent may record reported availability but should not confirm a visit window without a tool or source authorizing it. A preference and an appointment are different kinds of information, and both should be represented accurately in the record.
If calls are transferred, test the destination and what happens when nobody answers. In Tigy, a direct transfer does not automatically send the history. If the administration needs that information, configure a separate delivery. Check that the answering person can actually open the record, not only that the connection reported success.
Plan continuity outside operating hours. Depending on approved arrangements, there may be another channel, specific guidance, or only a record for later handling. Wording should match that capability. “The team was notified” requires evidence of notification; “the request was recorded” describes a record. Accurate closing reduces follow-up calls caused by incorrect expectations and prevents announcements of provider mobilization that has not occurred. Check this distinction in both ordinary-hours and after-hours test cases.
Measure triage quality through maintenance continuity
The agent does not repair equipment simply by answering a call. Its contribution can be measured through record quality, correct routing, and clarity for the resident. Repair completion belongs to the responsible system and team. Separating these stages allows service evaluation without announcing unverified technical resolution or holding the agent responsible for work beyond its scope.
Review a sample covering different incident types, similar locations, repeated reports, and unavailable lookups. Check whether staff had to ask again where the issue was, whether categories required correction, and whether records created inappropriate expectations about attendance or timing. For write operations, compare the conversation against the incident actually created. For lookups, compare speech with returned state. This links the review to evidence rather than the persuasiveness of the final explanation.
Track duplication, incorrect routing, incomplete reports, and repeat contacts caused by missing information. Separate categories because administrative maintenance questions, usage guidance, and equipment faults have different needs. Lower average call duration can be harmful when it results from insufficient collection. Interpret measures alongside examples and feedback from management and service providers. Their perspective reveals whether the record genuinely prepares the next action.
Keep sources current when hours, contacts, or service rules change. Review tool descriptions when incident states change in the system. After relevant changes, repeat affected scenarios, including failures and resident corrections. A useful agent organizes reports and supports continuity with clear limits around diagnosis, deadlines, and repair. This accuracy supports a more predictable operation and prevents a convincing conversation from being mistaken for completed maintenance. Retain recurring failure scenarios so a later content update does not quietly reintroduce the same routing or confirmation problem.
