Maintenance is one of the few areas of property management where the volume is genuinely unpredictable. A quiet month can turn into five simultaneous requests after one hard freeze. Triage — deciding what gets attention first, who handles it, and what the tenant is told — only works if every request lands in the same place and carries the same structure, every time.
Why maintenance sprawls into a spreadsheet
A single maintenance issue touches several things at once: a description of the problem, a priority level, who is responsible for fixing it, a due date, photos, and a running set of notes as work progresses. When that information lives across text messages, email, and a vendor’s own notes, someone inevitably builds a spreadsheet just to keep track of what is still open.
The spreadsheet works right up until two people update it at the same time, or a photo a tenant sent by text never makes it into the row, or a vendor closes out work in their own system without anyone updating yours. Triage breaks down not because anyone is careless, but because the information was never structured to live in one place.
Tenantivo splits maintenance into two connected pieces — tenant-submitted requests and internal maintenance tickets — and links them together so triage happens on structured records instead of a shared file.
Tenant-submitted requests: the front door
Most maintenance issues start with the tenant, not with you. From their portal, a tenant submits a maintenance request with a subject, a description, and an urgency level they choose themselves:
- Low — a minor issue with no urgency, such as a loose cabinet hinge.
- Normal — the default level for most everyday repairs.
- High — something affecting daily living that should be scheduled soon.
- Emergency — safety issues, active leaks, no heat, or anything that cannot wait.
Requests appear in your Tenants → Requests list by status and tenant, with any photos or notes the tenant attached already there — nothing to forward or copy from a separate inbox. This is the queue you triage first, before anything becomes a work order.
Turning a request into a maintenance ticket
A tenant request tells you what happened. A maintenance ticket is where you manage the work — category, assignment, vendor, due date, and the full history of what has been done. Linking a request to a ticket keeps that thread in one place: tenant request → your ticket → notes → resolution.
When you create or link a ticket from a request, you carry forward the useful context — the tenant’s description and any photos — while adding the structure your team needs to actually schedule and track the work:
- Category — plumbing, HVAC, electrical, and other trade groupings you define.
- Assignee — the team member responsible for seeing the ticket through.
- Vendor — the outside contractor or company scheduled to do the work, once one is selected.
- Due date — when the work needs to be completed, independent of the tenant’s original urgency level.
Not every internal ticket originates from a tenant — you can also create one directly for something your team noticed on a walkthrough, a preventive task, or a vendor-flagged issue that has nothing to do with a tenant complaint.
Triaging by category, priority, and assignee
Internal maintenance tickets carry their own priority scale, separate from the tenant’s original urgency choice — useful because your team’s assessment of severity does not always match how the tenant described it:
- NotSet — not yet triaged.
- Low
- Medium
- High
- Critical
Filtering the ticket list by status, priority, property, and date — alone or combined — is the actual triage workflow. A filter for “Open” tickets at Critical priority shows you exactly what needs attention today; a filter by property surfaces everything happening at one address before a walkthrough.
Notes, attachments, and what the tenant sees
A ticket’s history matters as much as its current status. As work progresses, add notes — “vendor scheduled for Tuesday,” “part on order” — and attach photos or documents like an invoice or a before-and- after picture, all stored with the ticket itself.
On the tenant request side, each note you add can be marked visible to the tenant or kept internal only. That distinction matters: a tenant benefits from knowing “scheduled for Tuesday,” but does not need to see “vendor quoted $600, negotiating down” or other internal commentary. Choosing visibility per note, rather than per ticket, means you can keep the tenant informed without exposing your team’s working notes.
Because notes and attachments live on the ticket rather than in a text thread or email, anyone who opens it later — including someone who was not involved in the original conversation — gets the full picture immediately.
Closing the loop: status, filters, and metrics
A ticket moves through Open → In progress → Closed (or Resolved) as work happens, and a linked tenant request updates alongside it so the tenant can see progress without a separate status update from you. When the work is done, close the ticket with a short closing note — useful both for your own records and if the tenant later asks what was done.
Beyond individual tickets, dashboard metrics — open count, how long tickets have been open, and breakdown by priority — give you a portfolio-wide read on maintenance health without opening every ticket one at a time. Reviewing those metrics on a regular cadence is what catches a bottleneck (a category piling up, a property with recurring issues) before it becomes an owner complaint.
See the full walkthrough for both sides of the workflow in Maintenance training and Tenant Requests training.