Enquiry systems for property sales and rentals

What a property enquiry has to establish

An enquiry becomes useful once a few facts exist: buy, rent, sell or let; which property, project or area; the budget, and whether it is self-funded, sanctioned in principle or waiting on another sale; the possession date; and, where the market works that way, whether another broker has already registered the caller.

Routing reads those answers plus a CRM lookup on the number or email: a listed sale to the agent holding the instruction, a rental to the leasing desk, a leak to management. Qualification and routing are the scope; valuing a property and advice on price, yield, loan eligibility, tax or title are out of scope, and a valuation request is booked for a valuer rather than answered.

Listing state and how callers refer to a listing

Listing state changes frequently: price reductions, under offer, booked, withdrawn, back on the market. Vocabulary differs by market, so recognised statuses come from your CRM rather than a standard list: under offer in the UK, booked or allotted on an Indian primary sale.

A scheduled index is stale for the listings being asked about, so status should be read from the system of record mid-conversation. Whether that is possible depends on the CRM: some expose a live lookup, some only a periodic export, some rate-limit reads below launch-day volume. Which applies, and the fallback it forces, is settled in the sprint.

Callers rarely use the identifier the system holds: they quote a portal reference, describe the three-bedroom with the corner balcony or name a project and tower, and one unit often exists as several records across feeds and branches. Resolution is scoped across references, address components, project and unit, with a disambiguation question where candidates tie.

Viewings, agent calendars and the access condition

Booking a viewing takes more than a free slot in the branch diary. It needs the agent holding the instruction or the keys, travel time from the previous appointment, and access somebody else controls: a tenanted property usually requires notice to the tenant, an occupied one depends on whether the owner accompanies viewings or has left keys with the branch, a vacant one on where the keys are, which may be a key safe or a concierge.

The access condition belongs in the scope as a property-level field, and scheduling is a constrained search across it, the calendar and viewing hours, as far as those APIs allow. Out of hours it also sets what may be offered: a vacant unit with keys at the branch can take a next-day slot, a tenanted one cannot. An unanswered enquiry does not queue, because the same portal page lists other agencies, so the requirement is to qualify, book where access allows and hand over by morning.

Duplicate leads, lead ownership and source attribution

One person may enquire about three listings, call back twice about one and submit a portal form, and which is new decides who owns the lead and which source is credited. Deduplication is keyed on person and property together, inside an agreed window: person from whatever the channel supplies, a number, an email or a portal proxy number identifying the portal rather than the caller, and property from the resolved listing. A lead matching on neither becomes an unassigned enquiry to merge.

Each write carries a key from its source, the call or a portal delivery id, recorded on our side before the CRM is called, because real estate CRMs rarely accept an idempotency key of their own. A redelivered webhook then matches that key and appends rather than creating a second lead, leaving owner and source untouched; whether the CRM can be read reliably enough for that check is scoped against its API.

The same resolution threads a portal form, a WhatsApp message and a walk-in onto that record.

Portals, feeds and which system is authoritative

Distribution usually runs outward from the CRM, directly or through an aggregator, each portal taking a feed on its own schedule and format. Where listings are instead created or edited in a portal back office, ordinary practice in some markets, the portal is the system of record for those fields, so which system is authoritative is established in the sprint before anything reads it. Leads return carrying the portal reference rather than your listing identifier, and feed lag means callers quote prices the portal still shows, so the answer comes from the authoritative system and names the portal as behind.

Disclosure, advice and what the enquiry record holds

Property advertising is regulated, and the rules reach into what the conversation may state. In India, a registered project's registration number belongs with promotional material, and agents themselves register under the applicable state rules; in some other markets, screening an enquiry on protected characteristics is prohibited and identity checks on buyers and sellers are separate obligations. Which disclosures your enquiries require, we scope with you rather than advise on as a legal matter.

Statements about approvals, possession dates and carpet area are claims about the property, so the system repeats only what the record holds. Qualification fields are kept to what the agency needs, and consent, retention and access rules are decided explicitly.

Evaluating against the enquiries that actually arrive

The evaluation set comes from the agency's own recordings and enquiry logs and has to hold the cases that cost something: a listing withdrawn that morning, a caller another broker has already registered, a portal lead with a masked number, and a CRM that times out mid-conversation. Each is scored the same way every run: the right listing resolved, the status matching the authoritative system, the access condition respected, one lead afterwards with owner and source unchanged, and the handoff complete.

This page describes work that can be scoped for an agency, not a system already deployed at one. No accuracy figure is quoted here; that comes out of testing against your own enquiries.

What a real estate build costs

Every engagement starts with a fixed-price discovery sprint at USD 2,500 over two weeks, which produces the architecture, initial screen designs, acceptance criteria, a running-cost model and a fixed price for the build. The sprint fee is deducted from the build.

Running cost splits between what scales with enquiries, metered per minute or per message, and flat hosting and seat fees. The model is built from peak concurrency in your own enquiry logs.

Part of the AI Feature Implementation Sprint → · Explore our work → · Discuss an AI project →