Start with an honest evidence boundary
The map in this guide uses a representative six-unit property scenario. No property operator, tenant, vendor, building, or customer system was observed or interviewed for this article. The scenario makes the method inspectable; it is not field research or a claim about how every property team works.
Community discussions describe records and requests spread across messages, files, and spreadsheets. They help establish the question and the language operators use. They do not prove prevalence or the correct process.
The map also uses current Microsoft Field Service documentation as one reference model. Microsoft documents recurring agreements separately from work orders and describes a work-order lifecycle from creation through scheduling, dispatch, service, review, and invoice. That vocabulary is useful for finding missing handoffs. It is not a recommendation to use Microsoft or copy its configuration.
Define the operational outcome
Replace “one place for maintenance” with a result the team can inspect:
The tenant or property owner can determine what was reported, who owns the next action, whether a vendor is expected, what evidence exists, and why the work is closed or still open. Recurring work remains visible even when nobody opens a request.
That outcome can be supported by a spreadsheet, an established product, or a narrow custom layer. The map should not decide the tool in advance.
Lane one: follow a reactive request
Map one actual or representative request from report to closure.
| State | Essential record | Next owner | Exception to ask about |
|---|---|---|---|
| Reported | Location, problem, observed time, contact path | Property manager | The message lacks a unit or safe-contact detail |
| Triaged | Urgency rationale and escalation decision | Manager or emergency owner | The manager is unavailable or urgency is uncertain |
| Authorized | Scope and authority decision | Manager | Owner approval is required but absent |
| Assigned | Assignee, scope, response expectation | Vendor or staff | The first vendor declines or stays silent |
| Scheduled | Time window and access arrangement | Assignee | The tenant cannot provide access |
| Performed | Work note and permitted evidence | Manager | A temporary repair needs follow-up |
| Verified | Confirmation method and unresolved issue | Manager | The vendor says complete but the symptom remains |
| Closed | Closure actor, time, evidence, stopped reminders | Nobody or recurring owner | Invoice or warranty work remains open |
Do not compress these states into open, in progress, and done until the
team has checked which decisions disappear. The most important distinction may
be between a vendor reporting completion and the property team verifying the
outcome.
Lane two: expose the vendor handoffs
A vendor has a workflow inside the request workflow:
- identify a currently appropriate and available vendor;
- communicate the exact scope and response expectation;
- record acceptance or refusal;
- arrange authorized access;
- receive the vendor's completion account;
- verify the operational result; and
- route invoice, warranty, or follow-up work.
Keep at least four facts separate:
- vendor says the task is complete;
- tenant says the symptom is resolved;
- manager closes the operational request; and
- invoice is accepted for payment.
One may happen without the others. A useful system makes the disagreement visible instead of using a single green check.
Lane three: keep recurring work visible
Recurring work begins from an obligation, asset, or policy rather than a new tenant message. Map:
| Recurring state | Question |
|---|---|
| Defined | Which location or asset needs which task, and who owns the definition? |
| Scheduled | What cadence and allowed window apply? |
| Generated | Did the obligation create a visible occurrence of work? |
| Assigned | Who accepted this occurrence? |
| Performed | What was done, and what evidence is appropriate? |
| Reviewed | Who checked the outcome and unresolved exceptions? |
| Advanced | Is the next occurrence visible with the right owner and date? |
Microsoft's agreement guidance documents one system in which recurring agreements generate work orders. It also warns that agreement processes run with their owner's permissions and can break when that owner leaves. The general discovery question is valuable even outside that product: which automation depends on a person, account, or team that may disappear?
Connect the lanes through exceptions
Cross-lane cases reveal more than the happy path:
- a reactive repair creates a future recurring inspection;
- a recurring visit discovers a separate tenant-facing issue;
- a vendor closes its task without enough evidence for manager closure;
- access changes after the visit is scheduled;
- the automation owner leaves;
- an operational request closes while invoice or warranty follow-up remains;
- a repair exposes a safety question that must leave the ordinary workflow.
The last case is a boundary, not an invitation to improvise legal or emergency rules. Record the responsible escalation path with qualified local guidance.
Use one row per handoff
For each real example, capture:
| Field | Question |
|---|---|
| Trigger | What started this work? |
| Person | Who acted or decided? |
| Channel | Where did the handoff happen? |
| State | What did the team believe was true afterward? |
| Evidence | What proves the handoff or outcome? |
| Next owner | Who must act now? |
| Next date | When does silence become an exception? |
| Recovery | What happens if the expected action fails? |
| Closure | Who can close it, and what stops? |
This is similar to mapping a missing-document workflow: the screen is secondary to status, ownership, evidence, and exception recovery.
Make the first improvement smaller than a platform
Before replacing tools, try one shared register that separates request, vendor, and recurrence state. Give every open row one next owner, one next-action date, one evidence note or link, and one exception reason.
Walk one recent reactive request and one recurring task with the people who actually coordinate them. Mark every representative state that does not exist, every hidden handoff, and every channel the first map omitted.
Then evaluate software against observed questions:
- Can it preserve the three kinds of state without forcing them into one label?
- Can an absent manager or departed owner be replaced?
- Can a vendor response differ from operational verification?
- Can recurring work advance without losing exceptions?
- Can the team export the authoritative history?
- Which important steps still happen by text, phone, email, or accounting tool?
If a process and shared register resolve the material ambiguity, that is a valid outcome. A map is useful even when the decision is not to build or buy anything new.
Frequently asked questions
Should tenant requests and recurring work use the same statuses?
Not automatically. They may share assignee, schedule, performance, review, and closure concepts, but their triggers and exception paths differ. Preserve the distinction until real examples show that merging is safe.
Does a vendor marking work complete close the request?
Only if the team has deliberately defined it that way. Many workflows need a separate operational verification, tenant communication, invoice, warranty, or follow-up state.
Can we use this map to choose a property-management platform?
Use it to ask comparable questions and run real scenarios. Do not treat the representative map or cited product documentation as a vendor evaluation.
What should we validate first?
Walk one reactive request and one recurring task from trigger through closure. Those two examples usually expose the hidden owner, channel, and exception assumptions quickly.