How AI helps property managers respond to tenant requests faster, and the one clock it cannot move

In short: AI cannot make a repair happen faster. It has no van and no plumber. What it can compress is the wait before anyone responds, the time to correctly categorize the request, and the delay before it reaches the person who can act. Those are different clocks, and almost every vendor sells the one they cannot move.

Key takeaways

• There are four clocks in a tenant request: acknowledgement, triage, dispatch, and resolution. AI moves the first three. It does not move the fourth, and any vendor claiming otherwise is selling you a plumber they do not employ.
• Peter Lohmann of RL Property Management publishes a live KPI scorecard. As of July 2026 it shows median repair days of 6 against a stated routine SLA of one to three weeks. The gap between those two numbers is where resident frustration actually lives.
• Lohmann's ordering is Policy, then Process, then Tech. His line on skipping it is the most useful sentence written about AI in this industry: without documented processes, the technology just makes mistakes faster than you currently do.
• After hours volume is concentrated, not random. In RLPM's published 2019 after hours data, no heat, water leaks, and lockouts made up 77 of 150 calls. That is a known distribution, which means it is a triage problem, not a reasoning problem.
• On a live property management line we run, 73 of 110 calls over ten days were resolved in the call itself without a person. A quarter of the callers were upset when they rang. All of them were handled to completion.

Two clocks, and only one of them is yours

Peter Lohmann runs RL Property Management in Columbus, about 600 doors, and he does something almost nobody else in this industry does. He publishes his operating numbers on a live scorecard where anyone, including his competitors, can read them.

As of July 2026 that page shows a median repair time of 6 days. Elsewhere on the same site, the stated service standard for routine maintenance is one to three weeks. Resident satisfaction sits at 4.3 out of 5.

Hold those numbers next to each other, because they are the whole argument. A median of 6 days is genuinely good. A one to three week window is an honest promise about the worst case. And a resident whose dishwasher is leaking does not experience either number. They experience the silence between submitting the request and hearing back.

Lohmann has written the sharp version of this himself: a cheap maintenance rate is meaningless if the response takes three weeks. He is talking about owners choosing a manager. The same logic runs downhill to residents, and it is the reason the maintenance experience is the single biggest lever on renewal, which he has also written about at length.

So when someone asks whether AI can make you respond to tenant requests faster, the useful answer starts by splitting the question.

The four clocks

Every tenant request has four separate timers running, and they are almost never measured separately.

Acknowledgement. From the moment the tenant submits until a human or system confirms it was received and understood. In most operations this is the largest and least measured number in the whole chain. Overnight, it is the entire night.

Triage. From acknowledgement until the request is correctly classified. Emergency or routine. Resident responsibility or owner cost. In house team or third party vendor. Misclassification here is expensive twice, once when you dispatch wrong and again when the tenant loses trust in the process.

Dispatch. From classification until the right party has the job with the right context. Address, access instructions, unit history, what was already tried.

Resolution. From dispatch until the thing is actually fixed.

AI moves the first three. It cannot move the fourth. A language model does not own a van, hold a licence, or carry a compressor up three flights of stairs. Resolution time is governed by your vendor bench, your parts availability, and your in house team's calendar, and no amount of software touches any of that.

That sounds like a limitation. It is actually the useful part, because acknowledgement and triage are where the tenant's felt experience is formed, and they are the cheapest clocks to fix.

The precondition nobody puts in the sales deck

Before any of this works there is a step Lohmann is right about and most vendors skip. His ordering is Policy, then Process, then Tech, an idea he credits to Jordan Muela. Get the policy written, turn it into a documented process, and only then put technology on top.

His warning about doing it in the wrong order is the most useful sentence anyone has written about AI in property management: without documented processes, the tech is just going to make mistakes faster than you do now. He puts it another way too. Most property management companies do not have a technology problem. They have a clarity problem.

We agree with this completely, and we will go further, because it has a specific consequence for anyone about to buy an AI tool.

An AI system answering your maintenance line has to decide, in about ninety seconds, whether a call is an emergency. That decision is not a modelling question. It is a policy question. Is a clogged drain your cost or the resident's? Is no heat at 40 degrees an emergency or a next morning job? Do you dispatch a locksmith for a 2am lockout or tell the resident to call one? RLPM has an answer to that last one, publicly, and it is that they do not provide after hours lockout service.

If your company does not have written answers to questions like those, an AI cannot invent them, and if it tries, it will be confidently wrong at 3am on a Sunday in a recorded call. The documentation is not paperwork you do before the fun part. It is the specification.

This is most of what we spend an [AI readiness audit](/blog/five-questions-every-audit-answers) doing, and it is why we will not skip straight to a build for a client who has not done it.

