Reading Time: 8 minutes

In the previous part of this series, I looked at five existing platforms that could help solve the property-maintenance problem: Property Meld, Entrata, AppFolio, Building Engines and Zendesk.

There are good reasons to buy rather than build.

But let’s suppose the property manager already has systems for leases, accounting, resident records, rent collection and financial reporting.

Let’s also suppose they already have relationships with plumbers, electricians, elevator companies, landscapers and other contractors.

Their problem is narrower:

Maintenance requests arrive from everywhere, employees spend too much time understanding and routing them, communication is inconsistent, and contractor coordination requires too much manual effort.

If that were the problem, I wouldn’t build another property-management platform. I wouldn’t try to recreate AppFolio. I wouldn’t try to recreate Property Meld. I would build something much smaller.

I would build the maintenance coordination layer.

Its job would be simple to describe:

Take maintenance communications from residents, understand them, organize them, prepare the required actions and communications, and give property staff a controlled queue from which they can approve and manage the work.

Nothing more unless there were a strong business reason to add it.

And if I were designing that product, this is where I would start.

Step 1: Don’t Make Reporting Maintenance Difficult

There is a temptation when building software to create a portal for everything.

• Download our app.
• Create an account.
• Remember your password.
• Select your building.
• Choose a category.
• Choose a subcategory.
• Fill in seven mandatory fields.

That’s convenient for the database.

It isn’t necessarily convenient for the resident.

I live in a strata myself.

If something is wrong with in our strata, I email the strata-management company.

Once I’ve reported it, unless the problem directly affects me, I generally don’t think about it again.

That behaviour matters.

So I would start with the communication channels residents already understand.

Email

Every property could have its own maintenance address:

• maintenance-mainstreet@propertycompany.com
• maintenance-oakstreet@propertycompany.com
• maintenance-kingstreet@propertycompany.com

Or addresses could use a consistent structure such as:

mainstreet-maintenance@propertycompany.com

The particular naming convention isn’t important.

The principle is.

If each property has its own incoming address, the resident doesn’t even have to tell us which building they’re reporting.

The email address already tells the system.

We’ve removed one more piece of friction and one more opportunity for bad data.

Technically, this is quite achievable.

Modern email services can receive incoming email, extract the sender, recipient, subject, body and attachments, and deliver that information directly to an application through a webhook.

The application isn’t periodically logging into somebody’s Outlook inbox and looking for unread messages.

The email itself becomes an event that enters the maintenance system.

A Simple Web Page

Email wouldn’t be the only option.

I’d also provide a simple Report a Maintenance Problem page.

It might ask for:

• property

• unit number, where relevant

• location of the problem

• description

• contact information

• photographs or other attachments

• preferred method of contact

But I would resist the urge to make the form overly structured.

A resident shouldn’t have to decide whether this:

“There is water coming from the ceiling beside the elevators on P2.”

belongs under:

Building Services → Mechanical → Plumbing → Common Area Plumbing → Active Leak

That’s our problem.

Not theirs.

Let them describe what they see.

Let the system figure out the taxonomy.

That is where AI starts becoming genuinely useful.

Step 2: Turn Unstructured Messages Into Structured Data

Human beings communicate messily.

That’s fine.

Residents might write:

“There’s water everywhere downstairs.”

or:

“P2 elevator area has a huge puddle and I think something is dripping from above.”

or:

“Looks like there might be a pipe leaking beside the lifts.”

A traditional system has a problem with that.

A person has to read it and turn it into structured information.

An AI-enabled system can perform that first interpretation.

For example:

Property: 123 Main Street
Location: P2 elevator lobby
Category: Plumbing / Water leak
Priority: High
Potential safety issue: Yes
Suggested contractor type: Plumbing
Suggested contractor: ABC Plumbing
AI confidence: 94%

Now we have data the rest of the application can actually use.

The important distinction is that the AI isn’t inventing the property’s operating rules.

We’ve already told the system:

• which property received the message

• which contractors service that property

• what types of maintenance requests exist

