Reading Time: 8 minutes

In the previous part of this series, I designed the front half of a custom AI-powered maintenance system.

The system could:

• Receive requests by email or web form

• Understand what the resident is reporting

• Identify the property and location

• Categorize the issue

• Estimate urgency

• Check for duplicate incidents

• Acknowledge the resident

• Create or update a maintenance case

• Place that case into a review queue

At that point, the system has done a lot of work.

But it hasn’t actually authorized anything.

And that distinction matters.

If a resident reports water leaking near the elevators, I don’t necessarily want AI autonomously deciding to call a plumber, approve a service visit, incur a cost and commit the property manager to work.

• I want the AI to prepare the decision.
• Then I want a person to make it.

That is where the second half of the system begins.

Step 1: Give the Property Manager One Clear Decision

Imagine the property manager opens the maintenance queue and sees this:

CRITICAL PRIORITY

123 Main Street

Possible active water leak near the P2 elevator lobby.

Six residents have reported the issue in the last 12 minutes.

Two residents mention water appearing to come from the ceiling.

No matching open incident was found.

Recommended contractor: ABC Plumbing

Reason: Approved emergency plumbing contractor for this property

The system has already:

• Read the incoming messages

• Grouped the reports

• Identified the likely problem

• Assessed the urgency

• Checked for duplicates

• Looked up the approved contractor

• Summarized the incident

The property manager now has several choices:

• Approve Dispatch
• Assign Internally
• Change Contractor
• Request More Information
• Hold
• Merge With Existing Incident
• Close

This is the boundary I would deliberately create around AI.

AI recommends.

Humans authorize.

The value isn’t that AI eliminates the property manager.

The value is that the property manager may now spend ten seconds making a decision that previously required several minutes of reading, searching, forwarding and composing emails.

Multiply that by dozens of requests per day and the operational impact becomes significant.

Step 2: Let AI Draft the Contractor Communication

Once the property manager approves the action, the system already knows most of what the contractor needs.

There is no reason for the property manager to write another email from scratch.

The system could generate something like:

Subject: Urgent Service Request #2847: Water Leak, 123 Main Street

Multiple residents have reported water accumulating near the P2 elevator lobby at 123 Main Street.

Reports began at approximately 2:14 PM and indicate that water may be entering from the ceiling.

Please confirm whether you can attend and provide your estimated arrival time.

Work Order: #2847

The manager reviews it.

Clicks:

Approve & Send

And the message goes out.

That sounds like a small improvement.

Operationally, it isn’t.

The property manager still controls the decision.

But they are no longer responsible for manually assembling all the information required to communicate it.

The system already has:

• The property

• The location

• The issue

• The priority

• The incident number

• The preferred contractor

• The resident reports

• The relevant contact information

AI simply turns that structured information into a clean communication.

Step 3: Use Email or SMS Based on the Situation

I wouldn’t send every maintenance message through every possible channel.  That creates noise.

Email is useful when detail matters.

SMS is useful when attention matters.

For example:

Email

A normal contractor dispatch may include:

• address

• work-order number

• description

• photos

• access instructions

• contact details

• requested attendance window

Email is ideal for that.

SMS

An urgent alert could be much shorter:

Urgent work request #2847 at 123 Main Street. Possible active water leak on P2. Review: [secure link]

Or an internal escalation:

CRITICAL: Possible active water leak reported at 123 Main Street P2. Human review required.

The communication method should follow the urgency and purpose of the message.

Not everything needs an SMS.

And not everything should disappear into someone’s inbox.

Step 4: Don’t Force Contractors Into Another App

This is one design decision I feel strongly about.

Contractors already have their own systems:

• The plumber has a dispatch process.
• The elevator company has service software.
• The landscaper has scheduling tools.

The last thing I would want to do is tell every contractor:

Download our app, create another account and remember another password.

Instead, send them an email or SMS containing a secure link tied to that specific work request.

The contractor clicks the link and sees something like:

Work Order #2847

123 Main Street

Possible active water leak near P2 elevators.

Can you attend?

Accept

Unable to Attend

If they accept:

Estimated arrival

• • 2:30 PM

  • 3:00 PM

  • 4:00 PM

  • Other

