Resident support AI chatbot for property and estate management

Most property management companies arrive at this with the same sentence: the phone does not stop. Service charge questions, a lift out of service, heating in block C, a booking for the function room, and the same three questions about visitor parking every week. A chatbot on the resident portal looks like the obvious answer.

It usually is not, and the reason has nothing to do with the model. Residents rarely want an answer. They want something recorded: a fault logged, a balance confirmed, a booking held, a complaint on file. A tool that produces good sentences and no records makes the operation worse, because now there is a conversation nobody can find.

This article covers what residents actually ask, which of those an assistant can close on its own, where it has to stop and hand the job to a field system, how the identity problem works when owners and tenants are different people, and what data a build like this cannot start without.

What residents actually ask

Before designing anything, take a month of your own inbound traffic and sort it. The phone log, the WhatsApp group, the portal, the caretaker’s notebook. Nearly every portfolio produces the same shape: a small number of request types carrying most of the volume, and a long tail that is genuinely varied and genuinely human.

What the resident asks	Can the assistant close it	What has to be produced
Current service charge balance or arrears	Yes, if the ledger is readable	A read from the accounting record, with the unit and the asker's authority verified
I paid, it is not showing on my account	Partly	A flagged item for the finance desk, never a reassurance
Fault report: lift, water, heating, lighting, door	Intake yes, resolution no	A work order with location, category, description, photograph and access constraints
Facility booking: function room, gym, guest parking	Yes, if a calendar with rules exists	A reservation record the manager can see and cancel
What did the last notice say, when is the meeting	Yes	A read from the announcement archive, with no new content invented
Access fob, plate registration, visitor pass	Intake yes, provisioning no	A request record routed to whoever holds the access system
Neighbour complaint: noise, parking, damage	No	A logged complaint and a person, immediately
Emergency: gas, smoke, flood, trapped in a lift	No	Emergency number shown, conversation ended, escalation logged
Contract terms, legal question, board decision	No	Handover with the question preserved word for word

Read the third column rather than the second. Almost every row the assistant can close is a row whose output is a record, not a sentence. That is the entire design problem, and it is why general chatbots underperform in this sector while looking fine in a demo.

An answer is not the deliverable

A general purpose chatbot is built to end the conversation. In building operations, ending the conversation is usually the failure. If a resident writes at nine in the evening that the lift is stuck between floors and receives a polite, accurate, well written reply about how lift faults are handled, nothing has happened. Nobody has been assigned. No clock is running. In the morning the manager has no idea the report exists.

The same request handled as intake produces a very different artefact: a work order with a building, a block, a category, a description, a photograph and a priority, sitting in a queue with an owner. The resident gets a reference number rather than an explanation. That reference number is worth more to them than the explanation, because it is the only thing they can quote when they follow up.

This is also why the routing question is about answer type rather than channel, the same argument set out in AI chatbot vs live support. The channel a resident uses tells you nothing about whether a machine can handle the request. What the request has to produce tells you everything.

From “the lift is stuck” to a work order

A usable fault record is not a paragraph of free text. It has a fixed set of fields, and the assistant’s job is to complete them through questions rather than to diagnose anything.

Location. Building, block, floor, and whether it is a private unit or a common area. This single field decides who pays and who is allowed to authorise the repair, so it can never be left implied.

Category. Mechanical, electrical, plumbing, heating, lift, access, cleaning. Good enough to route. Precision here is not the goal, because a dispatcher can change it in a second and often will.

Description in the resident’s own words. Stored unedited. Summaries lose the detail that turns out to matter.

Evidence. A photograph where a photograph is possible. Residents will send one if asked at the right moment, and almost never if asked later.

Access. Whether someone will be home, and when. This is the field that most often decides whether the first visit is wasted, and it is the field paper processes lose most reliably.

Urgency, stated and assessed. What the resident says, and what the category implies. Where the two disagree, the higher of the two wins and a person reviews it.

The assistant stops the moment that record is complete. Everything after it belongs to a different system: assignment, routing, the SLA clock, the technician’s mobile screen, the evidence photographs taken on site, the closing record and the resident notification. That is field service work, not conversation work. If you do not have a system for it, the assistant will produce very tidy reports that arrive in a mailbox and get lost, which is a more expensive version of the problem you started with.

