40%

faster first response to a new enquiry

Real Estate case study

Keeping listings honest across a website, three portals and a CRM

A brokerage whose listings drifted out of sync across portals got one source of truth and near-real-time updates everywhere.

Client
Acreline
Vertical
Real Estate
Role
Listings platform and portal sync
Year
2024

How it ran

From brief to outcome.

  1. 01

    Brief

    One price change should reach every portal, and no enquiry should sit unseen. Stop the stale-listing complaints.

  2. 02

    Approach

    Make the CRM the source of truth, fan changes out per portal, and pull every enquiry into one routed inbox.

  3. 03

    Build

    A listings hub, per-portal adapters, an enquiry router with response timers, and a drift monitor, shipped portal by portal.

  4. 04

    Launch

    Connected one portal at a time, watched the drift monitor confirm parity, then moved the team fully onto the routed inbox.

  5. 05

    Outcome

    Listings stayed consistent everywhere, stale-price complaints stopped, and agents reached new leads markedly faster.

What changed

Before, and after.

Time for a price change to reach all portals
BeforeHours to days
AfterNear real-time
First response to a portal enquiry
Before~6 hrs avg
After~3.5 hrs avg
Stale-listing complaints per month
Before~25
After~3

The work

The problem, and how we took it on.

The challenge

Acreline listed the same property on its own site and three portals, plus a CRM the agents lived in. A price change in one place rarely reached the others, so buyers saw stale prices and sold homes still showing as available. Enquiries from the portals landed in inboxes nobody watched closely, and the best leads went cold.

Our approach

  • Made the CRM the single source of truth for a listing, so there was one place a change could come from.
  • Pushed updates out to each portal on its own terms, since every portal's feed format and rules are different.
  • Pulled every portal enquiry into one routed inbox with an owner and a clock, instead of scattered email.
  • Added a quiet reconciliation pass that catches a listing that drifted and flags it before a buyer notices.

What we built

  • A listings hub where one edit fans out to the website and every connected portal.
  • Per-portal adapters that handle each feed's format, media rules and update cadence.
  • An enquiry router that assigns each new lead to an agent and tracks time-to-first-response.
  • A drift monitor that compares what's live on each portal against the source and flags mismatches.

The outcome

Acreline's listings now read the same on every channel, so buyers stop calling about a price that changed last week or a home that already sold. New enquiries land with an owner and a timer, and the team reaches them noticeably faster, which is where deals are won or lost. The drift monitor means the brokerage hears about a mismatch before a client does.

Built with

The stack on this project.

TypeScriptNext.jsNode.jsPostgreSQLRedisAWS

Where this fits

The services and industry behind it.

Straight answers

Questions about this build.

How close to real time are the portal updates?

An edit in the CRM fans out within seconds in most cases. Some portals only accept feeds on their own schedule, so for those the platform queues the change and confirms parity once the portal picks it up.

What happens when a portal and the source disagree?

A reconciliation pass compares each portal against the source listing and flags any drift to the team, so a mismatch is caught internally before a buyer runs into it.

Have a problem like Acreline’s?

Tell us what's slowing your product down. We reply to every serious enquiry within one business day.