The conversation about AI in property operations almost always starts with the wrong noun. It asks which jobs will be replaced, which roles are at risk, how many people a portfolio will still need. And because it starts there, it produces a headcount plan, a projection of positions to eliminate, which is usually both wrong and a distraction from where the value actually is.
Watch what a property manager, a leasing coordinator, or an accounting specialist actually does for a week, and a different picture emerges. A large share of their time is not spent on the work their title describes. It is spent moving information between systems that do not talk to each other, reconciling two records that should agree, re-entering the same data in a third place, chasing a status update, and translating between the format one system produces and the format another one needs. That activity is not the job. It is friction, the overhead the organization generates because its parts are not connected, and it is what AI is actually good at removing.
Get the noun right and the whole plan changes. AI is not primarily replacing the person. It is replacing the friction the person was absorbing, and those are very different things to build a strategy around.
The friction is measured, and it is enormous
This is not a soft observation about busywork. The scale of coordination overhead has been quantified, and it is larger than most executives assume.
The McKinsey Global Institute, in its work on the social economy, found that the average knowledge worker spends nearly 20% of the workweek searching for internal information or tracking down colleagues who can help with a task, which works out to roughly 1.8 hours a day, or about nine full working weeks a year per person spent not producing anything, just locating what is needed to produce. That is one component of friction, information retrieval, and it alone consumes a fifth of the week.
Add the rest and the total climbs. Asana's State of Work Innovation research has found that knowledge workers spend around 60% of their time on what it calls work about work: coordination, status chasing, switching between tools, and duplicating effort, leaving only about 40% for the skilled work they were actually hired to do. The specific figures vary across studies, but the direction is unmistakable and consistent. The majority of a knowledge worker's time in a fragmented environment goes to the overhead of fragmentation rather than to the work itself.
In a property operation, that fragmentation is acute, because the operation is stitched together from a property management system, an accounting system, spreadsheets, email, and a set of external parties, none of which share a record. The friction that McKinsey and others measure in general knowledge work is, in property, close to the median experience.
The person whose job looks automatable is usually the friction absorber
Here is the reframe that matters for anyone planning around AI. When you look at a role and conclude it is highly automatable, look more closely at what specifically makes it look that way. Very often, the reason the job appears to be mostly automatable tasks is that the job has silently become mostly friction absorption.
The accounting specialist who spends their days reconciling exports between two systems is not doing accounting most of the time. They are compensating, manually, for the fact that the two systems do not reconcile themselves. The leasing coordinator who re-keys applicant data across three tools is not doing leasing work in those hours. They are being a human integration layer. These roles look automatable because a large fraction of what they do is the mechanical movement of information, and that fraction is not the value of the role. It is the tax the organization imposed on the role by never connecting its systems.
This distinction is the whole game, and it echoes a pattern examined in the job you're actually automating: the visible, automatable tasks and the actual value of a role are frequently different things. Applied here, the point is specific. If you automate the friction and eliminate the person, you have thrown away the judgment, the relationships, and the exception-handling that were buried under the friction, and kept only the savings. If you automate the friction and keep the person, you have converted a friction absorber back into whatever their title actually promised, which is almost always worth more than the salary you would have saved.
Why the headcount framing produces bad decisions
Framing AI as a headcount question rather than a friction question leads reliably to worse outcomes, for a few reasons.
It targets the wrong thing. A headcount plan removes people, which removes both the friction absorption and the underlying value. A friction plan removes the friction, which frees the value. The first optimizes for a one-time cost reduction. The second optimizes for capacity, and capacity is what a growing property portfolio is usually short of.
It also measures the wrong outcome. The natural metric for a headcount plan is positions eliminated, which is exactly the activity-flavored measure that looks like progress without proving value, a trap examined at length in the metrics that lie about AI success. Positions eliminated tells you nothing about whether the work got better, and it actively hides the possibility that you removed capability along with cost.
And it generates internal resistance that quietly sabotages the whole effort. If AI is introduced as the thing that eliminates jobs, the people who understand the operation best, the ones whose knowledge you need to deploy it well, have every reason to withhold that knowledge and to route around the tools. If it is introduced as the thing that removes the tedious friction from their day, the same people become allies. The framing is not just a communications choice. It determines whether the deployment succeeds, because the people who absorb the friction are the people who know where it is.
The honest part
Several qualifications keep this from becoming a comfortable evasion, because the comfortable version of this argument is dishonest.
Removing friction does genuinely reduce how many people a given volume of work requires, and pretending otherwise is not credible. If a role was 60% friction and you remove the friction, the organization does need fewer of that role to handle the same volume, or it needs the same number handling much more. Over time, at the level of the whole industry, that shows up as slower hiring rather than as the same people doing more forever. The friction framing is more accurate and more humane than the headcount framing, but it is not a promise that employment is unaffected. It is a claim about what you should target and in what order, not a guarantee about the end state.
It is also true that some roles genuinely are mostly friction with little underneath, and for those, automation is straightforwardly a headcount reduction and calling it anything else is spin. The distinction the piece insists on, friction absorber versus friction-plus-value, is real precisely because it does not apply uniformly. Some roles are almost all value with a little friction, some are the reverse, and honest planning sorts them rather than applying one story to all.
And removing friction is harder than removing people, which is why organizations so often reach for the headcount version. Connecting systems, or replacing the human integration layer with an actual one, is real work with real cost, whereas cutting a position is a line in a spreadsheet. The friction framing is correct, but it is not the easy path, and anyone selling it as effortless is selling something.
Target the friction
The practical discipline is to run the analysis in the right order. Before asking which roles AI could reduce, map where the friction is: which people spend which fraction of their time moving information between systems, reconciling records, re-entering data, and chasing status. That map is usually available for free, because the friction absorbers know exactly where it is and will tell you if the exercise is framed as removing their tedium rather than removing them.
Then, for each concentration of friction, ask the question that separates the two framings. If this friction disappeared, what would the person do with the reclaimed time, and is that worth more than their cost? Where the answer is a list of higher-value work the friction was crowding out, you have found a role to free rather than cut. Where the answer is genuinely nothing, the role was mostly friction, and reduction is the honest call. Most roles land in the first category, which is why the headcount-first framing gets the majority of cases wrong.
The organizations that get the most from AI in property will not be the ones that eliminated the most positions. They will be the ones that correctly identified their friction, removed it, and let the people who had been absorbing it do the work they were actually hired for. The friction was never the job. It was the cost of an operation that was never connected, and removing it is the opportunity, whoever ends up doing the work that remains.
FAQs
Q1. Isn't AI going to replace jobs in property operations?
It will change how many people a given volume of work requires, but the primary thing it removes is friction, the manual movement of information between disconnected systems, rather than the judgment and relationships a role actually contributes. Framing it as job replacement targets the wrong thing and tends to eliminate value along with cost. The more accurate framing is that AI removes the overhead the organization imposed on roles by never connecting its systems.
Q2. What do you mean by organizational friction?
The overhead a fragmented operation generates: time spent searching for information, reconciling records that should already agree, re-entering the same data across tools, chasing status updates, and translating between incompatible formats. Research finds knowledge workers spend a large majority of their time on this kind of coordination overhead rather than on their actual work, and property operations, stitched together from several unconnected systems, are especially exposed.
Q3. Why does the role look automatable if the value isn't in the tasks?
Because a large fraction of the role has quietly become friction absorption, and friction is exactly the mechanical, repetitive activity AI handles well. The role appears automatable because so much of the visible work is moving information around, but that movement is the tax the organization placed on the role, not the role's actual contribution. Removing the tax and keeping the person is usually the better move.
Q4. Why is headcount the wrong way to frame this?
Because it optimizes for one-time cost reduction rather than capacity, measures success by positions eliminated rather than by whether work improved, and generates resistance from the people whose knowledge the deployment needs. A friction framing frees capability, produces a better metric, and turns the friction absorbers into allies rather than obstacles. The framing materially affects whether the deployment works.
Q5. Doesn't removing friction still mean needing fewer people?
At sufficient scale, yes, and it would be dishonest to claim otherwise. If a role was substantially friction and the friction is removed, the same volume needs fewer of that role, which shows up over time as slower hiring. The argument is about what to target and in what order, not a guarantee that employment is unaffected. Targeting friction is more accurate and more humane than targeting headcount, without pretending the end state is unchanged.
Q6. Are some roles genuinely mostly friction?
Yes, and for those, automation really is a headcount reduction, and calling it something softer would be spin. The distinction between a friction absorber with real value underneath and a role that is almost entirely friction is the whole point, and it requires sorting roles honestly rather than applying one narrative to all of them. Some are mostly value, some are mostly friction, and planning should reflect the difference.
Q7. Why is removing friction harder than removing people?
Because eliminating a position is a line in a budget, while removing friction means connecting systems or building a real integration layer to replace the human one, which is genuine work with real cost. This is precisely why organizations default to the headcount version even though it is usually the worse decision. The friction framing is correct but not effortless, and it should not be presented as a free lunch.
Q8. How should we actually start?
Map the friction before touching the org chart: identify who spends what fraction of their time moving information between systems, reconciling, re-entering, and chasing status. Then for each concentration, ask what the person would do with the reclaimed time and whether that is worth more than their cost. Most roles turn out to have valuable work the friction was crowding out, which means freeing them, not cutting them, is the higher-return move.