A model deciding whether something is an emergency is not making a technical judgment. It is applying your policy. If the policy is not written down, you have not automated a decision. You have delegated one, to something that will guess.

What this looks like on a live line

We run an inbound voice agent for a Toronto property management operation. Over a ten day sample, 110 calls. The client stays anonymous, the numbers do not.

73 of those 110 were resolved inside the call itself, with no person involved at any point. The rest were captured, summarized, and flagged to the right staff member with the caller's number attached. Average call length was about a minute and a half. Across the combined property management and brokerage volume in the same period, 27% arrived after hours or on a weekend. Zero calls went unanswered, because the thing answering does not sleep.

The detail we did not expect: 27 of those 110 callers were upset when they rang. Flooding in a unit and no idea whether to call a plumber or wait. A fallen tree that took out the internet. A front door that would not close. A leaking dishwasher. These were not tidy requests from calm people, and the assumption we went in with, that AI handles the easy calls and humans take the hard ones, did not survive the data. The angry calls were handled to completion at roughly the same rate as the rest, because what an upset tenant at 9pm wants first is not a repair. It is confirmation that a competent party now has the problem.

The genuinely boring wins were the largest category. How do I pay an outstanding balance. Do you manage this building. Can my brother do the yard work at my property. Every one of those is a question with a written answer, asked at a moment when nobody was available to give it.

After hours volume is concentrated, and that is the opening

Here is where Lohmann's published data does something no vendor case study can. In 2019 RLPM logged all of their after hours calls and put the breakdown on the internet. 150 calls for the year. 34 no heat. 23 water leaks. 20 lockouts. 13 drain clogs. 13 no air conditioning. 12 no power. 10 appliance issues. A handful of gas leaks, frozen pipes, break ins, one rodent, one wildlife.

Three categories account for 77 of 150 calls. His conclusion from the same dataset is worth carrying around: roughly one in four units will call you with one after hours emergency per year.

That distribution is the entire design brief. You are not building something that has to reason about an unbounded space of tenant problems at 3am. You are building something that has to recognize about a dozen categories with high reliability, apply a written policy to each, capture a callback number, and escalate the two or three that genuinely require waking someone up. That is a tractable problem, and it is tractable specifically because operators like Lohmann published the distribution instead of guessing at it.

Most PM companies have this data sitting in their own call logs and have never counted it. Counting it is free and it takes an afternoon.

What is oversold

Lohmann walked the NARPM Broker/Owner expo floor this year and described what he saw plainly. Some of the AI on display was genuinely useful. Some of it, in his words, was rebranded if then logic with a chatbot bolted on.

He has also drawn a line we think every operator should copy. He stopped covering vendor AI announcements in his newsletter unless they include two things: when you can actually get it, and what it costs. He named the companies that failed the test. His argument is that without those two details it is not news, it is a billboard.

We will hold ourselves to that, so here is the plain version for the kind of system described above. It answers on the first ring, 24/7. It resolves the categories you have written policy for, and it captures and routes the rest with a callback number. It does not make a repair happen faster. It does not reduce your vendor spend. It does not let you run the same portfolio with fewer people, and we would not build it if that were the goal, because [AI should give people back their time rather than take their jobs](/blog/why-we-named-the-company-the-system). Typical build runs four to ten weeks after a two week audit, and the full price list is already published in [what AI consulting actually costs](/blog/what-ai-consulting-actually-costs), because a number you have to email us for is not a number.

What to do this week

Five things, none of which require buying anything.

1. Pull last quarter's maintenance requests and time-stamp four moments, not one. Submitted, acknowledged, classified, resolved. Most operations only track the first and last. The two in the middle are the ones you can actually move.
2. Count your after hours calls by category for the last twelve months. You are looking for the concentration. If three categories are half your volume, you have found your build scope.
3. Write down your emergency definition. Then hand it to someone who does not work in maintenance and ask them to classify twenty real past requests with it. Every disagreement is a gap an AI would have guessed at.
4. Find the requests that are questions, not repairs. Balance enquiries, policy questions, "is this mine or yours." In our sample these were the largest clearable category and they are the least risky thing to automate first.
5. Before you evaluate any vendor, ask for availability and price. Lohmann's two-detail rule is the cheapest filter in this industry and it eliminates most of the field in one email.

None of this makes your plumber faster. It makes the eight hours before your plumber gets the ticket stop being eight hours, and it means the person waiting knows, within seconds, that someone competent has the problem.

That is the whole of what AI does for tenant response time right now. It is smaller than the pitch decks claim and considerably more valuable than the skeptics allow, and the operators publishing their real numbers are the reason we can be specific about which is which.