resources
IDX Lead Handoff in City Property Markets: The Complete Guide
19 Sept 2026

An IDX lead handoff is the chain of integrations that carries a property enquiry from a listing page on an agent’s website into the CRM where somebody is supposed to call it. It is one of the least examined pieces of software in residential real estate, and in dense urban markets — where a buyer compares four flats in the same district on the same evening, it is where most of the loss happens.
Your IDX search works. Someone found a three-bedroom on your site at 9:40pm, filled in the form, and hit send. Eleven hours later you spot the name in your CRM with no property address attached, no saved search history, and a source field that just says "website." By then they’ve toured two homes with another agent.
The listing side of most agent websites is fine. The handoff is where deals leak. A lead moves from your IDX provider to your CRM through a chain of small integrations, and every link in that chain can drop a field, delay a record, or file the enquiry under a source that tells you nothing. City markets punish this harder than rural ones, because supply is denser, the buyer’s shortlist is longer, and the cost of being third to call is higher. This piece walks through where those breaks happen, what to check on your own setup, and how to close the gap between the form submission and the first call.
One note on scope. The plumbing described here is the North American one: an MLS feeding an IDX provider under RESO standards. If you operate in a market served by national portals rather than an MLS, the vocabulary changes but the failure points do not. A listing source hands an enquiry to a website, the website hands it to a CRM, and fields go missing at every boundary.
What actually happens between the listing page and your CRM
Most agents picture one step: someone fills in a form, the lead appears in the CRM. There are usually four or five.
- The MLS sends listing data to your IDX provider. This runs on a schedule, not in real time, and the interval is set by your MLS and your provider.
- Your IDX provider renders listing pages and search on your domain, either as an embedded widget, an iframe, or a full integration into your site’s templates.
- A visitor submits something — a contact form, a showing request, a saved-search signup, or a registration wall.
- The IDX provider captures that submission and holds the lead in its own dashboard.
- A connector pushes the lead to your CRM, mapping fields from one system’s schema to another’s.
Step five is where most of the damage happens, because it’s the only step nobody demonstrates during a sales call. You’ll be shown the search experience and the dashboard. The field mapping is left as an exercise for the buyer.
It’s worth knowing what standard your data runs on. The Real Estate Standards Organization stopped certifying RETS in 2018 and moved entirely to the RESO Web API, now the mandated transport for REALTOR®-operated MLSs under NAR Policy 7.90, with more than 500 certified MLSs as of June 2026. If a provider still describes your feed as a RETS pull, you’re on a legacy path that fewer people maintain each year.
Where the handoff breaks
Four failure modes account for most lost enquiries, and they’re all quiet. Nothing errors. The lead just arrives worse than it left.
Field mapping drops the property. This is the big one. An IDX lead is only useful because it carries context: which listing, which price band, which neighbourhood, how many times they came back. Many connectors map name, email, and phone, then discard everything else because the destination CRM has no matching field. You get a contact record identical to one from a newsletter signup. The agent calling it has nothing to open with.
The source field collapses. If every web lead lands tagged "website," you can’t tell a high-intent showing request from someone who downloaded a buyer’s guide. Six months later you can’t work out which of your marketing spend produced closings, because the data to answer that was thrown away at the point of capture.
Duplicates fork the history. A buyer registers in March with a Gmail address, comes back in August and uses a work address. Without a deduplication rule, that’s two records, two saved-search histories, and potentially two agents calling the same person.
Sync delay. Some connectors poll every 15 minutes. Some batch overnight. If yours batches, a 9:40pm enquiry is a 7am lead, and the buyer has had a full evening to fill in three more forms.
Registration walls capture the wrong moment. Forcing signup after three listing views produces more records, and a meaningful share of them are throwaway addresses typed to get past the gate. Those land in your CRM looking identical to a genuine showing request. If your connector doesn’t pass through which gate the lead came from, your team can’t tell a buyer who asked to see a house from someone who wanted to get past a form, and both get the same follow-up sequence.
Fixing these usually means treating the feed and the CRM sync as one system rather than two separate purchases, which is the practical shift in IDX software development over the past few years: the question moved from "can we display listings" to "which system owns the lead record, and what does it carry." If you’re scoping work with a developer or evaluating a provider, that’s the question to lead with.
The fields that decide whether a lead is worth calling
Before you change anything, decide what a useful lead record looks like for your team. For most residential agents, the minimum set is:
- Listing address and MLS number of the property they enquired about
- Price and price band of that listing
- Enquiry type — showing request, general question, saved search, valuation request
- Search history, or at least the count of sessions and last-seen date
- Saved searches and favourites, which tell you the real criteria rather than the one house they clicked
- Original source and campaign, kept distinct from the generic "website"
- Timestamp of submission, in your local timezone, not the provider’s
That list isn’t long, and none of it is exotic. It’s just that each field has to survive three systems. Check what your CRM actually received on your last ten web leads before assuming any of them made it.
One detail worth arguing about with your provider: favourites and saved searches are behavioural data, and they age. A saved search from eleven months ago describes a buyer who has probably already bought. If your connector syncs these once at lead creation and never again, the CRM’s picture of that person freezes on day one.
There’s a second-order benefit to getting this right that has nothing to do with the first call. Once listing context lands in the CRM reliably, you can segment on it: everyone who enquired in one price band, everyone who favourited a property in a school catchment, everyone whose saved search hasn’t matched a new listing in 60 days. In a city portfolio that spans several districts and price tiers, that segmentation is the difference between a mailing list and a pipeline.
Speed is the part you can’t make up later
The research here is blunt. The MIT Lead Response Management study, built on three years of data covering more than 15,000 leads and over 100,000 call attempts, found that the odds of contacting a lead drop more than tenfold within the first hour. Comparing a five-minute response against a thirty-minute one, the contact odds differ by a factor of 100, and the odds of qualifying the lead by a factor of 21.
Apply that to a batched overnight sync and the arithmetic gets uncomfortable. It isn’t that slow follow-up converts a bit worse. It’s that the lead is functionally a different, much colder lead by the time you see it.
This is also why routing matters as much as speed. A lead that syncs in 30 seconds and then sits unassigned in a shared queue until someone notices it is no faster, in practice, than one that arrives at 7am. Three things need to be true:
- The record reaches the CRM in near real time
- It gets assigned to a specific person, not a pool
- That person is notified somewhere they actually look
Most agents I’ve seen fix the first and forget the other two.
Buyer behaviour makes the timing tighter than it used to be. NAR’s 2025 Profile of Home Buyers and Sellers reports that 52% of buyers found the home they purchased online, and 70% used a mobile device or tablet during the search. A phone-based search at 10pm is a phone-based enquiry at 10pm, and the person sending it is rarely sending only one. In a city where a dozen comparable flats are listed within a short walk of each other, they are almost certainly sending several.
How to audit your own handoff this week
You don’t need a project for this. You need an hour and a test lead.
- Submit a real enquiry on your own site, from a phone, on a specific listing, outside office hours. Use an email address you control but that isn’t already in your CRM.
- Note the exact time. Then watch for the record in your CRM and note when it lands. That interval is your actual sync delay, whatever the provider’s documentation claims.
- Open the record and list what’s missing against the field set above. Screenshot it. This is the artifact you take to your provider.
- Check the source and campaign values. If they say "website" or are blank, your attribution is already broken.
- Submit a second enquiry with a different email but the same name and phone. See whether you get one record or two. That’s your deduplication test.
- Check who it was assigned to and whether anyone was notified. Ask that person whether the notification reached them anywhere they’d see it on a Saturday.
- Repeat for each lead type you offer — showing request, saved search, valuation. They often run through different forms and different connectors, and they frequently behave differently.
Run that and you’ll have a specific list of defects rather than a vague sense that the website isn’t producing. Vague complaints get vague responses from vendors. A screenshot showing a missing MLS number gets a ticket.
What to ask before you sign with an IDX provider
Most of the problems above are cheaper to avoid at purchase than to fix in year two. If you’re evaluating providers, or renewing, these are the questions that separate the ones who’ve thought about the handoff from the ones who’ve only thought about search:
- Which standard do you pull on, and from which MLS? You want to hear RESO Web API and your specific MLS named back to you.
- How often does listing data refresh, and is that a pull or a push?
- Show me the exact CRM payload for a showing request. Not a feature list. The actual field names and a sample record.
- Which of my CRM’s custom fields can you write to? Some connectors only map a fixed set, whatever your CRM supports.
- Is the sync real time, scheduled, or batched? Get the number in minutes, in writing.
- How do you handle duplicates across different email addresses?
- Do you re-sync saved searches and favourites after lead creation, or only once?
- What happens to leads if the CRM connection fails overnight? Queued and retried, or dropped?
- Can I export my leads, with full history, if I leave?
The last one matters more than it looks. Lead history is the asset you’re building, and a provider who makes it awkward to take with you has priced that awkwardness into your renewal.
FAQs
Should the IDX provider or the CRM be the system of record?
The CRM, in almost every case. The IDX dashboard is where leads appear first, not where they should live. If your agents work two dashboards, half the activity history ends up in the one nobody updates.
We operate outside North America, with portals instead of an MLS. Does any of this apply?
The failure modes do, almost entirely. Swap "MLS feed" for "portal enquiry forwarding" and the same four things go wrong: context fields get dropped, the source collapses into a generic label, duplicates fork, and the sync is slower than anyone told you. The audit described earlier works unchanged. What differs is leverage — with a portal you usually cannot change the payload, so the work moves to what your own site and CRM do with it on arrival.
Is a native CRM-plus-IDX product better than connecting two tools?
Sometimes, and the tradeoff is real. A combined product removes the mapping problem but ties you to that vendor’s search experience and their CRM’s limits. Connected tools give you better components and one more thing to maintain. Pick based on which problem your team is worse at living with.
How often should listing data refresh?
Ask your MLS what they push and how often, then ask your provider what they pull and how often. The slower of the two is your real number. Buyers notice stale listings faster than agents do, and a "still available" home that sold last week costs you credibility on the first call.
What if my CRM has no field for MLS number?
Most CRMs allow custom fields. Create them before you rebuild the mapping, not after. A connector can only deliver data into a field that exists.
We’re a two-agent team. Is this worth the effort?
More so, not less. A large brokerage can absorb a broken handoff by throwing volume at it. On a two-person team, every lead that arrives stripped of context is a call you make blind, and you’ll make fewer calls in total. The audit takes an hour and the fixes are mostly configuration rather than development.
Takeaways
The listing search on your site is rarely the weak point. The chain between a submitted form and a notified agent is, and it fails quietly enough that most teams never audit it. The denser your market, the faster that gap is punished.
Three things to do next: run the test-lead exercise above and write down your real sync delay; compare what lands in your CRM against the field list in this article; and check whether new leads are assigned to a person rather than a queue. Those three answers will tell you whether your next investment belongs in more traffic or in the handoff you already have.






