Enquiries that book themselves.
First response in under a minute, on every channel.
Rightmove · Zoopla · phone · email · WhatsApp. One property-viewing operations layer for a UK residential lettings and sales agency.
The world before
Speed to lead decides who wins
the viewing. This agency was losing on speed.
It’s 8:42 PM. Your office closed two hours ago, and a serious applicant just clicked “Email Agent” on your Rightmove listing. You won’t see it until
nine tomorrow morning. By then they’ve enquired on Zoopla about two more properties, left a voicemail on your office line, and WhatsApped the listing to a second agency: the one that answered. In UK residential lettings, the first agent to respond usually wins the booking, and if you run an agency, you already know how it feels to watch the diary depend on whoever checks the inbox first. Intuz, a real estate AI development company, mapped this full enquiry lifecycle, from the portal click to the morning-of confirmation call, before automating any of it. What we built is not a chatbot. It’s an operation layer that absorbs the whole lifecycle.
The operational reality
5 channels
Every enquiry arrived on one of five channels: Rightmove portal emails, Zoopla portal emails, the office phone, direct email replies, and WhatsApp. None of them converged anywhere. First response took hours. Every hour of silence handed the applicant, and the tenancy, to whichever competitor answered first. And every unfilled viewing slot stretches a void period the landlord is paying for.
Fragmented lead intake
Five channels, no unified ingestion. Messages were missed, duplicated, and inconsistently processed. The same applicant could email, call, and WhatsApp within an hour and be treated as three different people, or as nobody at all.
If your negotiators triage portal emails between viewings, this is you.
Slow first response
Manual triage meant hours, not minutes. In a speed-to-lead market, that gap is the whole game: by the time a lettings negotiator replied, a competitor had often already booked the viewing.
If your fastest reply still opens with an apology for the delay, this is you.
CRM data entry overhead
Expert Agent CRM has no public API. Every applicant record, every viewing booking, every duplicate check was entered by hand in a browser. This was the single largest source of manual workload in the office.
If someone on your team spends every afternoon retyping enquiries into the CRM, this is you.
Calendar coordination complexity
Property-specific availability, business hours, 10-minute slot increments, and zero tolerance for double-bookings. Manual coordination produced regular errors, and every calendar error is an applicant standing outside the wrong door.
If your diary rules live in one person’s head, this is you.
Follow-up and no-show leakage
Applicants who didn’t respond were rarely chased. Same-day no-shows were discovered only when the agent arrived at an empty property. The no-show rate wasn’t even measured, because nobody had the data to measure it.
If you learn about no-shows from a negotiator standing outside an empty property, this is you.
Before · After
The same enquiry, rebuilt.
Same Rightmove click. Same applicant. Same viewing. One column shows what the front desk
did before. The other shows what happens now, before anyone in the office has read the email.
Manual Triage
Check five inboxes. Ring back. Type into Expert Agent. Hope the diary is right. Chase nobody.
First response: hours, sometimes days
Automated Lifecycle
Enquiry ingested. AI replies. Slots matched. Staff approves. CRM updated. Viewing confirmed morning-of.
First response: under 60 seconds, any channel, any hour
Enquiries handled end-to-end by AI
Average first response
0
Double-bookings since go-live
The transformation
The same lettings office.
Two completely different days.
This is what changes at the metric level. The exact numbers a lettings director tracks every week:
response time, capture rate, diary errors, no-shows.
Operational Metric
First response time
Hours, sometimes days
Manual triage across five separate inboxes and a voicemail box
Competitor gets there firstUnder 1 minute
Average across email and phone · 24/7, including out-of-hours
First to respond, by defaultEnquiry capture across channels
Inconsistent
Rightmove, Zoopla, phone, email, WhatsApp · missed, duplicated, or dropped
Channel blind spots100% capture
Unified ingestion with cross-channel dedup · exactly-once handling
Zero channel blind spotsCRM data entry (Expert Agent)
All by hand
No public API · every applicant, duplicate check, and booking typed in a browser
Largest manual workloadAutomated write-back
Playwright logs in, checks duplicates, creates applicants, books viewings
Staff approve, scripts typeDiary integrity
Regular errors
Per-property rules and 10-minute increments coordinated by memory
Double-bookings happenedZero double-bookings
Central availability engine enforces every rule on every slot
Enforced, not hoped forNon-responder follow-up
Rarely chased
No system, no owner · warm applicants simply went cold
Pipeline leakageAutomated call-backs
Outbound Retell AI agent re-engages every non-responder
Every warm lead chasedNo-show discovery
At the property door
Negotiator travels, waits, and comes back with nothing
Audit is a fire drillMorning-of confirmation
Automated call + WhatsApp surfaces cancellations before anyone leaves the office
Cancellations caught earlyHours
To first response, in a market decided by minutes
<60 sec
First response · 60% less staff time on enquiry admin
Live replay · one evening enquiry
8:42 PM.
Watch what happens.
The office closed two hours ago. This is one enquiry, replayed step by step, exactly the way the system runs it every night.
Six minutes and forty-seven seconds, no staff on the thread until the approval tap.
Want to see this run against your enquiries?
Let’s Discuss Your WorkflowReal Estate AI Architecture
Five channels in.
One approved booking out.
This is a workflow system with AI components, not a chatbot with ambitions. AI where
language is the problem: voice conversations, availability parsing. Deterministic workflow
everywhere else. Humans at exactly two points: out-of-scope questions the AI flags, and
booking approval before anything touches the CRM. That decision shaped every box below.
Want to talk through how this could work for you?
Let’s TalkThe build
Five phases, sequenced around one risk.
The CRM automation layer was named the project’s largest technical risk on day one.
So the delivery plan was built to give it the most hardening time: foundations first,
workflows second, voice third, the risky part fourth, and a real pilot before anything went live.
01
Infrastructure foundation
AWS environment, a dedicated n8n instance, the Retell AI account, API credentials, and baseline integrations wired and verified. Nothing clever yet, deliberately. Every later phase assumes this layer never becomes the problem.
02
The n8n workflow layer
Email ingestion for Rightmove and Zoopla portal enquiries, reply handling, cron-based escalation, the shared availability engine, the booking-approval flow, the notification layer, and the wiring that lets workflows call the CRM scripts. This phase built the spine everything else hangs from, including the single availability workflow that every channel obeys.
03
The voice AI layer
Retell AI agents for inbound booking calls, outbound non-responder follow-up, and day-of confirmation, with ElevenLabs voice synthesis. Plus the piece nobody plans for until they hit it: a routing agent, so multiple outbound call types can share one phone number without applicants ever noticing a hand-off.
04
The CRM automation layer
Four Python + Playwright scripts against Expert Agent CRM: login and session management, applicant search, applicant creation, and viewing booking. Built as the project’s largest technical risk and treated accordingly: persistent sessions, retry logic, and screenshot-based debugging from the first commit, not bolted on after the first production failure.
05
Testing, pilot, go-live
End-to-end tests across every channel, edge-case runs against the calendar rules, load and security checks, monitoring, documentation, then a live pilot with real enquiries before full deployment. The system earned production; it wasn’t promoted to it.
The hard parts
Six problems that
never show up in a demo.
Anyone can wire a language model to a phone number. The engineering lives in the failure modes:
a CRM with no API, five channels that disagree with each other, and applicants who speak in weather forecasts, not calendar slots.
The CRM has no API. The CRM is also where everything must end up.
We built the API that Expert Agent never shipped. Four Playwright scripts with persistent session management, retry logic, and screenshot-based debugging operate the CRM through its own browser UI: searching applicants, checking duplicates, creating records, booking viewings. A synthetic API for a legacy system, hardened until it could run unattended in production.
4 production scripts, running unattended
Email leads and phone leads behave nothing alike. The calendar doesn’t care.
An email thread can wait an hour; a live caller cannot. So ingestion is split by channel, but every path converges into one shared availability workflow that enforces the same rules on the same live calendar. This convergence layer is the most technically significant component in the system: two ingestion behaviours, one source of truth.
One availability engine, every channel
“Maybe Tuesday afternoon, if it’s not raining” is not a calendar slot.
Natural-language availability goes through LLM extraction, structured-output validation, business-rule clamping, and a live calendar conflict check before any slot is offered. The AI never proposes a time that violates property rules, business hours, or the 10-minute grid. If it can’t extract a valid preference, it asks instead of guessing.
0 rule-breaking slots ever offered
One applicant. Three channels. Sixty minutes.
The same person emails, calls, and WhatsApps about the same flat within the hour. Thread-based matching, freshness filters, dedup logic, and status-based guards collapse those into one applicant, one state, one booking flow. Exactly-once processing, across every channel, no matter how enthusiastic the applicant.
Exactly-once handling across 5 channels
Humans in the right loop. Not every loop.
Staff are involved at exactly two points: out-of-scope questions the AI flags instead of improvising, and booking approval before any CRM write-back. Everything else, ingestion, replies, slot matching, follow-up calls, confirmations, runs unattended. That boundary is what makes 85% AI-handled trustworthy instead of reckless.
2 human touchpoints per enquiry lifecycle
If you can’t audit it, you can’t run it unattended.
Every reply sent, status change, call outcome, and CRM write is logged with timestamps into the state store. When a director asks “what happened with this applicant?”, the answer is a traceable record, not a memory. The audit trail is also the debugging tool: production issues replay from the log.
100% of system actions logged and timestamped
The Hardest Claim on
This Page, Shown
The weather stays the applicant’s problem. The 10-minute grid, business hours, and per-property rules are the engine’s.
If a valid preference can’t be extracted, the system asks instead of guessing, and no slot that breaks a rule is ever offered.
Want something built this reliably?
Let’s TalkEnd-to-end workflow
Enquiry in. Confirmed viewing out. Six steps.
The complete enquiry lifecycle, from the “Email Agent” click on Rightmove to the morning-of confirmation call.
Humans appear at exactly two of the six steps. Everything else runs on its own, 24/7.
week 1
Enquiry Arrives
Portal email, call, reply,
or WhatsApp. Ingested
24/7. Deduplicated
across channels.
Weeks 2–4
AI Engages
Voice agent answers.
Replies in under 60s.
Weeks 4–6
Availability Matched
GPT-4.1 parses “Tuesday
afternoon” into slots.
Rules + live calendar
checked. No conflicts.
Weeks 4–6
Staff Approves
Every booking reviewed
before the CRM write.
Out-of-scope questions
flagged to a human.
Weeks 10–12
CRM Updated
Playwright logs into
Expert Agent. Dupes
checked. Applicant +
viewing created.
Zero manual data entry
Ongoing
Viewing Confirmed
Morning-of call plus WhatsApp. Cancellations surfaced early. Non- responders re-called.
No-shows caught early
Real Estate AI Outcomes
Thirty days after go-live.
Measured on the office floor, not in a slide deck. Every number below is from the first 30 days of production, across live enquiries from Rightmove, Zoopla, phone, email, and WhatsApp.
Of inbound enquiry calls handled end-to-end by AI, with no human on the line. Details captured, availability checked, slots offered, booking proposed.
Reduction in staff time spent on enquiry admin. The hours that used to go into inbox triage and CRM typing now go into viewings and valuations.
Enquiry capture across Rightmove, Zoopla, phone, email, and WhatsApp. Zero channel blind spots. Nothing waits in an unwatched inbox.
Sub-minute first response
Average first response across email and phone is now under a minute. In a market where the first agent to respond usually wins the viewing, the agency is first to nearly every enquiry it receives, including the ones sent at 11 PM on a Sunday.
First to respond, by default
Zero double-bookings
Since go-live, the central availability engine has not allowed a single double-booking. Every offered slot honours per-property rules, business hours, and 10-minute increments, checked against the live calendar at the moment of offer, not at the moment of regret.
Diary integrity enforced by the engine
Same-day confirmation loop
Every viewing gets a morning-of confirmation call plus a WhatsApp message, automatically. Cancellations surface before the negotiator leaves the office, not at the property door. The no-show problem became a rebooking workflow.
Cancellations surfaced before travel
24/7 lead ingestion
Enquiries outside business hours are captured, acknowledged, and queued for action. The diary fills overnight. Out-of-hours applicants, previously the most-lost segment, now get the same sub-minute acknowledgment as everyone else.
Every after-hours enquiry acknowledged
A system of record
Every lead timestamped. Every conversation logged. Every booking auditable. The agency now has an enquiry pipeline it can inspect and improve, instead of a shared inbox it hoped was covered. This is the outcome the directors mention first.
Full audit trail per enquiry, per booking
Want your enquiry pipeline to run like this?
Book a Workflow AuditWhat the Client Said
We used to win or lose a tenant based on who picked up the phone first. Now the system has replied, offered slots, and proposed the booking before anyone in the office has even seen the enquiry. The diary just fills.
Director · UK Residential Lettings & Sales Agency
Five forks in the road,
and what we picked.
Every architecture is a series of trade-offs. Here are the five that shaped this one:
what we chose, what we left on the table, and the honest cost of each call.
Decision 01
Playwright browser automation
over waiting for a CRM API
Expert Agent CRM has no public API, and the agency wasn’t changing CRMs for us. Four Playwright scripts with persistent sessions, retry logic, and screenshot-based debugging gave the system a synthetic API for a legacy platform, reliable enough to run unattended in production.
Browser automation breaks when the CRM UI changes. Paid for with monitoring and fast selector fixes; bookings queue safely during any outage, so nothing is lost.
Decision 02
n8n orchestration
over custom Python services
The whole enquiry lifecycle lives on one visual surface that can be read, audited, and changed without a deploy. Ingestion, escalation crons, the availability engine, approval flows, notifications: all inspectable by anyone on the team. Custom code is reserved for the two places it earns its keep: the CRM scripts and the webhook handlers.
Complex branching in a visual tool gets awkward. We accepted a few dense code nodes over owning and maintaining a bespoke orchestrator forever.
Decision 03
Humans on booking approval
over full autonomy
A wrong record in the CRM costs more than a slightly slower booking. Every booking passes a staff approval gate before Playwright writes it to Expert Agent, and anything outside the AI’s scope is flagged to a human instead of improvised. Everything else runs unattended.
Minutes of human latency per booking. Accepted: the applicant already got a sub-minute response, and the CRM stays clean. Full autonomy is a dial we can turn later, with data.
Decision 04
Google Sheets as the state store
over Postgres
The people who operate this system are lettings negotiators, not DBAs. Lead state, conversation history, and booking status live in a store the staff can open, read, filter, and correct themselves. Zero database ops, zero schema migrations, total visibility, already inside the agency’s Google stack.
Sheets won’t survive heavy concurrent writes. Right at single-agency volume; the Postgres migration path exists and stays unspent until scale demands it.
Decision 05
Retell plus a routing agent
over multiple phone numbers
One number the local market already recognizes. Four conversational voice agents (inbound booking, non-responder follow-up, day-of confirmation, and a router) share a single line. The routing agent dispatches each outbound call type so every applicant sees the same agency number, and answers it.
A routing layer is one more agent to script, test, and monitor. Cheaper than number sprawl, and far cheaper than applicants screening calls from numbers they don’t know.
Have a Similar Use Case in Mind?
Let’s Build It.
Every automation we build starts with a single conversation.
Tell us what your team is doing manually today, and we will show you what an AI system could look like for your use case.
Is this you?
Where this pattern applies.
This wasn’t a proptech-only build. The patterns underneath it (channel convergence,
browser-automated CRM write-back, shared availability engines, human approval gates) translate
anywhere these five things are true. Count how many describe your operation.
High-volume, multi-channel inbound
Enquiries arrive by portal, phone, email, and WhatsApp, and response speed decides revenue. Speed to lead is your market’s physics, whether you sell tenancies, appointments, or quotes.
A CRM with no API, or a weak one
Staff spend hours typing into a browser because the system of record can’t be integrated the normal way. The synthetic-API pattern removes exactly this workload.
Non-trivial calendar logic
Per-resource rules, business hours, slot increments, and zero tolerance for double-bookings. A shared availability engine turns those rules from tribal knowledge into enforced constraints.
AI in the loop, not in control
You want the speed of automation without giving a language model unsupervised write access to your system of record. Approval gates make that a design choice, not a compromise.
Follow-up and confirmation leakage
Non-responders go cold because nobody owns the chase, and no-shows are discovered on site. Automated re-engagement and same-day confirmation loops close both leaks.
If two or more apply, this architecture maps onto your operation directly. The stack changes; the patterns don’t.
Ready to Replace Manual Work
with an AI-Powered Solution?
Book a free consultation with our AI experts to walk through your use case – what can be automated,
where manual overhead is slowing your team down, and what a purpose-built platform could look like
for your operation. Just like we did for CasePath.
Tools & technologies
Tools and Technologies We Used
Every tool in this stack was chosen for a specific reason – multi-tenant data isolation,
AI-driven document processing, and a cloud infrastructure built to handle sensitive child welfare data at scale.
