Every software vendor in property has added the letters AI to a slide this year, and most buyers have stopped believing any of it. That is a reasonable reaction to the marketing, but it is an expensive reaction to the technology. In a real estate and construction business there are a handful of places where machine learning does something a rule cannot, does it repeatedly, and pays for itself inside a quarter. There are also places where it should be kept well away from a decision. Knowing the difference is most of the value.
What this class of technology is genuinely good at
Strip away the branding and the useful capabilities fall into three groups: ranking things so a human works the right one first, reading unstructured material so a human does not have to type it, and noticing a pattern early enough that a human can still act on it. Every worthwhile application below is one of those three. Anything that promises to make the decision itself deserves a longer conversation.
1. Ranking the enquiry queue
A sales executive with sixty open enquiries and six hours of calling time is making a prioritisation decision whether they realise it or not. Left alone, they call the most recent, the most pleasant, or the one whose name they remember. A model trained on your own closed-won and closed-lost history ranks that queue on the attributes that actually preceded bookings in your projects: source, budget band, configuration asked for, distance from site, response latency, how the first conversation went.
The gain is not that the model is clairvoyant. It is that the executive's first ten calls are now the best ten calls available, every single day. Two conditions have to hold for it to work: you need a couple of thousand historical enquiries with honest outcomes recorded, and the score has to be visible where the calling happens, not in a report someone opens on Friday.
2. Reading calls, emails and documents
Pre-sales teams lose an enormous amount of time to transcription — logging what was said, updating a disposition, re-typing a customer's requirement into a form. Speech and language models do this competently now. A call is transcribed, summarised into a few lines, tagged with the requirement and the objection, and the next action date is proposed. The executive corrects it in five seconds instead of writing it in ninety.
The same capability applies to documents. A vendor quotation arrives as a PDF; the line items, rates and delivery terms are extracted into the comparison sheet. A customer sends a PAN card image; the number and name are read and put in the right fields for verification. This is unglamorous and it is where most of the hours are.
3. Noticing a collection going wrong before it does
Receivables in real estate go bad slowly and then suddenly. By the time an account is in the 90-day bucket, the conversation is difficult and the options are poor. The signals that precede it are usually present much earlier and are individually unremarkable: a part payment instead of a full one, a cheque presented late, a customer who stopped opening the demand emails, a change in the pattern of contact.
A model that watches those signals across a portfolio can rank accounts by the probability of slipping next month, which turns the collections team from a chase function into a prevention function. The practical test of whether it is working is simple: has the age profile of your book improved, or have you just added a dashboard?
4. Forecasting a cost overrun while it is still cheap to fix
On the delivery side, the equivalent is cost to complete. Every project carries early indicators of an overrun — a cost head burning faster than progress, a vendor whose deliveries have started slipping, a sequence of small budget revisions in the same package. Individually a project manager may notice them. Across eleven packages and four projects, nobody does.
The value here comes from continuous recalculation rather than clever mathematics. A forecast that updates on every purchase order raised, every GRN posted and every measurement certified will tell you in week three what a monthly report tells you in week nine.
5. Reading the site from images
Progress capture is the other place where models earn their keep. Photographs and drone or 360-degree walkthrough footage can be compared against the model and the programme to estimate what has actually been built. It is not yet a substitute for a measurement engineer certifying an RA bill, and you should be suspicious of anyone who says it is. It is a very good early-warning layer between certifications, and it creates a dated visual record that settles disputes months later.
6. Answering questions about your own data
The newest and least mature category: asking a plain-language question and getting an answer drawn from your own transactions. “Which projects have receivables over ninety days above a crore?” “Show me every purchase order raised against the MEP head this quarter above the approved rate.” When it is wired to the actual ledger and it shows its working, this genuinely shortens the distance between a question and a decision. When it summarises without letting you click through to the underlying documents, treat the answer as a hypothesis and nothing more.
Where it should not be trusted yet
- Pricing a unit. Automated valuation is directionally useful and locally unreliable. A model does not know that the tower opposite got its approval last week.
- Approving anything. Discounts, budget revisions, payments — a model can rank and flag, but the approval must remain a named human with an audit trail.
- Statutory and legal output. RERA disclosures, agreements and tax filings are template-and-review work, not generation work.
- Safety-critical calls. A vision system can raise an alert. Deciding to stop work is a person's job.
The uncomfortable prerequisite
Every application above needs one thing that has nothing to do with AI: your operational data has to be in one place and it has to be honest. A lead-scoring model trained on a CRM where half the lost enquiries were never marked lost will confidently learn the wrong lesson. A cost forecast built on purchase orders raised outside the system is a forecast of a fictional project.
This is why the sequencing usually goes: get the transactions into a single system, insist that the system is where work actually happens, run it honestly for two or three quarters, and then switch on the models. Teams that do it in that order get results. Teams that buy the AI first get a demo.
How to start without a research budget
Pick one queue where somebody is currently guessing the order of work — the follow-up list, the collections worklist, the approvals inbox — and put a score on it. Measure one number before and after: enquiry-to-visit time, ninety-day receivables, days to approve. If it moves, extend it. If it does not, you have lost a fortnight instead of a year, and you have learned something specific about your data.
Written by the Teczen team. If you want to talk through how any of this applies to your projects, book a working session — no slides.