How to Manage Maintenance Requests So None Slip Through the Cracks

Ask a property manager to describe their maintenance process and you will hear a clean workflow: log the request, assign a vendor, track the job, close the loop. It is the right workflow, and most guides walk you through those four steps in detail. But there is a step those guides skip, the one before "log the request," and it is where the most expensive failures start. A tenant with a leaking pipe calls at 9 PM. No one answers. The request never gets logged, so the four-step workflow never begins. You cannot track a ticket that was never created.

This is the part of managing maintenance requests that the tracking-software guides gloss over: a workflow can only manage the requests it captures, and a surprising number of requests, especially the urgent ones, never make it in. This article covers the full picture, starting one step earlier than most: how requests actually reach you, why the phone is where capture breaks, and how to make sure every request becomes a ticket your workflow can handle.

The workflow everyone teaches, and the step it assumes

The standard maintenance workflow is genuinely good, and worth stating plainly because the rest of this article builds on it.

• Log the request in one place so nothing is lost and every issue has an owner.
• Assign a vendor with clear instructions and a due date, and confirm the appointment.
• Track progress transparently so tenants can see status and stop calling to ask.
• Confirm and close by verifying the fix, recording costs, and documenting the job.

Run that loop consistently and maintenance stops being chaos. The problem is that every step in it assumes the request has already been captured. Logging, assigning, tracking, and closing all begin after the tenant's issue is sitting in your system. So the real question, the one that decides whether the workflow ever runs, is how the request gets into the system in the first place.

Requests arrive in more ways than your system captures

Tenants report problems however is easiest in the moment, and that is rarely the neat portal form you would prefer. A resident who submits an online request during business hours flows straight into your workflow. But the tenant whose heat fails at 11 PM does not open a portal; they call. So does the tenant panicking about water spreading across the floor. The urgent, high-stakes requests, the ones where a slow response does the most damage, are exactly the ones most likely to come by phone.

And the phone is where capture quietly fails. If the office is closed, the call goes to voicemail, and a panicked tenant often will not leave one; they keep calling or stop trying and stew. If the office is open but busy, the call competes with everything else the front desk is doing. Either way, the most urgent request is the one least likely to become a logged ticket. Your workflow never sees it, yet the tenant experienced exactly that: a problem in their home that nobody responded to.

This is the capture gap, and no tracking system or tenant portal closes it, because they all begin after capture. Closing it takes something that answers the call.

Image 1

Sort the request before it becomes a work order

Capturing the request is step one. Sorting it correctly is step two, and it matters because not every maintenance call deserves the same response. A good intake process triages before it dispatches.

The triage step is where phone intake either helps or hurts. A rushed human taking a 9 PM call might log a burst pipe as a routine ticket and cost you a flooded unit; a caller who cannot reach anyone gets no triage at all. The goal is to classify every request the moment it arrives, so the emergency gets escalated and the dripping faucet gets scheduled, without an exhausted staffer making that call at midnight.

Your maintenance workflow starts one step earlier than you think

Put the pieces together and the familiar four-step workflow is really a five-step one, with a step zero that every guide leaves out.

Image 2

Step zero is capture: the request has to be answered and turned into a ticket before any other step can run. It is invisible on a workflow diagram because it feels automatic, of course the request gets captured, until you count how many phone calls at how many inconvenient hours never do. The property managers with the fewest maintenance disasters are not the ones with the best tracking software. They are the ones who never lose the request in the first place.

How an AI voice agent closes the capture gap

The workflow guides are right that you need a system to log, assign, track, and close. What they miss is that you need something to reliably capture the request before that system has anything to work with, and for phone requests, especially after hours, that is exactly what an AI voice agent does.

An AI voice agent answers every maintenance call live, at any hour, so the 11 PM no-heat call becomes a logged, triaged ticket instead of an unanswered ring. It gathers what a work order needs, the unit, the issue, access instructions, classifies the urgency so an emergency is escalated and a routine repair is queued, and passes the request straight into the workflow the guides describe. AI voice agents like Pesta are built for exactly this in mid-market and multifamily operations, feeding your tracking system instead of replacing it. Powered by Deepdub, it handles callers in a wide range of languages, which a diverse resident base needs more than most software admits.

Two capabilities matter on a maintenance call specifically. First, handling the request that does not fit a script: a resident rarely describes a problem in clean categories, they say "there's water coming from under the sink and now the cabinet smells." A scripted system stalls; because Pesta answers from a knowledge base rather than a script, its BASA capability understands the messy description and still classifies it correctly, the same reason it resolves the off-script call a rigid system would fumble. Second, Pesta's call analysis reads every maintenance call, so you can see where requests stall and which issues recur across units, turning intake into data you can act on rather than a black box.

None of this fixes the pipe or replaces your maintenance team. It makes sure the request reaches them as a clear, triaged ticket, which is the one step the tracking-software guides assume has already happened.

What losing the request actually costs

The capture gap is easy to underrate because a lost request does not show up as a line item; it shows up months later as a resident who does not renew. That makes it worth putting a number to.

[CALCULATOR EMBED - Lost-Request Renewal Cost Calculator Inputs: Maintenance calls per month | Share missed or mishandled at intake (%) | Share of affected residents who won't renew because of it (%) | Average cost of a turnover (lost rent, make-ready, marketing) ($) Live outputs: Requests lost at intake per month | Non-renewals caused per year | Annual turnover cost from the capture gap Formula: calls x missed% x nonrenew% x turnover cost, annualized]

Run it on your own numbers. A single missed after-hours emergency that sours a resident on renewing can cost a full turnover, and turnovers are expensive enough that even a low non-renewal rate on mishandled requests tends to dwarf the cost of answering every call.