Turn resident maintenance requests into dispatched work orders
Requests arrive by phone, text, email and the resident portal. The system identifies the unit, asks follow-up questions, collects photos and access windows, opens the work order and offers it to the right vendor. For property managers whose staff retype requests into the system each day.
Function: Operations · Industry: Property management
Turn resident maintenance requests into dispatched work orders
6 steps
At a glance
- Trigger
- A resident reports an issue through any channel.
- Typical inputs
- Resident messages, calls and photos
- Unit, lease and resident records
- Vendor roster with trades and service areas
- Approval limits and owner preferences
- Systems it usually connects to
- AppFolio
- Buildium
- Yardi
- Twilio
- How the work splits
4 rules, 1 model, 1 person steps
How it runs, step by step
6 steps, each tagged by what does the work. Rules are fixed logic, a model reads or drafts, and a person decides.
- Rules Fixed logic in code
- Model AI reads or drafts, with a confidence score
- Person A named person decides
- 1
Identify the resident and unit
RulesThe sender is matched to a tenancy by phone number or email, and unknown senders are asked to confirm their address.
- 2
Classify the issue
ModelA model reads the request and photos, and asks follow-up questions for the trade and urgency, such as where the leak is and whether water is spreading.
- 3
Apply your rules
RulesEntry permission, pets, preferred access windows and warranty or owner-approval rules are applied from the records.
- 4
Open the work order
RulesThe work order is created in your system with the conversation, photos and access notes attached.
- 5
Approve above the limit
PersonA property manager approves work above the spending limit or on a property that requires owner consent.
- 6
Offer and confirm the vendor
RulesThe job is sent to the first matching vendor on the rota, and the resident gets a confirmed time by text.
Where people approve
The decisions that stay with your team, whatever the confidence score says.
- The manager approves work above the property's spending limit.
- Owners approve non-routine repairs where the agreement says so.
- Vendor changes on an assigned job are made by a person.
KPIs to track
What to measure, before and after. Targets come from your own baseline.
- 01Time from request to work order created
- 02Requests resolved with no staff retyping
- 03Work orders reopened after completion
- 04Resident follow-up calls asking for status
Questions about this workflow
How does it tell an emergency from a routine request?
It uses the escalation rules you define, such as active leaks, no heat or a gas smell, and treats an unclear case as urgent. The separate after-hours triage use case covers what happens next for emergencies.
Does the resident always talk to a bot?
They talk to an assistant that says what it is. A person can take over at any point, and requests the assistant cannot place go to staff with the conversation attached.
Which steps use rules, a model and a person?
Rules: identify the resident and unit; apply your rules; open the work order; offer and confirm the vendor. Model: classify the issue. Person: approve above the limit. Rules are fixed logic in code. A model reads or drafts and reports its confidence. A named person decides.
What do we need to start?
Typically: resident messages, calls and photos; unit, lease and resident records; vendor roster with trades and service areas; approval limits and owner preferences. You also need read access to AppFolio, Buildium, Yardi and Twilio, or the equivalents you use. A workflow audit measures your volumes and past cases first, then gives a fixed price for the build, so you can decide with real numbers.