Who is writing, and from which unit

This is the part that decides whether the project is safe, and it is the part most proposals skip.

Requests fall into three authority levels, and they need to be separated before any conversation flow is drawn.

Public. Notices, house rules, opening hours, emergency numbers, refuse collection days. No identity required, and no risk in getting it wrong beyond an inaccurate answer.

Unit linked. A fault in my flat, a booking, an access request. The assistant needs to know which unit, and needs to know that this person is attached to it.

Financial and personal. Balance, payment history, arrears, anything about another resident. Requires verified identity plus an authority check, and those are two different things.

The most common mistake we see is treating a phone number as identity. A number matched against the resident register is a reasonable first factor. It is not sufficient on its own for a financial read, because numbers get reused, tenants move, family members write from the account holder’s phone, and a landlord and a tenant are not the same person with the same rights over the same flat.

That last point deserves its own line. In a mixed portfolio, the person living in the property is frequently not the person who owes the service charge. A tenant may legitimately report a fault in a common area and have no right to see arrears. An owner living abroad may have every right to the balance and none of the day to day questions. Write the authority table first: owner, tenant, family member on the account, board member, agency staff, and for each of them which requests they may make and which data they may see. Anything not on that table defaults to refusal, and refusal means handover to a person.

The read, draft, write boundary underneath this is the same one that governs any enterprise AI assistant. Property management simply makes the consequences of getting it wrong easier to see, because the wrong answer is somebody’s financial position shown to their neighbour.

Language and hours, honestly

Two operational realities push property managers towards this before anything else does.

Mixed language residents. In many portfolios residents write in several languages while the operations team works in one. Handling that in the conversation is straightforward. The decision that matters is what language the record is stored in. Keep one working language for work orders so the dispatch queue stays readable, and attach the resident’s original message unchanged. Do not translate and discard. In any dispute, what the resident actually wrote is the evidence.

Out of hours load. Most faults are noticed in the evening and at weekends. Today they either reach a phone nobody answers, or they wait until morning and are then reported verbally with half the detail already gone. An intake channel that works at eleven at night does not repair the lift any faster. It means the morning starts with complete records instead of a queue of callbacks, and that difference is where the real operational gain sits.

Neither of these is a reason to automate decisions. Both are reasons to automate intake.

The exception queue

Every design of this kind needs a written list of situations where the assistant stops and a person takes over. Five triggers cover almost everything.

1. Emergency wording. Gas, smoke, fire, flood, injury, trapped. The assistant does not attempt to help. It shows the emergency number, ends the exchange, and raises an escalation that somebody is required to acknowledge.
2. Money in dispute. Any variant of “I paid and it is not showing”. Never reassure, never argue, never promise a correction. Log it with what the resident says and route it to finance.
3. Anything involving another resident. Noise, parking, damage, behaviour. These carry legal and social weight that no automated reply should touch.
4. Low confidence or a second failed attempt. After two unsuccessful tries at understanding the same request, hand over with the full transcript rather than trying a third time.
5. The resident asks for a person. Granted immediately, with no negotiation and no survey first.

A handover has to carry the transcript, the identified unit, what was already established and what could not be. A handover that arrives as “resident needs assistance” is not a handover, it is a second intake job for a member of staff.

Where the gain is actually measured

Almost every proposal leads with call volume. It is the wrong headline number for two reasons: it moves slowly, and it is easy to fake by making the phone number harder to find.

Four measures tell you whether this worked.

Record completeness. Of last month’s fault reports, how many arrived with location, category, priority and a photograph? Measure this before you build anything, because it is the number that moves first and moves most.

Intake latency. Time from the resident noticing a problem to a record existing in a system. Not resolution time, which belongs to the field operation.

Share of requests with no record at all. The corridor conversation, the message to the caretaker’s personal phone, the note left at reception. This is the genuine leak in most operations, and it is the one an intake channel closes.

Repeat contacts on the same issue. A resident asking again is usually a record they cannot see the status of, not a resident being difficult.

Resolution time and resident satisfaction belong to the field operation, not the assistant. Claiming the assistant improved them confuses two systems, and it will be challenged the first time someone looks closely.

What you cannot start without

Four items. If any one of them is missing, the project ends as a chatbot that answers questions about bin collection days.

