The enterprise system gap is the difference between what a property management platform like Yardi or StarRez is designed to do and what your operation actually needs. Every operator running a major enterprise system develops manual workarounds to fill this gap - spreadsheets, shared inboxes, Monday morning exports, email template folders. These workarounds are rational responses to real gaps, but they accumulate into a significant and largely invisible operational cost that sits inside headcount, overtime and institutional knowledge that leaves when people do.
I spent years as a founding technology leader at Greystar Asia Pacific. And the thing nobody tells you when you take a role like that is how much of the job is not choosing technology. It is living with the technology that was already there when you arrived.
The enterprise system was selected before you got there. It went through a procurement process, a board sign-off, an implementation. Millions of dollars and eighteen months of someone's life. It is not going anywhere. Your job is to make the operation run on top of it.
And mostly, it does. That is worth saying clearly, because the discourse around legacy systems tends toward either uncritical defence or lazy dismissal. The reality is more nuanced. Yardi does what Yardi is built to do. StarRez is genuinely good at the student accommodation record-keeping problem it was built to solve. Oracle, for all it matters, is running the back office of organisations that cannot afford for the back office to fail.
The problem is not the system. The problem is everything the system does not do and the human labour that fills that gap.
Every operator has built the same spreadsheet
I have sat with operations teams at BTR operators, PBSA providers, commercial landlords, logistics businesses. Different systems, different industries, different team sizes. The pattern is identical.
There is a spreadsheet that tracks what the system cannot surface quickly enough. There is a shared inbox that a rotation of people monitors because the system's notification logic does not map to how the team is actually structured. There is a manual export that someone runs every Monday morning because the report the system generates is not quite in the format the business needs. There is an email template folder that a senior person maintains because the system's communication tools are functional but not flexible enough for how the team actually communicates.
None of this is the team's fault. Every one of those workarounds was built by a rational person responding to a real gap. The leasing manager who built the spreadsheet was not being inefficient. She was solving a problem that the system was not solving.
But workarounds add up. Each one requires someone to maintain it. Each manual step is a point of failure. Each piece of institutional knowledge about how the workaround works lives in someone's head rather than in a system. When that person leaves, the knowledge leaves with them. And the next person hired into that role spends their first three months learning not the job, but the workarounds.
This is not abstract. A BTR leasing team running manual lead follow-up because their CRM's notification logic is not quite right is losing tenancies, not because the CRM is broken, but because the gap between what it does and what the team needs requires a person to fill it and that person is not always available at the right time. A PBSA team processing application forms by hand because their PMS captures the data but does not route or file it is spending ten-plus hours a week on work that produces no value beyond getting data into a system that could have received it automatically.
The cost of workarounds vs. the cost of automation
Most operators frame this as a binary choice: replace the system (expensive, risky, years of work) or live with the workarounds (free, already running, known quantity). The actual comparison looks different when the workaround costs are made visible.
| Cost Type | Manual Workarounds | Targeted Automation |
|---|---|---|
| Finance team invoice processing | 40–90 hours/month in data entry | $100–$200/month infrastructure, 3-week build |
| PBSA application processing | 50–80 hours/week at peak intake | Eliminated; exceptions only (1–2% of volume) |
| BTR lead re-engagement | 7+ hours/month; tenancies lost to timing | 30%+ conversion improvement, no headcount |
| Institutional knowledge risk | Lost when staff leave | Encoded in workflow, not in people |
| Scalability | Requires proportional headcount | Volume-independent |
| Time to address | Indefinite (waiting for vendor roadmap) | 3 weeks per workflow |
The case for targeted automation is not that it replaces the enterprise system. It is that it closes specific, costed gaps without touching the core system at all - using the APIs and data access those systems already expose. This is the core of how TenthNode engagements work: fixed scope, fixed fee, built around your existing stack.
The AI roadmap problem
Most of the major enterprise systems now have an AI strategy. Yardi has been announcing AI features for the better part of two years. Oracle is building it into their property suite. StarRez has been doing things with automation in their newer releases. The vendor conferences are full of it.
If you are running one of these platforms, you have probably sat in a webinar where the product team showed you what is coming. It looked genuinely impressive. And the question you walked away with (the one nobody quite answered) was: when?
In my experience, enterprise software AI roadmaps run eighteen months to three years behind the announcement. This is not a conspiracy. It is just the reality of building AI features into systems that were architected in a different era, for a different set of assumptions about how data would flow and how users would interact with software. The retrofitting is genuinely hard.
The features that ship first are the ones that are easiest to build and easiest to demo. A smart search interface. An AI-generated summary in the sidebar. Useful, but not the thing that eliminates the Monday morning export or fixes the notification logic that never quite matched how the team works. Those are the deep, integration-level changes. They tend to come later. Or they come as add-on modules with separate licensing. Or they ship in a version that requires a re-implementation to access.
I am not saying the vendors are being dishonest about their roadmaps. I am saying that waiting for an enterprise vendor's AI roadmap to close the operational gaps your team is working around today is a specific strategic choice. Most of the organisations I have spoken to have not made it consciously. They are just waiting because waiting feels like the safe option.
What the gap actually costs
The cost of the workarounds is invisible because it is distributed. No line item in the budget says "manual compensation for system gaps." It sits inside headcount, inside overtime, inside the quiet assumption that certain things just require a person.
When you map it out, the number is usually larger than anyone expected. A finance team spending three hours every quarter-end manually reconciling data between two systems that should talk to each other. A student services team processing application documents by hand because the system captures them but does not route them. A finance team spending hours every month processing invoices by hand because the accounting system posts fine but does not capture, extract or code. A leasing coordinator handling lead follow-up manually because the CRM logs inspections but does not trigger outreach.
These are not big numbers individually. Collectively, across a team, across a year, they add up to something that would justify significant investment to fix, if anyone were tracking them.
The reason most organisations are not tracking them is that the people doing the work are not complaining loudly enough. They adapted. They built the spreadsheet. They got efficient at the workaround. And because they are efficient at it, the cost is invisible.
Deloitte's 2026 Commercial Real Estate Outlook, which surveyed over 850 C-suite executives at firms with at least $250 million AUM, identifies operational efficiency and technology integration as the primary levers available to property businesses in a constrained growth environment. The gap between what enterprise systems do and what operations need is consistently identified as the constraint. The workarounds are the symptom.
The thing I keep coming back to
The perspective is usually one or the other: either you replace the system or you live with it. Both options feel expensive. Replacement is a multi-year programme with significant execution risk. Living with it means the workarounds continue indefinitely.
What I think is underappreciated is how much is possible in the space between those two options, without touching the core system at all, without a vendor relationship, without a transformation programme. The enterprise systems that operators are running all have APIs. The data is accessible. The workflows can be read and written externally. The gap between what the system does and what the operation needs is largely a connectivity and automation problem, not a fundamental architecture problem.
That does not mean the solution is simple or that anyone can build it. But it does mean the choice is not as binary as it often feels.
The spreadsheet your leasing manager built is not a failure. It is a signal. It is telling you exactly where the system ends and the manual work begins. That boundary is more useful than most technology assessments I have seen, because it is drawn by the people who actually run the operation, in real time, in response to real gaps.
The question worth sitting with is not whether to replace the system. It is whether you have actually looked at what the workarounds are costing you and whether you have made a conscious decision about that cost, rather than just accepting it as the background noise of running the business.
If you want to map what that looks like for your operation, see what TenthNode builds or talk to us directly.
Frequently Asked Questions
Why do property operators build manual workarounds around enterprise systems like Yardi and StarRez?
Enterprise systems like Yardi and StarRez are designed to handle core property management functions well - accounting, records, compliance. The gaps appear where operational workflows extend beyond those core functions: notification logic that does not match team structure, reports in the wrong format, documents that are captured but not routed. Manual workarounds fill these gaps because they are faster to build than requesting vendor changes and cheaper than replacing the system.
Should I wait for my enterprise software vendor's AI roadmap?
Waiting for an enterprise vendor AI roadmap to close specific operational gaps is a strategic choice with a known cost: the workarounds continue running in the meantime. In practice, enterprise software AI roadmaps tend to run 18 months to 3 years behind the announcement date and the features that ship first address high-visibility use cases rather than deep integration gaps. Targeted automation built around existing system APIs can close specific gaps in 3 weeks, independently of the vendor roadmap.
Can you automate around an existing property management system without replacing it?
Yes. Major property management platforms including Yardi, StarRez and Kinetic expose APIs that allow external automation to read and write data. This means specific operational gaps - invoice processing, application handling, lead follow-up - can be automated by building workflows around the existing system rather than inside it. The enterprise system stays in place and continues to do what it does well.
How long does it take to automate a manual workaround for a property operator?
Targeted automation builds for property operators consistently go live in three weeks: one week for scoping and design, one week for build and integration, one week for testing and go-live. This applies across invoice processing, PBSA application handling and BTR lead re-engagement workflows. The build is fixed-scope and fixed-fee; you own the workflow and all infrastructure accounts on delivery.
What is the hidden cost of manual workarounds in property management?
The cost is distributed across headcount, overtime and institutional knowledge. Common examples: a finance team processing 300 invoices per month by hand spends around 40 hours per month on data entry. A PBSA team processing 200 applications per week manually absorbs 50 to 80 hours of admin before any allocation decisions are made. A BTR leasing team doing manual follow-up loses tenancies to timing rather than competition. None of these appear as a line item, but collectively they represent significant and recoverable cost.
Does automation built around an enterprise system break when the system is updated?
Well-built automation uses stable API endpoints and is designed to handle schema changes gracefully. Integration points are documented and versioned. When an enterprise system update does affect an integration, the fix is typically isolated to a specific connector rather than requiring a rebuild of the full workflow. This is one reason owning the workflow and infrastructure accounts - rather than relying on a managed service - gives operators more control over continuity.