A new instruction, and the matching list is hopeless
A three-bedroom semi with a large garden comes on. The CRM match returns two hundred applicants: anyone looking for three bedrooms under a price in a broad area. Some of them bought months ago. Some said they needed a downstairs bedroom, or no main road, or a particular school catchment, but that was typed into the notes, not the criteria fields.
The negotiator does not have time to call two hundred people, so the automatic email goes out and the listing goes on Rightmove the same day. The buyer who would have been perfect sees it on the portal along with everyone else.
Why matching disappoints
CRM matching works on the fields that were filled in at registration, and registration forms capture only a few. The requirements that make a buyer choose one house over another, such as parking, a garage for work, a ground-floor bathroom or being near a relative, are said in conversation and written as notes. The system cannot match on notes.
Applicant lists also go stale. Buyers who have bought elsewhere or given up are rarely removed, so match lists are padded with people who will never reply.
| What the CRM matches on | What the buyer actually cares about |
|---|---|
| Price band | Real budget given their sale and mortgage |
| Bedrooms | Bedroom layout, a room for home working |
| Broad area | Specific streets, schools or commute |
| Property type | Garden, parking, no stairs, no main road |
What weak matching costs
Your registered buyers are your advantage over the portals, but only if you use them first. When a good buyer finds the listing on Rightmove, you have gained nothing from registering them. Vendors like to hear that you have buyers ready to view; that promise weakens if the viewings come from the portals anyway.
Bulk alerts also train applicants to ignore your emails, which makes every future alert less effective.
How we build better matching
- Requirements extraction: we read applicant notes, call summaries and feedback from past viewings with a language model to pull out real requirements, such as must have parking, and store them as structured fields your team can check and edit.
- Freshness check: applicants with no recent contact are asked briefly whether they are still looking, and those who have bought or stopped are marked inactive.
- Ranked matching: for each new instruction, applicants are scored against both the standard criteria and the extracted requirements, with the reason for each match shown.
- Call list: negotiators get the top matches as a short list with the key reason for each, before the property goes to the portals if your process allows.
- Personalised alerts: remaining good matches receive an email that mentions why the property may suit them, rather than a generic alert.
- Feedback loop: viewings and outcomes are recorded, so matching improves as your team uses it.
What the negotiators notice
A new instruction arrives with a short list of people worth calling, and the conversation starts with something specific: you mentioned needing parking for a van, this one has a double driveway. Your applicant list shrinks to people who are actually looking. Vendors see early viewings from your own buyers.
It also changes how negotiators register new applicants. Once they see that notes feed matching, they take a little more care to record what a buyer really needs, and the conversation at registration becomes more useful for both sides. Branch managers can see which new instructions attracted strong matches from the existing list and which needed the portals, which is a helpful signal for where to focus applicant marketing.
Are your registered applicants going to waste?
- CRM matches return long lists that nobody works through.
- Buyers' real requirements live in notes, not in fields.
- Registered applicants often see new listings on the portals first.
- Your applicant list includes many people who have already bought.
- Alert emails get few replies.