The loss that happens in the middle of the cycle
Property is a long-cycle business, and most of the systems built for it are tuned for the two ends: the moment a lead first calls, and the moment a deal is about to fall through. The middle — the many months a genuine buyer spends waiting for the right property, or the weeks a transaction spends crawling through searches and surveys — gets almost no attention, because nothing in it looks urgent on any given Tuesday.
That is exactly where deals go missing. A buyer registers today, is honest that they are not moving until next year, and gets one follow-up email before falling out of anyone's rotation. Later, when they are ready, they have either forgotten which agency they spoke to or found a property through someone who happened to still be in touch. A new instruction comes onto the books that matches several registered buyers exactly, and nobody notices until it has already gone under offer to someone who found it on the portal first. A transaction reaches exchange and then stalls because a surveyor's report is late and nobody chased it, while the buyer and seller both start to wonder if the deal is still happening. None of these are leads going cold through disinterest. They are cases of a person or a process losing track of a thread it was never given time to hold — and the fix is not more effort from an already stretched team, it is a system built to hold that thread the whole way through.
None of this requires judgement about a client, a price, or a legal position. It requires something to track a timeline, check a status, and act on schedule without forgetting. That is exactly the shape of work a custom AI agent can hold, and it is a different problem from the one a phone system is solving — which is why this sits alongside the other systems Calfy builds for real estate businesses, scoped specifically to the long middle of the cycle rather than the moment a call comes in.
What the agent does, day to day
A single agent, scoped to how your business actually works, typically covers a combination of the following. It does not value a property, does not advise a client, and does not decide who gets priority beyond the matching rules your team sets — it tracks, matches, chases, and assembles, and puts a finished picture in front of a person for the calls that are actually theirs to make. For the underlying mechanics of what makes this an agent rather than a script, see the AI agent glossary entry.
- Long-horizon lead nurture. Every registered buyer's stated timeline, budget, and requirements are logged, and re-engagement is timed against what they actually said — not a generic drip sequence that fires on the same schedule for someone six weeks out as for someone a year and a half out.
- Buyer-to-listing matching. Every new instruction is checked against every registered buyer's requirements the moment it goes live, and a genuine match gets a message before the listing has even finished its first day on the portals.
- Transaction milestone chasing. From offer accepted to completion, the agent tracks where a file sits against the solicitors, the broker, and the surveyor, and chases whoever is holding it up before a delay turns into a crisis.
- Listing preparation. The details a listing needs — measurements, EPC rating, title information, agent notes, photos — usually sit with different people. The agent pulls them together into a single draft ready for review.
- Lettings renewal tracking. Leases approaching their end get flagged with enough lead time to negotiate a renewal properly, instead of discovering a vacancy is coming a month before it starts.
- Maintenance triage. Incoming maintenance reports are logged, sorted by urgency, and routed to the right contractor or property manager, with the tenant kept informed along the way.
Walkthrough: the buyer who said eighteen months and got remembered anyway
A buyer registers with your agency after viewing one property that wasn't quite right. In the conversation, they mention they are not planning to move for at least a year and a half — they are waiting on a fixed-term tenancy to end. The agent logs that timeline against their profile rather than treating the call as a dead end, and sets a re-engagement schedule built around it: a light check-in partway through to confirm requirements haven't changed, a market update as their window approaches, and closer, more active contact as the date they gave you gets near.
At each touchpoint, the message reflects what has actually changed — a new instruction matching their brief, a shift in the local market, a direct question about whether their plans are still on track — rather than a repeat of the same generic newsletter. When the buyer's circumstances change and they mention it in a reply, the agent updates the profile and adjusts the schedule again. By the time they are seriously looking, well over a year after that first viewing, they are talking to an agent who already knows exactly what they want, because nothing about their file went quiet in between.
Walkthrough: matching a new instruction against buyers already waiting
A three-bedroom house with a garden and off-street parking comes onto the books. Before it is even live on the portals, the agent checks it against every buyer registered with matching requirements — bedrooms, budget range, location, and the specific must-haves each buyer gave at registration, such as parking or a particular school catchment. Several buyers come back as a strong match; a couple more are close but outside their stated budget, so they are held back rather than sent a listing they can't actually afford.
The matched buyers get a message the same day, ahead of the general portal push, with the listing details and a prompt to book a viewing against the agent's live calendar. Some respond and book within the hour. The agent logs who was contacted, who responded, and who didn't, so the listing agent can see at a glance which of their registered buyers have already seen it — instead of finding out weeks later that a buyer who'd been waiting for exactly this house never got told it existed.
Walkthrough: chasing a transaction across solicitors, brokers and surveyors
An offer is accepted on a property, and the agent opens a transaction file against a standard milestone template — memorandum of sale issued, searches ordered, mortgage offer received, survey booked, enquiries raised and answered, exchange, completion. Each milestone has an expected window, and the agent checks status against every party holding a piece of it: the buyer's solicitor, the seller's solicitor, the mortgage broker, and the surveyor.
When a milestone runs past its expected window — a survey booked but not yet returned, enquiries raised but not answered after the usual turnaround — the agent sends a status request to whoever is holding it up, in the tone and format that party expects, and logs the response. Most of these resolve with a simple reply. When one doesn't, after a defined number of follow-ups, the agent stops chasing quietly and flags the file to your team with the full timeline attached — what's been asked, of whom, and for how long — so the next call starts with the full picture instead of a guess at where things stand.
Listing prep: pulling one listing out of five places
Getting a property from instruction to a finished listing means assembling information that no single person or system holds in full. Measurements and floorplans might come from a previous listing or a site visit. The EPC rating and title details sit with a conveyancer or a public register. Photos come from a photographer's delivery. The agent's own notes on what makes the property stand out exist only in their head or a scribbled line in the CRM.
The agent pulls from each of these sources and assembles a first complete draft — description, headline features, and the supporting details a portal listing needs — ready for an agent to review, adjust in their own words, and publish, rather than starting from a blank page while five different files sit open in five different tabs.
On the lettings side: renewals and maintenance triage
Lettings runs on two clocks that are easy to lose track of across a portfolio: when a lease ends, and when something breaks. The agent tracks every lease against its renewal date and flags it early enough that a property manager can start the renewal conversation with real lead time, rather than realising a tenancy is ending a few weeks out and scrambling to avoid an empty unit.
Maintenance reports get the same discipline. An incoming request is logged, triaged by urgency, and routed to the right contractor or property manager, with the tenant given a clear next step instead of silence. A genuine emergency gets escalated immediately; a routine repair gets logged as a work order and queued for review. Nothing sits unclassified in a shared inbox while a tenant wonders if anyone has seen their message.
Not a phone system
It's worth being direct about what this page doesn't cover. Voice AI for real estate answers and makes calls — the moment-to-moment work of picking up when a buyer or tenant rings. This system does the opposite kind of work: it operates across your CRM, your portals, your conveyancing correspondence, and your inbox, holding a thread over weeks and months without ever touching a phone. Most agencies that run both find they solve different halves of the same operational load, but they're built and scoped as separate systems. If your actual bottleneck is simpler than tracking and chasing — reminders that just need to fire on schedule — workflow automation is often the lighter, cheaper fix, and we'll say so on the call rather than sell you more than the problem needs.
Matching and fair housing, built in
Anything that matches, ranks, or prioritises buyers or tenants carries a constraint that sits above every other design decision: the logic must not act on protected characteristics, whether that's deciding who hears about a new listing first, how a nurture sequence is paced, or how a maintenance request gets triaged. That isn't a setting adjusted after launch — it shapes what data the matching logic is allowed to use and what it's built to ignore, from the first version we design. General fair housing and anti-discrimination obligations apply to automated systems the same way they apply to a person doing the same job, and we design and test against that constraint before an agent goes near a live buyer list.
Where it connects into your systems
CRM. Buyer requirements, timelines, transaction status, and every nurture touch are read from and written back to the CRM your team already runs on — usually through an API, or a scheduled sync where the platform doesn't expose one cleanly.
Portals and listing feeds. New instructions are picked up from the same feed you already maintain for the major property portals, so matching runs the moment a listing goes live rather than after someone manually flags it.
Conveyancing and case management. Where solicitors, brokers, or your own case management platform expose a portal or a status API, the agent checks it directly. Where they don't — and plenty of conveyancing still runs on email — it works the way a coordinator would, reading status updates and sending requests in the format that party expects.
Calendars and email. Viewing offers, renewal conversations, and status requests go out through the inbox and calendar your team already uses, so nothing lands in an unfamiliar tool.
Data handling. Every agent gets the narrowest access that lets it do its job — read-only where reading is enough, scoped credentials rather than a shared login, and detailed audit logging so there's a clear answer to who touched a record and when.
Escalation. Every workflow has a defined edge — a transaction genuinely stuck rather than just slow, a buyer's circumstances that need a person's judgement, a maintenance report that isn't a clean triage call. When the agent reaches that edge, it stops and hands the case to a person with the full trail attached.