A 90-Day Proof Plan for AI in Property Management

Why 'just run a pilot' keeps failing you

"Start with one workflow" is the most repeated and least useful piece of AI advice in property management. It tells you to begin but never tells you how to keep score, so pilots end in a shrug: someone says it "felt faster," someone else says residents "seemed happier," and the decision to scale gets made on vibes instead of numbers.

The second failure is the isolation trap. A pilot runs in one community, one manager babysits it, results never get written down, and when that manager leaves or gets busy the whole thing evaporates. The industry keeps warning about pilots that never scale precisely because most were never built to.

A real proof plan fixes both problems up front. It names the metric before go-live, sets a threshold that means "worked," and forces a decision at day 90 instead of letting the pilot drift into a permanent experiment nobody owns.

Step 0: Diagnose your #1 bottleneck before you pick an agent

A bottleneck is the workflow that eats disproportionate staff time, generates the most repeat questions, or carries the most deadline risk. It is where your best people burn hours on work no human judgment is required for.

Match the bottleneck to a specific agent so the proof is clean. If after-hours resident calls swamp you, that points to a first-response agent like Riley. If COIs and vendor licenses expire under the radar, that is Victor. If work order intake is chaos, Mason. Board packet prep, Bailey. Institutional memory per community, CAMeron. One bottleneck, one agent, one scoreboard.

Step 1: Capture three baseline numbers this week

You cannot prove improvement against a number you never wrote down. Before the agent handles a single task, capture three baselines tied to the bottleneck you chose. Two weeks of honest data beats a perfect month you never collect.

Pick one speed metric, one volume metric, and one quality metric. Speed is response or turnaround time. Volume is how much of the work the agent absorbs. Quality is whether humans had to redo, correct, or escalate the output. That third one is the honesty check that keeps you from mistaking activity for value.

The 90-day scoreboard: what 'it worked' looks like

Each checkpoint has a different job. Day 30 tests whether the agent is even usable in your real environment. Day 60 tests whether it moves your baseline numbers. Day 90 tests whether the win holds without babysitting and whether staff trust it. Set the thresholds before go-live so nobody moves the goalposts to justify a decision they already made.

1. 01

   Day 30: Is it usable and safe?

   Pass if the agent is live on real work, handling the target task with correct outputs on a clear majority of cases, and every risky item is escalating to a human as designed. You are not measuring ROI yet. You are confirming it fits your data, your tone, and your approval gates. Fail signal: staff still route everything around it, or outputs need heavy rewriting.

2. 02

   Day 60: Is it moving the baseline?

   Pass if your speed metric has meaningfully improved (for a response-time pilot, aim for at least a 40 to 50% cut) and the agent now absorbs a real share of volume without the quality metric getting worse. Fail signal: faster but sloppier, or the numbers barely moved because adoption stalled.

3. 03

   Day 90: Does the win hold and do people trust it?

   Pass if the gains from day 60 held for a full month without anyone babysitting, escalation and rework stayed flat or fell, and the frontline staff who use it would object if you turned it off. That last part matters: an agent nobody defends will not survive contact with a busy week.

The pilot-to-portfolio bridge (avoiding the isolation trap)

The uncomfortable truth: most PM AI pilots succeed on the metric and still die, because nobody planned the second community before the first one finished. A win that lives in one manager's head is not a win, it is a liability waiting to leave with them.

Write the scaling rule before go-live: "If the day 90 scoreboard passes, we deploy this agent to the next three communities within X weeks, owned by Y, using the same thresholds." That single sentence is the difference between a pilot and a rollout. It forces the decision instead of letting the experiment become permanent.

The other half of the bridge is documentation. Because a trained agent carries what it learned about each community, the knowledge does not evaporate when a manager moves on. That is the actual portfolio value: not that one community got faster, but that the improvement is repeatable and does not depend on one person remembering how things work.

“The pilots that scale are boring on purpose. They have a number, a threshold, and a named next community before day one. The ones that die were always going to die: they were demos wearing a pilot's clothes.”

Todd Paton, Partner, One Home Agent

What to do if it doesn't hit the threshold

A missed threshold is data, not defeat, and there are only three honest reasons for it. Diagnose which one you have before you decide anything, because the fix is different for each.

First, wrong bottleneck: the workflow you picked was not actually costing you enough to notice a change. Switch the target, keep the method. Second, adoption stall: the agent worked but staff routed around it, which is a training and trust problem, not a technology one. Third, genuine fit failure: the task needed more human judgment than the workflow assumed, in which case you narrow the scope to the truly repetitive slice and re-baseline.

Start your proving ground

Run the plan in order: diagnose the bottleneck, capture three baselines this week, set the day 30/60/90 thresholds, and write the scaling rule before go-live. If it passes, you scale on evidence. If it fails, you learned which workflow to attack next, and it cost you nothing but attention.