A practical first version for Canadian property managers, connecting resident intake, triage, vendor dispatch, access, exception ownership, repair evidence, and verified closure.
A maintenance request is not finished when a vendor says "done." For a Canadian property management company, the job is closed only when someone has triaged it, accepted ownership, confirmed access, documented the repair, and sent the resident a final update. A property maintenance request workflow should make that sequence visible without forcing staff to chase email, voicemail, portal messages, and contractor texts.
This article lays out a practical first version for residential property managers. It connects resident intake, building staff, outside vendors, and management review. It also deals with the requests that do not follow the happy path: unclear emergencies, missing access permission, silent vendors, changed scope, and repeat complaints.
Automating messages before fixing the record underneath them usually makes the mess move faster. A portal creates a ticket, a coordinator texts a vendor, the resident replies by email, and the superintendent sends completion photos in a separate chat. Everyone did some work. Nobody can see the whole job.
PASMO’s view is that one request needs one durable ID from first report to verified closure. Every update should attach to that record: resident and unit, issue description, photos, priority and rationale, access status, assigned owner, appointment, vendor acceptance, work notes, completion evidence, resident update, and reopen reason. The workflow can use several tools, but the team must know which system holds the authoritative status.
That record is more than administration. It prevents a coordinator from dispatching the same issue twice, lets an on-call manager see what has already been tried, and makes repeat faults visible. A current CMHC property-management services specification requires detailed documentation for work orders and the nature of the work. Smaller operators can borrow the same discipline without copying an enterprise process.
Start with five operational stages. Each stage has one owner and one exit condition. If the system cannot prove the exit condition, the request stays open.
Stage | Minimum record | Owner | Exit condition |
|---|---|---|---|
Intake | Unit, issue, contact method, photos when useful, access permission, received time | Resident service or coordinator | Enough evidence exists to triage |
Triage | Priority, reason, required trade, next action | Coordinator or superintendent | A named person owns the next step |
Dispatch | Assignee, acceptance time, appointment window, access instructions | Dispatcher or property manager | Staff member or vendor accepts the job |
Work | Arrival, diagnosis, action taken, before/after evidence, unresolved condition | Site staff or vendor | Evidence is submitted or escalation is requested |
Verify and close | Manager review, resident update, reopen reason, completion time | Coordinator | The result is verified or the request is reopened |
Build this operator artifact before adding AI. The first version is intentionally modest: structured fields, timers, clear ownership, and a visible exception queue. An autonomous agent should not decide whether a leak is safe. A custom app does not need to replace the property-management platform either.
Residents describe impact, not operational priority. "Urgent" might mean an inconvenience that has lasted a week, while a short message about water near an electrical panel may need immediate human review. Let the intake form collect observable facts: what changed, where it is, whether water, heat, electricity, security, or access is affected, when it started, whether it is spreading, and whether a photo or video is available.
Rules can route obvious routine work, but uncertain high-impact reports should page a person. The system may recommend a category; the on-call manager owns the decision. Store both the priority and its reason so the next person does not have to reverse-engineer a coloured label.
Canadian portfolios also need local operating context inside the workflow. A frozen-entry mechanism in Winnipeg, a failed cooling unit during a heat event in Toronto, and a routine interior repair do not share one response playbook. Configure service regions, on-call schedules, approved trades, and seasonal escalation paths by property. Do not bury those differences in a staff member’s memory.
Most maintenance software looks tidy when every handoff succeeds. The design test is what happens when it does not. Your exception map should answer these cases before launch:
When a request may be an emergency, notify the on-call manager with the original evidence and require an acknowledged decision.
If access is not confirmed, hold the appointment, request available windows, and keep the request with the coordinator.
If a vendor does not accept, escalate after a defined interval to an alternate without creating a second ticket.
When site conditions change, pause the job and send the new diagnosis and evidence to the property manager for review.
If the same issue returns, link the prior work order, reopen when appropriate, and preserve the earlier diagnosis.
If the resident cannot be reached, record contact attempts and let a manager decide whether to reschedule, inspect, or close.
Notifications should follow ownership. The resident does not need every internal note, but they should receive clear acknowledgements, appointment changes, delay notices, and closure messages. Vendors need the current scope and access instructions, not the entire resident conversation. Managers need the exception queue, not copies of every successful update.
Pilot one property or one maintenance category for two weeks. Run new requests through the workflow while keeping the old channel available as a safety net. Each day, review requests that have no owner, exceeded a timer, changed priority, reopened, or were marked complete without evidence. Those failures tell you which fields, rules, and responsibilities need work.
Measure the transitions, not only average completion time. Track time from intake to triage, triage to acceptance, acceptance to appointment, work to evidence, and evidence to closure. Add the share of requests reopened within a set review window and the number waiting without a named next owner. A fast average can hide a small group of residents whose requests have stopped moving.
Only after the team can run this first version consistently should you automate classification, draft resident updates, or suggest vendors. Keep human approval on uncertain emergencies, access decisions, and changed conditions. The goal is not to remove the property manager. It is to make their judgement visible at the points where it matters.
PASMO designs maintenance workflows around the property platform, contractor network, and on-call structure already in place. The useful starting point is an audit of live requests and stalled handoffs, not a software shopping list.