The response goes directly back into the maintenance system.  No app.  No account creation.  No password reset six months later.

The contractor interacts with the system only as much as necessary to complete the work.

That reduces friction on both sides.

Step 5: Track the Contractor Response

Once the contractor responds, the maintenance case changes automatically.

Suppose ABC Plumbing selects:

Accepted

ETA: 3:00 PM

The incident now records:

Status: Contractor assigned

Contractor: ABC Plumbing

Accepted: 2:26 PM

Estimated arrival: 3:00 PM

The property manager doesn’t need to receive the contractor’s email, manually update a spreadsheet, forward the response to somebody else and then send another message to the resident.

The system already knows what happened.

That means it can trigger the next communication automatically.

Step 6: Keep Residents Informed Without Creating More Work

This is where the earlier duplicate-detection design becomes particularly valuable.

Suppose seventeen residents reported the broken elevator.  The maintenance department needs to arrange one repair.  But seventeen people may still want to know what’s happening.

Once the incident is centralized, communication can follow the status.

Contractor assigned

Your reported maintenance issue has been assigned to a contractor.

Contractor scheduled

A technician is expected to attend today between 3:00 PM and 5:00 PM.

Delay

The technician attending this issue has been delayed. The revised estimated arrival time is approximately 5:30 PM.

Resolved

Elevator #2 has been returned to service. Thank you for reporting the issue.

Now all seventeen residents associated with that incident can receive the same status update.

The maintenance department completes one repair.

The communication system closes seventeen loops.

That is a fundamentally different workflow from treating every resident email as an independent ticket.

Step 7: Escalate When the Contractor Doesn’t Respond

Automation becomes even more useful when something doesn’t happen.

Suppose the preferred plumbing contractor receives the request but hasn’t responded within ten minutes.

The system could flag:

NO CONTRACTOR RESPONSE

Then follow a predefined escalation path.

For example:

• 0 minutes: Send request to primary contractor
• 10 minutes: Send SMS reminder
• 15 minutes: Alert property manager
• 20 minutes: Recommend secondary approved contractor

The property manager could then approve the backup contractor.

This is the type of repetitive monitoring software is very good at.

No one has to remember:

Did ABC Plumbing ever reply to that email?

The system knows.

Step 8: Give Every Property Its Own Rules

The system shouldn’t have one global list of contractors.

Each property may operate differently.

For every building I would store information such as:

• approved plumber

• elevator contractor

• electrician

• landscaper

• janitorial company

• security provider

• superintendent

• emergency contacts

• after-hours contacts

• preferred communication channel

• spending authorization limits

• escalation rules

• building-specific access instructions

Then the system can understand that:

Building A + elevator issue → Contractor X

while:

Building B + elevator issue → Contractor Y

The property manager shouldn’t have to search through old emails to remember who services which building.

The system should already know.

This also gives us a way to introduce spending controls.

For example:

• Routine work under $300: Manager approval required.
• Emergency work: Immediate human escalation.
• Work over $2,500: Senior manager approval required.

You are not taking humans out of the loop, and the exact rules would vary by organization.

The important part is that the workflow follows explicit business rules rather than relying entirely on the language model.

Step 9: Treat Safety Differently From Normal Maintenance

Not every issue belongs in the same automation workflow.

A dead shrub can wait.

Water pouring through a ceiling cannot.

I would create at least three broad categories.

Emergency / Life Safety

Examples might include:

• suspected fire

• major active water leak

• serious electrical hazard

• trapped elevator occupant

• suspected gas leak

These should immediately alert a human and trigger predefined emergency procedures.

Urgent

Examples might include:

• elevator unavailable

• significant plumbing problems

• building-access failures

• major landlord-responsible appliance failures

These move to the top of the queue.

Routine

Examples might include:

• lighting

• landscaping

• cosmetic damage

• minor repairs

These can follow the normal review workflow.

AI can help classify the request.

But I would not allow probabilistic AI classification to be the only safeguard around a potentially dangerous situation.

If someone writes:

“I smell gas.”

I don’t want a language model debating whether its confidence is 81% or 84%.

I want a predefined safety rule to take over.

