One record for unit availability, not four copies in sync

The buyer's brochure quoted one price. The website quoted another, a little higher. And the apartment a broker had reserved for a client that morning still showed as free on the public listing, which is how two families ended up holding paperwork for the same unit. Someone had to make the call that unwinds that, and there is no smooth way to make it.

None of it was a typo. The sales spreadsheet, the website CMS, the CRM, and the price-list PDF each held their own copy of that unit's price and status, and each copy had drifted at its own pace. The spreadsheet ran a week ahead of the site. The PDF trailed a month behind everything. When four systems each store the number, the number quietly stops meaning one thing. This piece is about where that number should live. It is not a product tour.

No sync can invent an authority

The reflex, the morning after a double-sale, is to go shopping for integration. Wire the CRM to the CMS. Buy a real-time feed. Make the number travel faster between systems. There is a plainer check to run first: count the places where a person can open unit 4B and type a new price or flip its status. If that count is above one, no sync removes the drift, because there is no authoritative copy to sync from. Adding an API between two master copies does not hand you one master copy. It hands you two masters and a courier.

The arrangement sold as a single source of truth usually means picking which system wins and syncing the rest to it, which leaves you with four copies and a designated favourite. It holds until a rep drops a price in the spreadsheet to close on a Friday, or flips a status in the CRM that the website never hears about, and now the sync is faithfully broadcasting a disagreement, faster than the manual process it replaced. Naming a master system labels one copy as the preferred one to copy from; it does nothing to reduce how many editable copies exist. The checklist item that names the single party accountable when the render, CMS, CRM, and site disagree is asking this same question, and we worked through it in the vendor evaluation checklist.

Whether the listing stores availability or reads it

Under all of this sits one distinction that decides whether the problem is even yours. A synced listing keeps its own copy of availability, and someone or something has to remember to update it, which is what happens when a listing does a unit record's job. A data-bound listing keeps no such copy; it pulls the live unit record at the moment of rendering, so there is nothing to fall behind. Ask any listing which of the two it does. The stored copy is the thing that drifts.

In Vinode's back panel each unit carries its own status, free, reserved, sold, or promo, along with its price, and the listings bind to that live record instead of to a hand-kept duplicate. Flip 4B to reserved once and every surface that references 4B moves with it, because all of them were reading the same field to begin with. Nobody goes hunting for the six pages that happen to mention the unit. On the buyer's side, the same binding is what lets people filter for genuinely available units without seeing ghosts.

The sharpest case is the one from the top of this piece: the buyer's brochure. Vinode builds that brochure on demand, and it reads the selected unit's current price and details from the same record the website uses. A document that reads the price cannot quote a stale one, because it never stored a price to begin with. The PDF-versus-site mismatch that opened this piece stops being something proofreading has to catch.

Batch or real-time is a question of scale

Once a single record feeds every surface, the next question is how often that record has to reach a viewer's screen. Here the honest answer is that it depends, and the thing it depends on is something you can measure. A slow-moving estate of six units, where the developer's own team makes every reservation, tolerates an hourly refresh without strain. The worst outcome is that a unit shows free for fifty-nine extra minutes while the one person who already knows it is taken gets around to marking it.

Change the scale and the arithmetic changes with it. A 528-unit launch across 25 buildings, sold through brokers reserving in parallel, cannot live with that window: every minute a taken unit still reads free anywhere is an open invitation to book it twice, and there are enough hands to accept the invitation. A rental building of 110 apartments running on a live, back-panel-bound inventory sits somewhere in between. Two variables decide where a project lands on that line: how fast units get allocated, and how many people can reserve at the same time, the same pair that decides when a shared reservation sheet double-books. Measure both before the launch and set the refresh cadence to match, instead of discovering the answer once the doors are open. A blanket rule that real-time always wins collapses on a six-unit estate, where an hourly refresh costs nothing.

Third-party portals are a separate integration job

There is a line where this advice stops. Getting your own surfaces to agree is achievable, high-value, and the first win worth taking. Pushing that availability out to third-party portals such as Rightmove, Zillow, or Bayut is a different project. Each portal defines its own feed format, its own onboarding, and its own idea of what real-time means, so syncing to all of them is a per-portal integration effort rather than a single setting.

Vinode keeps your own surfaces bound to one record, and it does not auto-feed third-party portals on your behalf. Stating that boundary is more useful than blurring it. A platform that promises to integrate with every portal out of the box often still leaves you with separate feeds to maintain, one per portal.

Who may change a unit's price during a launch

Collapse the copies to one record and the last open question is authority: who may change a unit's price and status while the launch is live. You set this as policy. Name the write authority before the doors open, decide whose hands can move a status from free to reserved, and route price changes through an approval step rather than a free-text field anyone can overwrite. Vinode's back panel supports that last part directly, with a discount-request workflow that runs through approval limits, so a rep's offer to close a deal passes a check instead of quietly rewriting the record. The base decision, who owns the number, is yours to make, and it belongs in the launch plan next to which weekly edits your team owns outright.

Count the copies, then decide what to buy

Before the next integration quote lands, do the cheap thing first. Tally the editable copies of price and availability across your website, your sales team, and your buyer's brochure, and scope the portal push as its own separate project. One record that every surface reads from removes the drift outright. A faster sync between many copies moves the same disagreement around more quickly.