A practical guide / Fonix.AI
Property management: a practical implementation guide
A worked scenario, illustrated decision review and a practical pilot worksheet.
Property management calls start with a unit and a responsibility
An AI answering service for property management should turn a tenant's report into the correct work order, with enough context for a property manager or contractor to act. The difficult part is ownership: the same symptom may fall to the tenant, building maintenance, landlord or an external utility.
Evaluate Fonix.AI against a defined portfolio and maintenance policy. Confirm access to your unit register and work-order system. This guide addresses occupied-property service requests; buyer enquiries and site visits belong in the real-estate calling guide.
Resolve the building before discussing the repair
Ask for the property and unit reference, then follow the approved caller-verification procedure before revealing tenancy information. A telephone number can represent a household, broker or former tenant. Preserve the caller's relationship to the unit rather than assuming ownership.
Capture the reported symptom, when it began, affected location, current access arrangements and any existing work-order reference. A report of water on the floor is an observation; the agent should not label it a burst pipe or approve a contractor's diagnosis. Restrict troubleshooting to instructions the property team has reviewed.
Worked example: water appears in two apartments
In a fictional building, a resident reports water below a bathroom ceiling. Another unit has already reported a related issue, and maintenance has an open incident for the common pipe riser. Creating two unrelated contractor jobs risks duplicated visits and conflicting access arrangements.
The agent should check the open incident, associate the new report with it and record which apartment needs inspection. If the caller mentions an immediate hazard, use the building's approved urgent route. Do not delay that route while trying to complete every intake field.
| Decision | Source to consult | Useful next state |
|---|---|---|
| Is this the correct unit? | Unit register and caller verification | Unit resolved or private handoff |
| Is a matching incident open? | Current maintenance records | Linked report or new work order |
| Who owns the repair? | Responsibility matrix | Named team or contractor queue |
| Can the contractor enter? | Current access permission | Agreed window or access pending |
A contractor assignment needs acceptance
Keep reported, triaged, assigned, accepted and completed as separate states. Dispatching a notification does not prove that a contractor saw it or can attend. A resident should hear the actual state and the next contact route, not an invented arrival time.
For access-sensitive work, record the approved window and contact method without exposing private tenancy notes to the whole contractor list. If the resident withdraws access or the incident closes before the callback, cancel the obsolete task. After a repair, record resident feedback separately from the contractor's completion entry; disagreement should reopen review, not silently overwrite either account.
Portfolio checks for linked incidents and access
Provide a fictional unit register, maintenance responsibility matrix and current work-order examples. Define approved access handling and an urgent-report route. A property manager should own ambiguous common-area and landlord-versus-tenant decisions.
| Pilot case | Required behaviour |
|---|---|
| Two apartments report the same riser incident | Link both reports to the incident while preserving each unit's access and symptoms. |
| A contractor receives a job but never accepts | Keep attendance unconfirmed and assign an operational follow-up owner. |
| A former tenant calls from a recognised number | Apply relationship and verification rules before disclosing current tenancy information. |
Measure correctly linked, accepted maintenance handoffs and the manager's clarification workload. Count duplicate contractor jobs and unsupported arrival promises separately. Compare incident-level outcomes so a multi-unit fault does not inflate apparent successful resolutions.
Should every repeat call create a new work order?
Only if the maintenance policy calls for a distinct job. Otherwise add the new observation to the existing incident or work order, retain the caller's unit context and name the next owner. A resident's disagreement with completion should trigger review rather than silently disappear.
Test the portfolio's difficult boundaries
Include a former tenant, a common-area fault, an existing work order and an unreachable contractor. Check correct ownership, duplicate-job prevention and access accuracy. Measure accepted maintenance handoffs and reports requiring manual clarification. A ticket count alone rewards duplicate intake.
Bring your responsibility matrix and sanitised unit/work-order examples to review property-management call handling. Use after-hours routing for duty schedules and caller verification for information boundaries.