Property management is really just three jobs stacked into one title: leasing, rent collection, and maintenance. Two of those are, for any reasonably experienced operator, basically solved problems. The third has an entire annual conference built around it, pulls hundreds of operators into a room every year, and still doesn't have a clean answer.

I just spent a few days in Rapid City, South Dakota at Property Meld's MX Summit (as far as I know, the only PM conference built exclusively around maintenance). There's no equivalent event for leasing. There's no equivalent event for rent collection. That gap alone tells you something. Sitting in that room confirmed a theory I've had for a while: maintenance isn't hard because our people or our software are bad. It's hard because of what maintenance actually is, structurally, compared to the other two-thirds of the job.

The Three Jobs Inside Every PM Company

Strip away the org chart and the software stack, and every residential PM company is doing three things:

  • Leasing: getting units occupied with qualified tenants, plus renewals
  • Rent collection: getting paid, plus the escalation path when you don't (late fees, evictions)
  • Maintenance: keeping the property functional, plus turnovers between tenants

Vendors and software categorize themselves this way too, which isn't a coincidence. It's because these three jobs behave completely differently as problems to solve, and that difference is the whole story.

Why Leasing and Rent Collection Got Easy

"Begin with the end in mind" only works if there's an end in mind to begin with. Leasing and rent collection both have that.

Leasing's end state is simple: the unit is occupied with a good tenant. The activities that get you there are a short, closed list: list it, screen applicants, sign a lease. Rent collection's end state is just as clean: you have the rent, or the tenant is out. Again, a short list of activities: send reminders, post late fees, run the eviction process if it comes to that.

Because the range of valid moves is so narrow, you can write the entire policy for either function on a single page. A brand-new coordinator can read it on day one and know what to do in nearly every situation. And because the policy is complete and stable, it can eventually be encoded almost entirely into software, which is exactly what's happened. Nobody's flying to a conference to argue about how leasing should work anymore.

Maintenance Doesn't Play By Those Rules

Maintenance has no equivalent clean end state, and the range of possible actions is close to unlimited.

Start with a simple example. A tenant calls in reporting a musty smell in a closet. Is that a landlord responsibility (early-stage mold, a slow leak behind the wall), or is it a wet towel someone left in a hamper for two weeks? Nowhere in leasing or rent collection does "do nothing" show up as a legitimate outcome. In maintenance, it's an everyday possibility, and guessing wrong in either direction gets someone in trouble.

Now say it is a real issue: the water heater's out. The end state seems obvious: working water heater. A vendor gets dispatched, the repair gets made, everyone should be happy. Except the owner sees the invoice and calls in furious, because the water heater was replaced under the previous management company less than a year ago and should still be under warranty. The correct outcome was technically reached, and it was still done wrong, because "correct outcome" was never actually a complete definition of the job.

That's the trap. Maintenance coordinators aren't failing at a well-defined task. They're being asked to make judgment calls, constantly, inside a task that was never fully defined for them in the first place.

The Policy → Process → Tech Hierarchy, and Why We Skip Step One

When something's broken in a business, the instinctive move is to blame the software or the people. "If my team were sharper, or my software actually worked, this wouldn't be an issue." I don't think that's true, and I think it's especially untrue in maintenance.

The real hierarchy runs policy → process → tech. Policy defines what your process should do. Process is that policy turned into repeatable steps. Tech is process encoded into software so it runs at scale. Your people mostly live at the process and tech layer, which means if the policy above them was never actually written down, no amount of hiring or platform-switching fixes anything. You're rearranging furniture on a floor with no foundation under it.

This is also where half-measures do real damage. A maintenance policy that covers half the situations and leaves the rest to "use your judgment" isn't a lighter version of a full policy. It's close to as chaotic as having no policy at all, because now your coordinator has to figure out, case by case, whether this situation is one of the documented ones or one they're supposed to freelance. That ambiguity is exhausting, and it's exactly why the same edge cases get re-litigated every single week.

A real maintenance policy has to actually answer things like:

  • What counts as a landlord responsibility versus a tenant one, and who makes that call in gray areas?
  • At what dollar amount does a repair need owner sign-off before a vendor is dispatched?
  • Is there a standing order of preferred vendors, and does prior work history on the unit factor in?
  • What's the response-time standard for an emergency versus a routine request, and who decides which one this is?
  • At what point does "repair" become "replace"?

None of that is a software problem. It's a documentation problem that happens to get blamed on software.

Why This Explains the Conference Itself

Once you see maintenance this way, it explains why an entire industry shows up to compare notes on it, year after year, while nobody's doing the equivalent for leasing or rent collection. Nobody's cracked the full policy layer alone, so operators are effectively crowd-sourcing it: a few hundred people at a time, trading edge cases and near-misses, trying to build something no single company's experience is broad enough to write by itself.

Credit to Ray Hespen and the Property Meld team for building software that takes this seriously and for pulling that many operators into one room to work on it together. The software isn't the missing piece, though. It's just the tool that finally has something worth encoding, once enough of the policy underneath it gets written down.

Related: Running In-House Maintenance? You Need This Formula.

None of this means maintenance can't get better. It means the fix starts with the policy nobody's written yet, not the next platform you're evaluating.