• which categories normally require urgent attention

• which issues require immediate escalation

• which employees are responsible for which properties

The AI’s job is to interpret the resident’s language and map it into that framework.

That’s substantially different from asking a general-purpose chatbot:

“What should I do about this?”

Step 3: Use Confidence Rather Than Pretending AI Is Always Right

I would store a confidence value alongside important classifications.

For example:

Issue: Water leak
Confidence: 97%

Location: P2 elevator lobby
Confidence: 91%

Priority: High
Confidence: 88%

Why?

Because AI will sometimes misunderstand things.

If confidence is high and the consequences are low, the application can continue normally.

If confidence is poor, send the item to the review queue with:

Needs classification

Rather than pretending the software knows something it doesn’t.

This is another reason I wouldn’t design the system around maximum automation.

The goal isn’t to remove the property manager.

The goal is to stop making them manually process information the software can interpret reliably.

Step 4: Check for Duplicate Incidents

This may be one of the highest-value functions in the entire application.

Consider four residents sending these messages:

“Elevator 2 isn’t working.”

“The left elevator won’t come when I press the button.”

“We’ve been waiting ten minutes for the elevator.”

“Second elevator is broken again.”

To a basic ticketing system, those are four requests.

To a human who knows the building, they probably describe one problem.

An AI-enabled maintenance system should compare every new request against open incidents at the same property.

The system could consider:

• property

• location

• equipment involved

• issue category

• description

• time

• currently open incidents

• similarity to earlier reports

It might then say:

Possible duplicate

Incident #2874 — Elevator #2 Out of Service

Similarity: High

Now the property manager can confirm:

Merge with Incident #2874

One repair.

Four residents associated with it.

That distinction becomes extremely important at scale.

Imagine an elevator stops working at 7:45 on Monday morning.

By 8:15 20 residents have emailed.

There aren’t 20 maintenance problems.

There is:

1 maintenance incident

and

20 people who need communication.

Those are two separate workloads.

A good system should treat them that way.

Step 5: Preserve Every Resident Report

Merging duplicate reports should not mean throwing them away.  Every resident report could still be attached to the master incident.

That gives the property team useful information.

Perhaps one person writes:

“Elevator won’t move.”

Another says:

“Doors keep opening and closing.”

A third reports:

“Someone may be stuck inside.”

Those aren’t merely duplicates anymore.  The later message may materially change the severity of the incident.

So the system should maintain:

Master incident

plus:

Associated reports

The AI can continually re-evaluate the incident as new reports arrive.  If a new report introduces a potential safety issue, the system can escalate it.

That’s much more useful than simply saying:

Duplicate. Closed.

Step 6: Acknowledge the Resident Immediately

Some communication can safely happen before a human reviews the request.

For example:

Thanks for reporting the issue near the P2 elevators at 123 Main Street. We’ve logged your maintenance request and forwarded it to the property team for review. Your reference number is #2847.

Notice what the system does not say:

A plumber will arrive in 20 minutes.

It doesn’t promise that work has been approved, it doesn’t diagnose the problem, it doesn’t commit money.

It simply tells the resident:

We received your message.

We understood what you reported.

It’s in the system.

That acknowledgement matters.

One of the reasons residents send a second email or make a phone call is uncertainty.

Did anyone actually see my email?

An automatic acknowledgement closes that gap immediately.

And because the message is generated from structured information, it can be specific enough to be useful without making promises the organization hasn’t authorized.

Step 7: Build the Operational Queue

This is where everything starts coming together.

The property-management team shouldn’t spend its day searching Outlook.

It should have one queue.

Something like:

Priority	Property	Issue	Reports	Suggested Resource	Age
Critical	Main Street	Water leak, P2	6	ABC Plumbing	4 min
High	King Street	Elevator #2	17	Elevator contractor	12 min
Medium	Main Street	Dead tree	2	Landscaping	1 day
Low	Oak Street	Hallway light	1	Building staff	2 hrs

Now the property manager isn’t processing emails, they’re managing incidents.

That’s an important change.