That could mean:

• Immediate alert to designated property staff

• Prominent emergency status in the queue

• Predefined instructions

• Escalation if no one acknowledges the incident

This is where traditional rules and AI should work together.

AI is very good at interpreting messy language.

Rules are very good at saying:

If this condition exists, this must happen.

Use each where it is strongest.

Step 10: Keep a Complete Audit Trail

Every action should be recorded.

Imagine the timeline for our water-leak incident:

• 2:14 PM
  Resident report received.
• 2:14 PM
  AI classified issue as Plumbing / Active Leak.
• 2:14 PM
  Priority recommended as High.
• 2:15 PM
  Resident acknowledgement sent.
• 2:17 PM
  Second resident report linked to incident.
• 2:18 PM
  Third report mentions water coming from ceiling.
• 2:18 PM
  Priority escalated to Critical.
• 2:19 PM
  Property manager notified.
• 2:21 PM
  Manager approved dispatch to ABC Plumbing.
• 2:21 PM
  Contractor email and SMS sent.
• 2:26 PM
  ABC Plumbing accepted.
• 2:26 PM
  ETA recorded as 3:00 PM.
• 2:27 PM
  Six affected residents notified.
• 3:06 PM
  Contractor marked On Site.
• 4:12 PM
  Contractor marked Work Complete.
• 4:13 PM
  Residents notified of resolution.

Now if anyone asks:

What happened?

the answer isn’t buried across an Outlook inbox, SMS messages and someone’s handwritten notes.

There is one history.

That becomes valuable for:

• Resident complaints

• Contractor performance

• Management reporting

• Insurance questions

• Recurring equipment problems

• Service-level monitoring

Step 11: Measure the Operation

Once everything passes through the system, the organization starts accumulating operational data.

Now it can measure:

• Maintenance requests by building

• Requests by category

• Requests by time of day

• Duplicate reports

• Acknowledgement time

• Manager approval time

• Contractor acceptance time

• Contractor arrival time

• Resolution time

• Reopened requests

• Reesident satisfaction

• Contractor acceptance rates

• AI classification accuracy

• Number of AI recommendations changed by employees

That creates a second use for AI.

The first use was:

What does this resident’s email mean?

The second becomes:

What is happening across my properties?

For example:

Elevator #2 at Building A generated 48 resident reports over the last six months.

Or:

Plumbing Contractor A takes an average of 12 minutes to acknowledge urgent work. Contractor B takes 47 minutes.

Or:

Building C generates three times as many after-hours maintenance incidents as comparable properties.

Now we’re moving from automation into operational intelligence.

And that’s where this relatively narrow maintenance system starts becoming strategically useful.

What Have We Actually Built?

At this point, our proposed system can handle the entire operational loop:

Resident sends request

↓

AI understands and categorizes it

↓

Duplicate incidents are identified

↓

Resident is acknowledged

↓

Maintenance case enters review queue

↓

AI recommends action and contractor

↓

Human approves

↓

Contractor receives email/SMS

↓

Contractor accepts and provides ETA

↓

Residents receive updates

↓

Work is completed

↓

Incident closes

↓

Performance data is retained

That’s a real product.  Not a chatbot.  Not an AI demo.  Not another button labelled Ask AI.

It’s an operational system in which AI removes administrative effort while people retain control over consequential decisions.

And Now We Have to Ask the Uncomfortable Question

We’ve designed something that could be built.

But should it be?

That’s where the economics matter.

Property Meld already offers substantial maintenance functionality for a per-unit subscription.

Entrata, AppFolio, Building Engines and other commercial platforms have years of development behind them.

A custom application means paying for:

• discovery

• consulting

• workflow design

• development

• testing

• implementation

• training

• hosting

• AI usage

• email and SMS

• maintenance

• future enhancements

So the next question isn’t:

Can we build this?

Clearly, we can.

The question is:

Should we build it?

In the next part, I’ll compare the cost of building this system with buying an existing solution, including the consulting and implementation work that often gets left out of custom-development estimates.

That’s where the build-versus-buy decision gets much more interesting.

Resources: Visit PropertyMCL.com to learn more about Property Maintenance Control.