It's one thing to agree that maintenance shouldn't live in text messages. It's another to decide what a request should actually contain. A request that just says 'sink broken' isn't much better than a 9pm text, because you still have to call the tenant back to learn anything useful.
The fields you capture up front decide how fast you can triage and how clearly you can answer 'what happened with that?' six weeks later. Here is what each request should hold and why it earns its place.
A title and a description that say something
The title is what you scan in a list of open work, so it should be specific: 'Kitchen faucet dripping, Apt 3' beats 'plumbing'. The description is where the tenant explains what's happening, when it started, and whether it's getting worse.
Together they let you decide what to do before you've spoken to anyone. A good description is the difference between dispatching a plumber and playing twenty questions over the phone.
Photos, captured at the source
A photo turns 'there's a stain on the ceiling' into something you can act on. You can often tell an active leak from old water damage, or a loose handle from a broken one, without a site visit.
The key is that the tenant attaches the photo when they file, not when you remember to ask. Photos taken at the moment of the report also become a record of the condition, which matters if there's ever a dispute about damage or timing.
Priority, so the list sorts itself
Not everything is an emergency, and not everything can wait. A priority field lets a no-heat-in-January request rise above a squeaky cabinet door, instead of both sitting in the same undifferentiated pile.
Let tenants set an initial priority when they file, and reserve the right to adjust it. They know how much it's bothering them; you know what's a genuine risk to the property or to safety.
A status that follows the work
Status is what makes a request trackable instead of just a note. A simple lifecycle covers almost everything:
- Open: reported, not yet started. This is your triage queue.
- In progress: you've acknowledged it and work is underway or scheduled.
- Resolved: the fix is done, pending the tenant confirming it actually worked.
- Closed: confirmed done and filed away, out of the active list.
The gap between resolved and closed matters more than it looks. 'Resolved' is your claim that it's fixed; 'closed' is the confirmation. Keeping them separate is how you avoid marking a job done that's quietly still broken.
Who reported it
Knowing which tenant and which unit a request came from sounds obvious, but it's what lets you reach the right person, schedule access, and follow up. It also tells you when one unit is generating an unusual number of requests, which is sometimes a clue about the unit and sometimes about the tenant.
A timeline of changes
The most underrated field is the one you don't fill in by hand: a running log of what changed and when. Every status change, comment, and photo added should land on a timeline with a timestamp and a name attached.
That history is your accountability. When a tenant says 'I reported this two weeks ago,' you can see exactly when it came in, when you acted, and what was said in between. It protects both sides, and it means nothing depends on anyone's memory.
How Unitly helps
In Unitly, a maintenance request captures all of this by default: a title and description, photos and priority from the tenant, a status you move through open, in progress, resolved, and closed, and a timeline that records every change with who made it. Both you and the tenant see the same history, so triage and follow-up don't depend on a phone call.
It's part of every plan, including the free tier for up to five active units, so you can set up your first few requests and see what a complete record looks like before you commit to anything.