Most CRMs sync from an IDX feed instead of pulling directly from the MLS, so status changes arrive late and every incomplete sync forks a new contact record instead of updating the one you already have. That’s why your CRM still shows a listing as active two weeks after it closed, and why the same buyer shows up three times under three slightly different email addresses. I’ve run the technology behind a Reno brokerage for 22 years, and this is the ticket I get more than any other.
The three places the connection actually breaks
There are three specific failure points, and they’re mechanical, not mysterious.
Every MLS field has to be manually mapped to a matching field in the CRM the first time the integration is built — status to status, list price to list price, showing instructions to whatever field the CRM calls showing instructions. If a field doesn’t have an obvious match, whoever sets up the integration either forces it into the closest wrong field or skips it. When your MLS adds a new field — a disclosure flag, a new photo count, a revised status code — nothing updates the mapping automatically. It just doesn’t come across until someone notices it’s missing and fixes it by hand.
Most CRMs used by small brokerages don’t talk to the MLS directly. They pull from an IDX feed — a downstream copy of MLS data delivered by a syndication vendor, refreshed on that vendor’s schedule rather than in real time. Depending on the vendor, that refresh might run every fifteen minutes or once an hour, and a failed pull can sit unnoticed for a day. A listing goes pending at 9 a.m., the feed doesn’t pull again until noon, and for three hours your CRM is showing agents a status that stopped being true before they logged in.
MLSs don’t all use the same schema, either. Some follow the RESO Data Dictionary closely; others still run older, locally built field sets with names that only make sense if you were in the room when they were created. A CRM vendor selling to brokerages nationwide can’t hand-map every regional MLS in advance, so the mapping for your specific board is usually the last thing built during setup and the first thing skipped when a deadline gets tight.
A buyer fills out a form on your website. The same buyer calls the office and gets logged manually by whoever answers. They sign in at an open house and the sign-in sheet gets entered as a lead too. Each of those touches creates a separate contact record unless the systems agree on a single identifier — usually a normalized phone number or email — and check for a match before creating a new one. Most integrations skip that check, because it requires someone to decide, in advance, which field is the identifier and how it gets cleaned up: does “(775) 823-3333” match “775-823-3333”? Without that decision, the CRM just keeps adding people.
The spreadsheet is the tell
In 22 years running systems for a brokerage, I’ve never walked into an office with a broken CRM-MLS integration that didn’t also have a spreadsheet. Somebody — usually an office manager or a transaction coordinator — keeps a running list of what’s actually still active, which leads have actually been contacted, or which contact record is the real one. It’s usually in Google Sheets, sometimes in someone’s email drafts, and it never appears in the CRM adoption numbers anyone reports to ownership.
I’ve seen different versions of it. One office tracks “status per MLS” next to “status per CRM” in adjoining columns so nobody has to guess which one is current. Another just keeps a running list of leads that came in through two different channels, so a duplicate doesn’t get double-contacted by two agents on the same day. The format changes from office to office. The reason it exists doesn’t.
That spreadsheet is the most reliable diagnostic I know for a broken integration — more reliable than agent complaints, because agents get used to the workaround and stop mentioning it. And it’s where the real cost hides. Nobody puts a line item on a budget for “the spreadsheet.” It’s absorbed into someone’s Friday afternoon, and because it’s absorbed, it’s never priced. That’s the next section.
What it costs, worked out
Here’s a way to put a number on it, using assumptions you can swap for your own. Say each agent loses one hour a week to this — checking a status against the board because the CRM doesn’t match, or fixing a contact record that split in two. Value that hour at $35, a reasonable loaded rate for what an hour of an agent’s time is worth to the brokerage, even though most agents aren’t paid hourly. For a 10-agent office:
- 1 hour per agent per week × 10 agents = 10 hours a week
- 10 hours × $35 = $350 a week
- $350 × 52 weeks = $18,200 a year
The hours are the easiest cost to put a number on, but they’re not the only one. A stale status means an agent shows a house that’s already under contract, which costs a client’s trust more than it costs anyone’s time. A missed follow-up on a lead that got orphaned in a duplicate record is a commission you never know you lost, because you never see the lead that went quiet — the same blind spot that makes slow lead response so easy to miss until you’re already down the deals.
That’s a conservative estimate, and it doesn’t include the time the office manager spends maintaining the spreadsheet from the last section, which in my experience runs higher than any single agent’s share. Change the inputs to match your office — a 20-agent shop with two hours of friction a week and a $45 loaded rate works out to $93,600 a year. The exercise isn’t about landing on the exact number. It’s about noticing that the number is real, even though it never shows up on an invoice.
When you shouldn’t integrate
Not every brokerage should do this, and I’d rather say so here than bill for it later.
Under about five agents, the math above doesn’t work. At $35 an hour, one hour of friction a week comes to about $1,820 a year per agent — not nothing, but not enough to justify an integration project, which typically runs into real money of its own in setup time and CRM configuration and won’t pay for itself for years, if ever. A shared spreadsheet and a habit of double-checking status before a showing will cost you less than the fix.
If you’re already planning to replace your CRM, don’t build the integration into the one you’re leaving. I’ve watched offices spend real money mapping fields into a system they dropped eight months later. Fix the mapping once, on the platform you’re keeping.
And check your MLS’s data license before you commit. Some MLS agreements restrict how listing data can be stored outside MLS-approved systems, how long it can be retained after a listing goes off-market, and whether it can be pushed into a CRM that isn’t already an approved vendor. If your CRM doesn’t have an existing compliant relationship with your MLS, the integration might require a data license amendment that costs more, in fees and paperwork, than the time it saves. Ask your MLS’s IT or compliance desk before your developer, not after.
None of these are reasons to avoid fixing the underlying habits — the spreadsheet, the manual double-checking. They’re reasons to hold off on paying for a technical integration until the volume or the timing actually makes sense.
What a working setup looks like
When I’ve fixed this for a brokerage, three things were always true afterward.
One person owns the field mapping. Not “whoever built it in 2019 and isn’t here anymore” — a named person, current, who gets told when the MLS changes its data dictionary and updates the mapping before agents notice something’s wrong. At the brokerage where I work, that’s part of my job, and I still schedule a quarterly check against the MLS’s published field list, because MLS changes happen without much warning.
One system is the source of truth for contacts, and everything else feeds it instead of duplicating it. Website leads, open-house sign-ins, and manual entries all route into the CRM through the same intake path, checked against the same normalized identifier, before a new record gets created. If two systems can both create a contact independently, they will eventually create the same contact twice.
Status sync runs on a schedule the team actually knows. Not “real time,” which almost nothing actually is — a schedule, communicated to agents, so they know a status is trustworthy as of the last sync and act accordingly during the gap. This is a documentation problem as much as a technical one; if nobody has formally mapped out who owns which step, it’s worth doing that as its own exercise before you touch the integration itself.
Part of what keeps a fix like this working is training, not just configuration. At the brokerage where I work, I run an internal program called Sierra Academy specifically so agents understand what the CRM is doing and why a status might lag by twenty minutes, instead of assuming the software is broken. A mapping nobody explains to the people using it gets blamed for problems it didn’t cause.
None of this requires a big rebuild. It requires someone deciding, in writing, who owns the mapping, what the source of truth is, and how often the sync runs — and then agents actually believing what the CRM tells them, because it’s finally accurate.
Frequently asked questions
Does my MLS allow a direct CRM integration?
It depends on your MLS’s data license and whether your CRM vendor already has an approved integration agreement with that MLS. Some allow direct RETS or Web API access outright; others require a paid data license amendment, and a few restrict what can leave their system entirely. Ask your MLS’s IT or compliance desk before your developer does.
Will this break my IDX website feed?
No, your IDX feed and a CRM integration are usually two separate connections into the same MLS data, and fixing one doesn’t touch the other. The exception is if your website and your CRM currently share the same feed subscription; in that case, changes need testing on a staging version of the site first, not live.
What does an integration like this typically cost?
It varies widely by CRM, MLS, and how much cleanup the contact data needs before it can sync properly, so I won’t quote a number I can’t back up. Ask any vendor for cost broken out by setup, field mapping, and ongoing maintenance separately, since the maintenance line is the one most quotes leave out entirely.
How long does it take to set up?
For a straightforward field mapping on a well-behaved MLS feed, plan on a few weeks, most of it spent testing status changes and duplicate handling rather than the initial connection. Add time if your MLS requires a data license amendment first, or if your contact records need cleanup before the sync goes live.
If your office is somewhere in the mess I’ve described — a spreadsheet nobody talks about, agents who’ve stopped trusting the CRM, or a status sync that’s more suggestion than fact — I’d rather have a straight conversation about it than sell you a project you don’t need. I’ve spent 22 years fixing this exact problem for one brokerage; if it’s useful, take a look at what that work looks like and get in touch. No sales pitch, just a straight conversation.