Ticket workflow
Maintenance tickets move through four statuses. There's no branching workflow with waiting-for-parts or waiting-for-access states — status changes are a single click, not a form.
Ticket statuses
stateDiagram-v2
[*] --> Open: Ticket Created
Open --> InProgress: Work Started
InProgress --> Resolved: Work Completed
Resolved --> Closed
[*]
Open
- Newly created ticket
- Not yet addressed
In Progress
- Work has begun
Resolved
- Issue has been fixed
Closed
- Ticket fully closed out
There's no "Waiting for Parts," "Waiting for Access," or "Cancelled" status — if you need to note a delay reason, use the ticket's email thread (see Creating tickets) rather than a status.
Updating ticket status
- Go to Maintenance, find and open the ticket
- Click the status button for the next status (e.g., Mark In Progress, Mark Resolved)
There's no separate "resolution details" form — marking a ticket Resolved doesn't prompt for a resolution date, notes, cost, or contractor. If you want that information on record, put it in the ticket's email thread or attach it as a receipt/invoice.
Response time tracking
There's no per-ticket response-time metric (time to first response, time to resolution, time in each status) shown anywhere in the UI. A property-level maintenance score, derived from open/high-priority ticket counts, is computed nightly on the backend, but it isn't currently surfaced on any page either — see Health scores.
Best practices
- Update promptly - Change status as soon as action is taken
- Use the email thread - Document delays, scheduling, and communications there
- Attach evidence - Photos, receipts, invoices as message attachments