Three kinds of price list drift, and which one responds to speed

A broker rang the sales desk at one of our clients on a Saturday morning, the second weekend after launch I think, to reserve a two-bed for a couple he had waiting in the car. The flat had sold the evening before. He had Friday's price list open on his phone, a PDF the sales coordinator had emailed to forty agents at five o'clock, and as far as that PDF was concerned the flat was still free. The coordinator, I do not remember her name, spent the rest of the morning ringing the other thirty-nine. On Monday the marketing director told us the website had also shown the unit as available until somebody republished it at ten. Three people described the same weekend to us, and each of them blamed a diffrent thing for going stale.

Only one of the three gets better if you update faster. The website does. The PDF was already in forty inboxes and could not be pulled back. The feed to the listing portal, which had also been offering the flat, had quietly stopped a week earlier and the coordinator had not noticed. The usual fix, update more often and make it someone's job, matches one failure out of three.

The recall test

To sort the three, ask if the stale copy can still be reached. A file that has left the building cannot be corrected at all. A page in your CMS can be corrected, but only when someone publishes. A feed from another system corrects itself, right up until it stops. They look alike from the sales desk, because the symptom is always a broker telling a buyer a unit is free when it is not. Underneath they are three seperate problems with three seperate fixes.

Where publishing faster does help

A published page is the case where speed matters. The listing sits in a CMS or a static build, someone corrects it, and someone has to press publish. At one sale a week, publishing daily keeps up. On a launch weekend with twenty reservations in a day, hourly is not enough, and the gap is whatever sits between the sales record and the publish button. You can shrink that gap by publishing more often. You cannot close it while the publish step exists. Because this is the one case where the fix works, teams assume it works everywhere.

The PDF that left the building

Few people think of the exported file as a software problem, and that is why it hurts. The price list goes out to the broker network on Friday. A unit sells on Saturday morning. The PDF is now wrong in every inbox it reached, and no amount of updating faster reaches into somebody else's phone.

How much it hurts depends on scale. Malinowskiego is six houses in Jozefow near Warsaw, and a stale PDF there is embarassing but you fix it with one phone call. Safa Al Fursan is 528 units across 25 buildings in Riyadh, and at that size every stale PDF is an open window for the same unit to be promised twice. The file format is the same in both places. The consequence is not.

The fix is to stop sending documents that can go stale and send a link to the live availability instead. The broker then sees the same record the sales team writes to, and when a unit moves to reserved at nine on Saturday morning, every open browser tab shows it.

The feed that stops without telling you

A synced feed updates itself. CRM to website, a webhook, a scheduled pull. When it works nobody thinks about it, and when it stops nobody notices either, wich is the whole problem. A working feed and a broken one feel identical from where the sales team sits, because in both cases you do not check. Not checking was the point of building it. The difference shows up when a buyer calls about a unit that sold yesterday.

Speed does nothing here. What helps is monitoring: a staleness alert, a health check, something loud when the quiet thing stops. Most teams build the feed and skip that second part, because on the day the feed goes live it feels like the problem is solved.

One record, and what you give up for it

Tightening the process feels safer than changing the architecture, so that is what most teams do. But a process that manages around a structural gap does not close it, it just makes the gap somebody's job forever. That is the mistake in update faster: it is the right fix for the published page, and it gets applied to all three.

The other two are solved differently. For exported files, stop exporting and send a live link. For feeds, monitor them, or remove the seam altogether by having one database, so there is no second copy to sync.

We built the platform around that second option. The website, the interactive floor plan and the sales dashboard all read the same unit row, so there is no second copy to drift. The trade is a single dependency: if that system is down, every channel is down at once, and you should know that before you choose it. For a six-house estate where the sales lead knows every buyer by name, the spreadsheet and the phone call still work fine. One record costs you a migration and one dependency. Two records cost you a reconciliation job that does not end. Either is a reasonable choice, as long as you know which one you are making.