Why property work gives AI something to build on

At a change of tenancy, a flat’s history becomes practical again. The previous inspection, any work ordered after it and the record of what was completed can all matter to the person preparing it for someone new. A detail that seemed minor when it was recorded may now be a reason to look more closely at a particular room.

The work has a recognisable shape, too. In a simplified letting process, notice arrives, an initial inspection is booked and repairs are assessed. There may be work to arrange before the final inspection and move-in. The sequence varies between businesses, but the person responsible can describe much of it: what starts the process, who needs to do something and what the next person needs to know.

The process is familiar enough to describe, and its failures are familiar enough to recognise. A property manager can spot a handover that leaves out an unresolved repair without knowing how the software behind it works. That knowledge becomes useful when deciding what to ask a tool to do and whether its answer is any good.

Our view is that property offers an unusually promising combination of recurring work and things that stay in place long enough for their history to matter. We know that work can be complicated. What interests us is how much of it already has a shape that an operator understands, and how a small improvement can remain useful when the task comes round again.

Describing what happens next

An inspection booking needs a time and somebody responsible for it. If it changes, the right people need to know. Ordinary software can handle that part through a calendar, rules and reminders. It would be a peculiar use of a language model to ask it to keep rediscovering a sequence the business has already agreed.

The less orderly part is what arrives along the way. In our example, an inspector might put several repairs into one paragraph. A contractor replies that some can be finished before move-in, while another needs a part. Before anyone can act, somebody has to work out what remains open and what the reply means for the next step.

A language model could help prepare an action list from the note, suggest which items the reply concerns and draft a message for review. The process around it can remain quite definite: a person checks the proposed list against the original, decides what to commission and approves anything sent out. A model’s interpretation has a specific place in the work, with somebody able to examine it before it carries consequences.

This is a practical reason to distinguish automation from AI. Fixed steps can follow rules; language models can help with material that needs interpreting. Anthropic makes a related distinction in its engineering account of workflows and agents, separating predefined paths from systems in which the model chooses more of its own route. That is experience from a supplier building the technology, not a measurement of what a property company will save by using it.

Writing down the workflow also forces some decisions that software cannot make on the business’s behalf. A job marked complete may have been commissioned, carried out or checked. Those events have different consequences for the person waiting to move the letting forward. Someone has to decide which one the status means and what is required before it can be used.

For a first attempt, we would rather give AI a small part in a process we can explain than ask it to organise a process we have not yet understood. Preparing a list for somebody to check is a useful place to learn. Deciding independently that a flat is ready for its next tenant is a much larger responsibility.

The same flat, with different things to know

The letting process has something else in its favour: much of the information refers to a place that will be needed again. The inspection describes the flat at one moment. A work order describes what should happen there. An invoice records a charge. Each serves its own purpose, yet a later question may require reading them together.

The flat gives them a common reference. If the connection is kept, the next person can follow what was observed into what was ordered and then examine the record of the result. If it is lost, they have to reconstruct that relationship before they can judge what remains to be done.

The same reasoning applies to equipment. Two ventilation installations may share a type and still have different ages, service requirements and condition. A common description helps organise what is known about that kind of installation. Each actual installation needs its own history. Reusing the description should leave room for the differences that determine what happens on site.

That makes it possible to improve one part without starting from nothing in the next. A way of recording a service visit can be reused for another visit, while the findings stay with the equipment they concern. A clearer inspection requirement can be carried into the next order. There is enough repetition to make the work worth organising, and enough variation that the person who knows the building still has a job to do.

For an AI assistant answering a question about the last service, this organisation becomes a condition of a dependable answer. It needs the right installation and the relevant source. If two different units have been recorded under the same name, the operator has an information problem to resolve before trusting a fluent reply about either of them.

In the RICS 2026 survey of AI in commercial property and construction, data quality and availability, alongside integration with existing systems, feature prominently among the barriers reported by commercial property respondents. The survey records their accounts and assessments. It does not measure the return a particular business has earned from AI.

A suitable kind of work can still come with difficult starting material. Attempting to make that material usable may reveal gaps that a person has been quietly bridging for years. The exercise then includes deciding which of those gaps can be resolved from the records and which require somebody to go and look.

What we could build on

Runs in our operation: we used an AI assistant to help prepare information from our property documents for entry into our system. It proposed entries mapped to our structure, with source references and lists of gaps and conflicts. We reviewed the proposals ourselves. An old inspection could tell us what had been recorded at the time; its age and wording still mattered when deciding what to enter as the current condition.

That work connected quite naturally to maintenance planning. In our system, an installation year and an assumed service life produce a suggested intervention year. We decide the action, timing and cost. The calculation is ordinary arithmetic, and a suggestion based on age still needs judgement about condition. There is no AI in that calculation inspecting the component or predicting when it will fail.

AI had helped with a different part: preparing the information that could make the calculation useful. A reviewed installation date could feed a maintenance suggestion. A missing date could become a reason for an inspection round. The gaps had somewhere to go, which meant we could keep working without filling them with plausible guesses.

For us, data and workflows became a backbone to build on. Components gave information a place. Controls and work orders described what needed doing in the property, and supporting evidence could follow the work performed. The wider workspace we are developing, with a shared inbox and further kinds of tasks, is still under way. We continue to build, test and introduce improvements in our operation; the existing system gives that work a starting point.

It also gave us a more precise sense of what an improvement should do. A new function could use something already known about the property. It could help move an existing task forward or leave better information for whoever came next. Those connections were a reason to keep building, even though the work of making them reliable involved database design, tests and rebuilding parts we had thought were settled.

Beginning with a piece of the work

Someone who wants to try AI in property work can begin before the whole system is clear. A written account of one recurring task is enough to start examining what could be improved. The result may be a better use of existing software, a simple automation or a small tool worth building separately.

In the letting example, a first trial could involve an anonymised inspection record and a proposed action list. The person reviewing it would need to check whether the observations survived, whether they belonged to the right location and whether recommendations had been kept separate from completed work. That provides something specific to learn from. Correcting the output and checking it against the source are part of the work the trial has to justify.

Trying that does not require becoming a developer. Connecting a tool to live records, permissions and outgoing messages brings further responsibilities, including somebody able to test it, recover from errors and maintain it. The useful freedom is being able to begin with a task small enough to understand, then decide how far it is sensible to take it.

A person who has spent years managing lettings already knows a great deal about what a working handover requires. Writing it down makes that knowledge available for examination. It can expose an assumption, help a colleague understand a decision or give an AI assistant a clearer job. Even if the first tool is discarded, the account of the work can be improved and used again.

At the next change of tenancy, the tool will need to reflect any changes in how the business works. Somebody has to keep it current. They will also need to know why a step exists: what it is meant to establish and what another person is relying on when it is marked complete. Keeping that reasoning alongside the workflow gives the colleague who eventually takes it over something to work from, too.