What is a reasonable maintenance response time?
A tenant reports a leak. The system sends an email saying the request has been received. If nobody is assigned and nobody knows when the next update is coming, that email has bought you very little.
There is no single response time that covers every property, repair and jurisdiction. A useful policy separates receipt, human review, assignment, tenant updates and repair completion. It puts an owner and a deadline on each stage. Emergencies go through the property's emergency procedure and to a responsible person immediately.
I'd build the workflow around those separate clocks. Otherwise a dashboard can show a fast response while the tenant is still waiting for somebody to do something.
A reply and a repair run on different clocks
The acknowledgement clock starts when the request arrives. It ends when the tenant receives a useful confirmation. Repeat the reported issue, include a request reference and explain the next step. Make it clear when a message was generated automatically.
The assignment clock ends when a named person accepts responsibility for the next action. An unclaimed ticket with a green status is still an unclaimed ticket.
The update clock measures whether the tenant heard from you when promised. A parts delay can change the repair date. The next update still needs an owner. If the timing changes, explain what changed and give the next checkpoint.
The repair clock ends after the work has been confirmed complete through the property's process. An acknowledgement, a vendor notification or an AI summary cannot establish that the repair happened.
Why a number from another property can mislead you
Published deadlines belong to a specific rule and situation. The California Department of Real Estate's tenant guide discusses 30 days as usually reasonable in its repair-and-deduct section, with shorter periods depending on the circumstances. That passage concerns repair timing within a particular legal remedy. It does not set a universal customer-service reply target.
HUD's NSPIRE definitions describe 24-hour correction requirements for life-threatening and severe deficiencies in the inspection regime. Those requirements have a defined program scope. They cannot be copied into every private property's maintenance policy.
Have the responsible manager check the property's applicable rules, lease and emergency plan before approving the targets. Record the source and review date beside each target. An automation should follow that approved policy, including any stricter requirements that apply.
Turn the policy into a queue somebody owns
For each request, capture the property and unit, time received, the tenant's original description, contact details, photos and any access information. Keep the original message attached. A summary can omit the detail that changes the urgency.
Then record the reviewed priority, assigned person, next action and promised update time. Keep the reported issue separate from the manager's assessment. Track uncertainty explicitly instead of quietly treating missing information as a routine repair.
For example, a routine request waiting on a vendor should show who is contacting the vendor and when the tenant gets another update. Use that as a workflow example, then set the actual timing from the approved property policy.
Where AI helps, and where a person takes over
AI can clean up intake, suggest a summary, flag possible safety language, prepare an acknowledgement and show overdue checkpoints. Those are useful jobs. They reduce the time spent searching an inbox for the same request.
A person confirms priority and approves safety decisions, access instructions, dispatch, spending and any deadline commitment. An uncertain classification should arrive with the original message and a reason for escalation. The system should never quietly downgrade a request because a photo is missing or a tenant used unfamiliar wording.
Keep emergency contact instructions visible in the intake channel. Urgent safety reports need the property's established human escalation path, including after-hours coverage. They should never depend on somebody eventually reading a batch of AI drafts.
Test the handoff before adding more properties
Start with one channel and one property. Run the system alongside the existing process while a manager reviews every proposed classification and message.
Check whether it creates duplicate tickets, loses attachments, misses after-hours requests or marks an acknowledgement as completion. Test what happens when the assigned person is away and when a vendor never replies. A reminder with nobody to receive it is a decorative alarm.
Review missed updates separately from unfinished repairs. One tells you about communication. The other tells you about completion. Mixing the two makes both harder to fix.
The larger workflow is covered in my property-management automation guide. This piece is the smaller part I'd get right first: the clocks and the handoff.
Every open request should have a name attached to it. And a next update that actually arrives.
Bring one annoying workflow.
Bring the task that keeps eating your time. In 30 minutes we'll map what the system would watch, what it would draft, what it would report, and where it stops for your OK. If it isn't worth automating, I'll tell you. The AI does the prep. You keep the keys.
Book Free 30-Minute Workflow Audit →