1. A current unit register. Building, block, unit, owner, tenant, contact numbers, and which party is the payer. If this lives in three spreadsheets that disagree with each other, that is not a preliminary task, it is the foundation. Expect it to be worse than believed, because the assistant will be the first system that reads every row of it inside a month.
2. Somewhere for a work order to go. A field system, or at minimum a structured queue with statuses and an owner. Not a mailbox.
3. A readable financial position per unit. If a person has to open a spreadsheet and interpret it to state a balance, the assistant cannot state it either.
4. A named owner of the exception queue. One person and one deputy. Not a rota, and not “the office”.

Delays in projects like this are concentrated almost entirely in item one.

When not to build one

A small portfolio where the manager knows every resident by name. A person is cheaper, faster and better at this scale, and residents notice the downgrade.

No field system and no intention of adopting one. Better intake with nowhere to put it produces frustration on both sides.

When the real problem is collections. A chatbot does not collect debts. Scheduled reminders and a working payment page do, and they are a different project.

When the goal is to cut headcount immediately. Volume moves from the phone to a queue. The queue still needs a person, certainly for the first months and probably permanently.

A realistic first release

Start with one portfolio and three request types: fault report, service charge balance, facility booking. That combination exercises every hard part of the design, because it requires a record with a work order behind it, an authority check on financial data, and a calendar with rules. Everything else you might add later is a variation on one of those three.

Run it alongside the phone rather than instead of it. What you are looking for in that first period is not usage volume. It is whether records created through the assistant are as complete as records created by your best member of staff. If they are, widen the scope. If they are not, the gap points directly at the question missing from the flow, which is a cheap thing to learn.

Next step

If you are weighing this up, the useful thing to send is not a feature list. Send a month of inbound requests sorted by type, tell us where your work orders live today or that they have nowhere to live yet, and describe how your unit register is held. Our approach to the work order side is set out on the field service page, and the authority and grounding questions behind any assistant of this kind are covered in what an enterprise digital assistant is. Send those three things through the quote form and we will tell you which request types are worth automating in a first release and which ones should stay with a person.

Frequently asked questions

Will residents actually use a chatbot instead of calling?

Some will, some never will, and the split follows the request type rather than age. Anything a resident wants recorded (a fault, a booking, a balance check) moves to a written channel readily, because they want proof it was logged. Anything urgent or emotional stays on the phone, and should. Plan for both permanently. The realistic outcome is that written intake takes the routine volume while the phone keeps the exceptions, which is the split you want anyway.

Can it show a resident their service charge balance?

Only if two things are true. The balance has to be readable from a system rather than assembled by hand in a spreadsheet, and you need an authority rule that says who may see it. Owner and tenant are not interchangeable here: the person living in the flat is often not the person who owes the charge. Once both exist, a balance read is one of the safest things to automate, because it is a read with no write and no judgement. Without them it is a data protection problem waiting to happen.

What happens when it misunderstands a fault report?

The record is still created, which is the point. A misclassified fault (heating logged as plumbing) costs a reassignment, and reassignment is a normal part of any dispatch operation. What must never happen is a fault that gets a confident reply and no record, because that is invisible until the resident calls back angry. Design the flow so the record is written first and the classification is a field a dispatcher can change. Misrouting is cheap. Silence is not.

Do we need a field service system before we start?

You need somewhere structured for a work order to land, with an owner and a status. A full field service system is the version that pays off, because it carries assignment, the SLA clock, the technician's mobile screen and the closing evidence. A shared ticket queue can carry a first release while you decide. What does not work is sending the assistant's output to a mailbox. A mailbox has no status, no assignee and no way to tell you what is still open at the end of the week.

How many languages can it handle?

As many as your residents write in, because reading a message in another language is the least difficult part of this. The operational decision is what language the record is stored in. Keep one working language for work orders and reports so dispatchers and technicians read a consistent queue, and attach the resident's original message to the record unchanged. The original matters later: in a dispute, what the resident actually wrote is the evidence, and a translated paraphrase is not.

Related guides

• RAG chatbot over internal documents: what it costs and when it works
• Gulf e-invoicing: what ZATCA and the UAE mandate actually require from your systems
• ERP customer portal vs dealer portal: which one your network needs

Service page: AI process automation