Facility Maintenance Request System
A managed building or estate where tenants report faults by calling or messaging the facility officer, who assigns a contractor by phone, and where the only record is the officer's memory.
The problem
Requests are lost, tenants chase, contractors are paid without a recorded approval, and the manager cannot say what maintenance costs per unit or which contractor is reliable.
In scope
- Request intake
- Triage and priority
- Assignment
- Quote and approval threshold
- Cost recording
- Resolution and tenant confirmation
- Vendor performance
- Recurring-fault analysis
Out of scope
- Rent
- Tenancies
- Service charge accounting
- Owner statements
- Also out: a tenant app — a link and a message reach tenants who will never install anything.
What this would cover
Grouped by module — open the ones you want to read.
Intake
- Tenant submits by link or message, with a photograph and location; office can also raise on their behalf, because many tenants will still call
Triage
- Category and priority, with an emergency path that bypasses the normal queue and notifies a named person immediately
Assignment
- Internal staff or external vendor, with the vendor's trade and availability visible
Quote and approval
- Jobs above a configurable threshold require a recorded approval before work proceeds, which is the control that protects the manager
Cost
- Recorded against the job, the unit and the property, feeding maintenance cost per unit
Status and communication
- Tenant sees progress without calling; automated updates at assignment, at scheduling and at completion
Completion
- Vendor marks complete, tenant confirms, and unconfirmed completions surface as a worklist rather than being assumed
Vendor performance
- Response time, completion time, cost against quote, and rework rate, which is the number that identifies the cheap contractor who is not cheap
Recurring faults
- The same fault in the same unit or the same system, surfaced, because repeated small repairs are usually a deferred large one
Data model
- MaintenanceRequest → Triage → Job
- Unit → Property
- Vendor → Trade
- Quote → Approval
- Cost
- StatusEvent
- TenantConfirmation
Invariants
- A job above the threshold cannot proceed without a recorded approval.
- Status events are append-only.
- A job is not closed by the vendor alone — closure requires tenant confirmation or an explicit override with a reason.
- Cost is always attributed to a unit, never only to a property, or per-unit analysis becomes impossible.
Offline behavior
Vendor and officer updates should work offline on site, queued.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
Requiring tenant confirmation before closure is correct and will create a backlog of jobs that are genuinely done.
Tenants do not respond. The system needs an ageing override — unconfirmed after a set period, closed with that status recorded — or the worklist becomes noise that staff learn to ignore. Which period, and who may override, is a Phase 2 decision.
Vendor adoption is the weak point.
A contractor who is not an employee will not learn a system for one client. The design must let the office update on the vendor's behalf without losing attribution — otherwise the record quietly becomes fiction.
End state
What would be true about their day once this is running.
- A fault is a record with a photograph, a priority and an owner from the moment it is reported.
- Work above the threshold has a recorded approval before it starts.
- Tenants see progress without calling.
- Cost is attributed per unit, so maintenance spend is known.
- Vendors are compared on response, cost against quote and rework rather than on impression.
This is a deliberate first step toward Property and Tenancy Management Platform — its data model is designed as a genuine subset, so growing into it later doesn't mean starting over.
Let's map how your operation actually runs.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Start the operations review