The problem showed up in one building first
A regional property management company — 12 residential buildings, one small ops team — had a maintenance-request bottleneck. Tenants emailed or called in requests. A coordinator read each one, guessed at urgency, and routed it to a vendor or in-house tech. On a good week this took an hour. On a bad week, a burst pipe sat in the same inbox as a flickering hallway light, and nobody noticed the difference until a tenant called angry.
The team piloted a fix at their largest building: an intake form that tagged requests by category and urgency, then auto-routed them to the right vendor list and pinged the coordinator only for anything flagged urgent. Everything else moved without a human touching it.
Response time at that building dropped from an average of 14 hours to under 3. Tenant complaints about maintenance fell by half in the first month. It worked. And that's exactly where a lot of small companies stop — they call it a win, move on to the next fire, and let the other 11 buildings keep running the old way.
This company didn't. Here's what they did instead.
A win at one site isn't a system yet
The coordinator who built the pilot knew the shortcuts because she built it. The routing rules lived partly in the tool and partly in her head — which vendor covers plumbing after hours, which requests actually count as "urgent" versus "annoying but fine until Monday." None of that was written down.
That's the gap between a fix and a system. A fix solves the problem where you built it. A system solves the problem everywhere, for anyone who runs it — including a new hire six months from now who's never heard of the original pilot.
Before rolling anything out further, the team spent a week doing three things:
- Writing the routing logic as a real SOP. Every category, every urgency threshold, every vendor assignment — documented in plain language, not left as tribal knowledge in one coordinator's head.
- Separating what was building-specific from what was universal. Vendor lists differ by property; urgency categories don't. They built the SOP with a shared core and a swappable local layer.
- Naming what to measure. Response time by urgency tier, percentage of requests auto-routed without human intervention, and tenant complaint volume — the same three numbers, tracked the same way, at every building. If you want a broader framework for choosing metrics like these, match the metric to the leverage rather than picking numbers that just sound good.
This is the part most teams skip, and it's the part that makes scaling possible.
Rolling it out without redoing the work 11 times
With the SOP written, the rollout to the remaining 11 buildings wasn't 11 separate projects. It was one template applied 11 times, with a fixed process:
- Load the shared routing logic into each building's version of the intake tool.
- Swap in the local vendor list — the only building-specific input required.
- Run one week in parallel with the old manual process, so nothing fell through the cracks during the switch.
- Cut over fully once the parallel week showed no missed requests.
They staggered three buildings per week, not all 11 at once — the same discipline the original 90-day plan called for: one rollout at a time, not everything together. By week four, all 12 buildings ran the same system, with the same SOP, tracked against the same three metrics.
The coordinator's personal shortcuts were gone — replaced by a process any team member could run. That's the actual point of standardizing: the win stops depending on one person's memory and starts depending on a documented process anyone can execute.
What the numbers looked like company-wide
Across all 12 buildings after the rollout:
- Average response time for non-urgent requests fell from roughly 12 hours to under 4.
- Urgent requests — the ones that used to get buried — were flagged and routed within minutes, every time, because the rule was explicit rather than a judgment call.
- The coordinator's team went from manually triaging every single request to reviewing only the flagged exceptions — about 15% of total volume.
- Tenant satisfaction scores, tracked quarterly across the portfolio, ticked up at every building, not just the original pilot site.
None of that happened because the technology got smarter between building one and building twelve. It happened because the process got written down, standardized, and applied consistently. The tool did the same job at every site — the difference was that every site now ran it the same way.
Standardizing surfaced the next problem
Here's the part that matters most for what comes next: once maintenance routing was consistent across all 12 buildings, a second issue became visible that had been hidden in the noise before. Vendor response time — how fast an assigned contractor actually showed up after being routed a job — varied by a factor of three in some cases, building to building.
That variance had always existed. Nobody could see it clearly before, because inconsistent request routing swallowed the signal. Standardizing one process didn't just fix that process — it cleaned up the data enough to expose the next bottleneck in line.
That's the loop this framework is built around: lock in a win, measure it consistently, and let the clean data point you to what to tackle next. If you're at the stage of deciding what that next target should be, running a triage on the automate/improve/ignore framework is a fast way to sort vendor response time against everything else competing for the team's attention this quarter.
The lesson for anyone with more than one location
A single fix, however good, only proves the idea works. It doesn't prove the idea travels. The gap between those two things is exactly where documentation, consistent metrics, and a staged rollout earn their keep.
If you've got a win running well in one location, one team, or one process, don't treat it as finished. Write down what actually made it work, separate the universal parts from the local ones, and roll it out deliberately — one site at a time, measured the same way everywhere. For a closer look at exactly how to capture and template a single win before you scale it, locking in a first automation win walks through the documentation step in more detail.
Once the standard is in place across every location, don't stop there either. Standardization has a habit of revealing the next real problem — the one that was hiding behind inconsistent data the whole time. That's not a detour from the plan. That's the plan working.