Opening the first item might show:

AI Summary

• Six residents have reported water accumulating near the P2 elevator lobby since approximately 2:14 PM.
• Two reports mention water appearing to come from the ceiling.
• No matching open plumbing incident currently exists for this location.

Recommended Action

Priority: Critical

Recommended resource: ABC Plumbing

Reason: Approved emergency plumbing contractor for this property

The manager can then choose:

• Approve Dispatch

• Assign Internally

• Change Contractor

• Request More Information

• Hold

• Merge With Existing Incident

• Close

This is the point where I would deliberately draw the boundary around the AI.

AI can recommend.

A person authorizes.

Step 8: Everything Should Be Auditable

If the system is making recommendations, I want to know what happened.

Every incident should retain a timeline.

For example:

• 2:14 PM
  Resident email received.
• 2:14 PM
  AI classified issue as Plumbing / Active Leak.
• 2:14 PM
  Priority set to High.
• 2:15 PM
  Resident acknowledgement sent.
• 2:17 PM
  Second report matched to incident.
• 2:18 PM
  Third report received containing reference to water entering from ceiling.
• 2:18 PM
  Priority escalated from High to Critical.
• 2:19 PM
  Property manager notified.

That provides two things: 

1. Operational visibility.
2. And accountability.

If someone later asks (and someone always does):

“Why did the system treat this as urgent?”

you should be able to answer that question.

What Would the Application Actually Contain?

At a high level, our first version is already taking shape.

We would need:

Resident Intake

• Email receiver
• Web request form
• Photo/attachment handling

AI Processing

• Message interpretation
• Property/location extraction
• Category detection
• Urgency recommendation
• Potential safety detection
• Duplicate matching
• Summarization

Maintenance Data

• Properties
• Locations
• Maintenance categories
• Approved contractors
• Open incidents
• Associated resident reports
• Status history

Communications

• Resident acknowledgement
• Resident contact preferences
• Templates
• Email delivery

Staff Interface

• Maintenance queue
• Priority filtering
• Incident detail
• AI summary
• Recommendations
• Approval controls
• Audit history

That’s enough for a genuine first product.

Notice what’s missing?

• Accounting.
• Leases.
• Rent collection.
• Resident billing.
• General CRM.
• Property financials.
• Tenant screening.

We’re not trying to build another property-management suite.

We’re solving one specific operational problem.

How Does Email Actually Get Into the System?

This is one piece of the architecture that’s worth making concrete.  You don’t necessarily need to build and operate an email server.  Services such as Twilio SendGrid provide inbound email parsing.

An address or subdomain can receive an email, and the service can extract the message content, headers and attachments and send them directly to a web endpoint in your application.

Your application receives something conceptually like:

From: resident@example.com
To: mainstreet-maintenance@propertycompany.com
Subject: Water near elevator
Body: There’s water coming from the ceiling beside the elevators on P2.
Attachments: photo.jpg

The backend then creates the incoming report and sends the text into the AI-processing workflow.

That sort of service can also secure the connection between the email service and your application using mechanisms such as cryptographic webhook signatures or OAuth.

So the email component isn’t science fiction.

It’s infrastructure you can already buy.

What we’re building is the intelligence and workflow on top of it.

What Happens Next?

At this point, the system can:

Receive a resident request

↓

Understand what they’re reporting

↓

Convert it into structured data

↓

Check for an existing incident

↓

Acknowledge the resident

↓

Create or update a maintenance incident

↓

Present the issue to the property manager

Now we reach the next problem.  Suppose the system has correctly identified:

Critical water leak

and knows:

ABC Plumbing is the approved contractor for 123 Main Street.

What happens next?

• Should the AI email the plumber automatically?
• Should it send an SMS?
• Should it prepare a work order?
• What happens if the contractor doesn’t respond?
• What happens if they decline the job?
• How do the residents get updated?

And, most importantly:

At what point does a human approve the action?

That’s where we’ll go next.

In the next part, I’ll take the system from AI triage through human approval, contractor dispatch and resident communication.