Over the course of this series, I started with a simple question from a property manager:
How can AI help manage dozens of maintenance requests across multiple large residential buildings?
At first, the problem looked like an email problem. It wasn’t.
The real problem was everything that happened after the email arrived.
- A resident reports an issue.
- Someone has to understand it.
- Categorize it.
- Decide how urgent it is.
- Check whether someone else already reported it.
- Acknowledge the resident.
- Figure out who should handle it.
- Get approval.
- Contact the contractor.
- Track the response.
- Update the resident.
- Close the loop.
- That is the work around the work.
And that is where AI can have a practical impact.
In the previous parts, I looked at commercial platforms such as Property Meld, Entrata, AppFolio, Building Engines and Zendesk. Then I designed a narrower custom alternative. Then I worked through the economics of building it.
And after all of that, I don’t think the decision is really:
Build or buy?
There are three choices.
Buy. Build. Or Integrate.
And each one makes sense under different conditions.
Option 1: Buy
Buying an existing platform is probably the right answer when the organization needs a substantial portion of what that platform already does.
This is especially true if the property manager needs more than maintenance intake.
Perhaps they also need:
-
technician scheduling
-
contractor management
-
resident communications
-
mobile tools
-
inspections
-
preventive maintenance
-
reporting
-
vendor management
-
accounting integration
-
broader property-management functionality
At that point, rebuilding mature commercial software usually makes very little sense. A platform such as Property Meld has already spent years solving maintenance-specific workflow problems.
Entrata and AppFolio combine maintenance with broader property-management capabilities.
Building Engines goes deeper into building operations.
Zendesk brings mature customer-service workflow and communication capabilities.
If one of these platforms already solves most of the problem, the practical answer may simply be:
Buy it.
That also means buying something that is easy to overlook when comparing licensing costs:
Responsibility.
With commercial SaaS, the vendor is responsible for maintaining the application.
They handle:
-
infrastructure
-
software updates
-
security patches
-
ongoing product development
-
support
-
many integration changes
-
uptime
That has value.
A subscription isn’t simply paying for code.
It’s paying someone else to remain responsible for the product.
When I Would Lean Toward Buying
I would lean toward buying when:
-
the organization needs most of the platform’s functionality
-
the existing workflows fit reasonably well
-
the organization doesn’t want to maintain custom software
-
implementation risk needs to remain low
-
time to value matters
-
the portfolio isn’t large enough for licensing costs to materially change the economics
-
the vendor can demonstrate the exact workflow the organization needs
And that last point matters.
I wouldn’t choose based on a checklist.
I’d make the vendor demonstrate the real scenario.
For example:
A resident reports water near the P2 elevator lobby. Show me how your system receives it, identifies urgency, checks for duplicates, acknowledges the resident, routes it correctly, obtains approval, contacts the contractor and updates everyone when the work is complete.
If the software handles that workflow well, that tells me much more than a list of 75 features.
Option 2: Build
Custom development becomes more interesting when the problem is much narrower.
Suppose the organization already has:
-
accounting
-
leasing
-
resident records
-
payment systems
-
property-management software
-
contractor relationships
-
reporting
And the real problem is simply:
“We spend too much time turning maintenance communications into coordinated action.”
In that situation, buying an enormous platform may mean paying for capabilities the organization doesn’t actually need.
That is where the custom system I outlined in this series becomes interesting.
It doesn’t try to be a property-management platform.
It does one thing:
Resident request → AI triage → incident → human approval → contractor → resident updates
That’s much more bounded.
And bounded problems are much better candidates for custom software.
When I Would Consider Building
I would investigate custom development when:
-
the problem can be clearly defined
-
existing systems already handle the rest of the business
-
commercial platforms include far more than the organization needs
-
the maintenance workflow is unusually specific
-
approval requirements are unique
-
integration with internal systems matters
-
per-unit SaaS pricing becomes significant at portfolio scale
-
the organization wants control over workflow and data
-
someone is prepared to own the software after launch
That last one is easy to ignore.
A custom system requires an owner.
Someone has to care about:
-
support
-
bugs
-
enhancements
-
security
-
integration changes
-
infrastructure
-
future requirements
If nobody wants that responsibility, don’t build. Even if the spreadsheet says it might save money.
Option 3: Integrate
This is the option I think is easiest to overlook. You may not need to buy an entirely new platform, and you may not need to build an entire maintenance system.
Perhaps the organization already has good tools, they just don’t talk to one another very well.
Imagine:
- Existing property-management system
- Existing customer-service or ticketing system
- AI orchestration
- Contractor communication
That can become a very powerful middle ground.
The custom component may only need to:
-
receive maintenance requests
-
classify them
-
detect duplicates
-
pull property information from an existing system
-
recommend the correct workflow
-
update the existing ticketing or property-management platform
-
generate communications
-
trigger approval workflows
Now you’re not rebuilding the entire stack, you’re building the connective tissue.
And that may be the most cost-effective solution of all.
Why Integration Can Be Attractive
Integration makes sense when:
-
the organization likes its existing software
-
replacing core systems would be disruptive
-
only a few workflow gaps are causing most of the pain
-
APIs are available
-
the organization needs flexibility without full custom ownership
-
AI can be added as a layer rather than becoming the whole application
This is also where something like Zendesk can become more interesting.
Zendesk may not be property-maintenance software.
But if the organization already uses it for customer communications, perhaps it handles intake and approvals while an existing property-management system holds property and contractor data.
Then AI connects the two.
That is a very different project from building everything from scratch.
The Most Important Step Comes Before Any of These
If this were my project, I still wouldn’t begin by calling software vendors and I wouldn’t begin by hiring a developer.
I’d start by watching the current operation.
The original analysis already identified the questions I’d want answered: how many requests arrive, how they arrive, how many are duplicates, how long triage takes, how contractors are selected, what requires approval, how much time staff spend chasing contractors, and how often residents follow up because they don’t know the status.
Because until you understand the current process, it’s difficult to know what you’re actually trying to improve.
Measure the Current State
I’d want numbers for:
Volume
- How many maintenance communications arrive per day?
- Per property?
- Per category?
Channel
How many arrive by:
-
email
-
phone
-
portal
-
SMS
-
other channels
Duplicate Work
How many requests are actually multiple reports of the same incident?
Staff Effort
How much time is spent:
-
reading requests
-
categorizing them
-
forwarding them
-
finding contractors
-
creating work orders
-
following up
-
answering status questions
Contractor Performance
How quickly do contractors:
-
acknowledge work
-
accept jobs
-
arrive
-
resolve issues
Resident Communication
How often do residents contact the property manager again simply because they don’t know what is happening?
These numbers become the baseline.
Without them, you can’t measure whether the new system actually worked.
Calculate the Cost of the Problem
Suppose employees collectively spend six hours every working day doing maintenance coordination.
That’s:
30 hours per week
Over 50 working weeks:
1,500 hours per year
That was one of the most important conclusions from the original exercise. Once you know the current process consumes more than 1,500 staff hours annually, the software discussion changes.
Now suppose a better system removes half of that administrative work.
You’ve returned approximately:
750 hours per year
to the organization.
That might mean:
-
fewer employees required to support portfolio growth
-
faster resident responses
-
less overtime
-
better contractor follow-up
-
fewer missed requests
-
more time for higher-value property-management work
Now we’re evaluating value, not just software cost.
Define What Success Looks Like
Before implementing anything, I would define measurable targets.
For example:
- Reduce manual triage time by 60%.
- Acknowledge 95% of digital maintenance requests within two minutes.
- Identify duplicate incidents automatically in at least 80% of applicable cases.
- Reduce resident status inquiries by 40%.
- Reduce average contractor acknowledgement time by 25%.
- Reduce average time from incoming request to approved dispatch.
Then you can evaluate:
Before
versus
After
That is much more useful than saying:
“We implemented AI.”
AI isn’t the outcome.
Operational improvement is.
Where AI Actually Belongs
One theme has remained consistent throughout this series.
I don’t think the best use of AI is necessarily making more decisions autonomously.
I think the better question is:
How much work can AI remove before a person has to make the decision?
In our hypothetical maintenance system, AI could:
-
read the request
-
understand the resident’s language
-
identify the property
-
classify the problem
-
estimate urgency
-
detect similar incidents
-
summarize multiple reports
-
recommend the contractor
-
draft communications
-
prepare the work request
The property manager then decides:
Approve.
The original article framed this as AI reducing work without removing control. The software handles the administrative maze while the human remains accountable for the consequential decision.
I still think that’s the right design principle.
So What Would I Recommend?
For the property manager who started this entire exercise, I would use this sequence.
1. Document the Current Workflow
Don’t start with software, understand the operation.
2. Measure the Cost
Calculate the time and money currently spent on maintenance administration.
3. Define the Required Workflow
What does the organization actually need? Not what could it possibly use. What does it need?
4. Demo the Commercial Products
Give every vendor the same real scenario, make them show the workflow.
5. Calculate Three-Year Total Cost
Include:
-
licensing
-
implementation
-
training
-
consulting
-
integration
-
support
-
internal staff time
6. Estimate the Custom Alternative
Include everything, not just development.
7. Consider Integration
Ask whether the organization can preserve what already works and only build the missing layer.
8. Choose the Lowest-Risk Solution That Solves the Actual Problem
Not the most impressive software, not the most advanced AI, not the architecture with the most diagrams.
The solution that removes the operational pain at an acceptable cost and risk.
My Decision Framework
If I had to reduce the entire series to three statements, they would be these:
Buy
If you need most of what the commercial platform offers, buy it.
You’re paying for mature functionality and transferring product responsibility to the vendor.
Build
If the problem is narrow, well understood, expensive and poorly served by existing products, custom development may make sense.
Especially when portfolio scale makes recurring SaaS fees significant.
Integrate
If most of your existing systems already work, don’t replace them just to solve one workflow problem.
Build or buy the missing layer and connect the pieces.
Final Thought
I started this series asking how AI could deal with maintenance emails.
Six parts later, I think that was the least interesting question.
AI can read an email.
That’s easy.
The interesting challenge is understanding the operating system around that email.
- Who should act?
- What requires approval?
- Which contractor should receive the work?
- Who needs to know?
- What happens if nobody responds?
- How do you prevent 20 reports of one elevator outage from becoming 20 separate jobs?
- How do you measure whether the new process is actually better?
That’s where AI becomes useful. Not as a replacement for the people running the operation.
As infrastructure that removes repetitive administrative work and gives those people better information at the point where their judgement actually matters.
And that is ultimately the approach I would take:
- Automate the work around the decision.
- Keep people responsible for the decision itself.
💡 One final thought: Everything in this series represents work an organization could absolutely do internally. But if a property-management company asked me to come in, map its current maintenance operation, evaluate the available software, design the custom alternative, model the costs and provide a build, buy or integrate recommendation, I would expect an engagement of this scope to cost roughly $10,000–$15,000 CAD, depending on the number of properties, stakeholders and systems involved.
Resources: Visit PropertyMCL.com to learn more about Property Maintenance Control.
About The Author
