Article · September 25, 2026
AI changes the work around it. Discover what your team actually does, define the responsibilities that remain, and train people for the job they will do next.
I underestimated how much retraining our AI rollout would require.
At Northpoint, we had assigned the first part of the leasing conversation, through tour scheduling, to AI, with defined reasons to hand the interaction to a person. We wanted our leasing team available for work later in the process. But people kept stepping into the early conversations.
People needed to understand when to step in, when to let the process continue, and where we now needed their attention.
Having a capability and being organizationally capable of using it are different things. A person can know how to use a tool and still need help learning the job around it.
Preparing for that job starts with understanding the work people already do.
At Northpoint, we planned a Demo Day: teammates would show us how they used their tools. Within the first few sessions, we realized we were discovering how the company actually worked. We renamed it Discovery Day.
Experienced people make decisions they no longer think to explain. Their description of a process may leave out the judgments that keep it moving. Watching them work helps reveal what the new process and its training must preserve.
Start with one role and one process. Watch someone perform it. Ask about the decisions, checks, and follow-up between the documented steps.
Then describe what AI may do and what the person will still own:
| Task or decision | Today | Proposed AI part | Human responsibility afterward | Preparation needed |
|---|---|---|---|---|
| Name one actual task. | Who does and checks it? | What may AI prepare, suggest, or do? | Who decides, acts, or checks? With what information and authority? | What must change? What will the person practice? |
Map the work before and after AI
Before telling someone to stop using a workaround, understand what it accomplishes. It may reflect an old habit or a training gap. It may also meet a legitimate need the intended system does not handle. Removing it could remove necessary capability. That finding should shape whether you change the training, the process, or the system.
Once those needs are accounted for, agree what should stop and where people's attention should go. In our leasing example, teaching only when to intervene would have left the rest of the new role unexplained.
Be specific about where that attention should go. “Spend more time on higher-value work” leaves the employee to guess which work matters, what good performance looks like, and what takes priority.
During our software migration, the new system made sense to me. Our team was learning new steps while unlearning years of habits built around the previous one.
I expected people to learn on their own when they needed more structured help. We provided resources and recurring opportunities to ask questions, but I had not provided enough structure upfront or clearly explained the learning plan.
Watch a daily user try the changed task. Find where they hesitate or lack information. Build practice and support around those points, with a short guide covering what to check and where to get help.
The test is whether they can do the work with the guides and support they will actually have.
Consider a resident who does not want to continue automated troubleshooting and wants someone to help.
Define what triggers the handoff, who receives it, what information follows the case, and how the recipient confirms they have it. Include a backup when that person is unavailable.
Prepare the receiving person to read the history, identify unknowns, decide what happens next, and explain it to the resident. Agree which decisions require help.
A practical training sequence is:
Include a case with missing information, a questionable AI result, or an unavailable recipient. People need practice recognizing when the usual path will not work.
Reviewing AI conversations with prospects revealed gaps in the property or policy information we had supplied.
That review also gave us work to assign: identify what is missing, get the right information or decision, and check whether the correction helped.
That is part of what I mean when I say defects are data. A poor result gives us something to investigate. The cause could involve context, process, training, the tool, or several things together.
Teach people how to bring a useful problem back: what they expected, what happened, and where someone can inspect it. Name who will review those reports and who can make or arrange a correction. Give that person time to do the work. Adding “monitor the AI” to an already full job description does not create that time.
If routine work shrinks, what happens to the mix of work people handle?
There may be more room for relationships and physical presence. Difficult cases may also become a larger part of the day.
I would inspect both possibilities. Are people getting to work they previously struggled to reach? Are they spending more time checking results, recovering from errors, or handling difficult conversations? Do they have the authority and support those responsibilities require?
Review performance expectations with the role. Routine transaction counts may tell you little about someone now responsible for investigation or complex cases. Time saved on one automated step also does not establish how much time is available for another assignment.
For each role whose work changes, complete a short brief:
Start with one role and one process. Watch what happens, talk with the people doing the work, and revise the expectations and training together.
I have come to realize there is no final “after” to transformation. Each improvement exposes another constraint. Training has to keep pace as new exceptions and responsibilities emerge.
If I expect someone to do a different job after an AI rollout, I need to explain that job, help them practice it, and stay involved as the work keeps changing.
Contributors
Steven works where operations, people, and technology meet. He built RPM Living’s first training program and helped develop its technology stack, then worked across operations and growth at ResProp. His focus is turning operating knowledge into systems people can actually use—with clear responsibilities, practical training, and feedback that improves the work.
Video
Steven Rea shares the work behind implementing AI in leasing and maintenance: clear context, defined processes, team training, and ongoing evaluation. Start with one workflow and use defects to improve the operation.
WatchVideo
The hard lessons from moving a maintenance operation from Property Meld to AppFolio.
WatchVideo
A conversation on what is actually holding AI back in property management—and what needs to change first.
Watch
