The maintenance model
Requests come in, projects organise the work, visits are the trips people make.
Maintenance has three layers, and they answer three different questions.
| Layer | Answers |
|---|---|
| Request | What did someone report? |
| Project | What are we actually doing about it? |
| Visit | Who is going, where, and when? |
Keeping them separate is what lets one trip fix five reported problems, and one reported problem take four trips, without either becoming a mess.
Requests are the inbox
A request is a report — usually from a resident, sometimes raised by staff. It carries the description, the photos and the unit it concerns.
A request is not a plan. It is the raw signal you group from. Requests stay readable as their own list precisely so nothing gets lost between being reported and being scheduled.
Projects are the work
A project is the unit of actual work, numbered PRJ-####. It gathers the
requests it addresses, the tasks it breaks down into, the purchases it needs, the
work logged against it and its files.
Project numbers have gaps, and that is expected. Older gaps came from rolled-back transactions burning a number. It is not evidence of a deleted project.
A project has a status — open, in progress, on hold, completed, closed — a priority, and a manager: the office staff member overseeing it. The manager is not the person who physically goes; that is the visit's assigned staff.
Grouping requests into a project
When you group requests, two warnings can appear, and both are about money and attribution rather than tidiness:
- Requests spanning different buildings produce a project with no building.
- A project with no building means grouped purchases book to the overall P&L rather than to a building.
The consensus rules that infer a project's building, unit and priority from the requests you are grouping apply only when creating a NEW project. Grouping into an existing project leaves that project's own building, unit and priority alone, and issues no warning. If you expected a project to inherit a building and it did not, check which of the two you did.
Visits are the trips
A visit is one person going to one place on one date, bundling the tasks to be done there. It has a scheduled time window, a status — scheduled, in progress, completed, cancelled — and may require approval.
Because a visit bundles tasks, the link between work and a trip lives on the project's tasks, not on the request. Claiming, reassigning or detaching work from a visit is done against a project task.
Filters for "needs a visit" exclude work already in progress — it is being dealt with. Reading such a filter as "everything outstanding" undercounts, and the gap is exactly the work someone is currently doing.
Contractor share links
A project can be shared with an outside contractor through a link. This is the part to be careful with.
The share page is project-scoped and writable. A contractor holding the link can see the project's requests, tasks, purchases, work logs, files and history, and can act: log hours, create a purchase, move a task between pending, in progress and completed, and tick steps.
A share link is a building credential, not a job credential. It exposes the building handbook — entrance codes and WiFi included — alongside the work. Send it only to a contractor you would give those details to on the phone, and revoke it when the job is done. Links expire, but expiry is a backstop, not the control.
Purchases a contractor creates on the share page book to the project's building, and therefore to that building's P&L — which is the other reason a building-less project deserves a second look before you share it.
See also the Maintenance chapter for the screens themselves.