Unit inventory for developers: what a hold really is, and why the sheet fails

Two agents each told a buyer that unit 4B was theirs. Both had checked the shared availability sheet that morning, both saw the cell read available, and both wrote a name against it an hour apart, in separate copies of the file that had not yet been merged. By the afternoon the developer was holding two signed reservation forms for one apartment and had no clean way to decide which buyer to disappoint.

The reflex after a near-miss like that is to blame discipline: someone should have refreshed the sheet, someone should have told the room. That reading is comforting and wrong. Unit inventory is not the task of keeping an availability list current. The list going stale is a symptom. The real failure is that the tool most teams reach for cannot hold the one thing a reservation actually is, and no amount of diligence patches over a missing field.

A new-build unit sells exactly once

Almost everything written about inventory management is about restockable stock. Reorder points, safety buffers, stock-outs: the whole discipline exists to stop a warehouse running out of a thing it can order more of. A new-build unit is the opposite kind of object. There is exactly one apartment 4B. It sells exactly once, and the entire job is making sure it is never sold twice. That is the whole game.

That inversion changes what a mistake costs. Run low on a retail SKU and you place another order; the problem fixes itself next week. Sell 4B to two buyers and there is no next week, only an apology and a mess to unwind. Generic advice about spreadsheets failing at inventory is written for the first case. None of it touches the second, which is the only one a developer has.

The states a pipeline uses, and the word that means two things

Strip the topic down and a unit is a record with a status. In Vinode's back panel that status is one of free, reserved, sold, or promo, sitting alongside the unit's price, galleries, and attributes. reserved is the interesting one, because it does not live only on the unit. It is coupled to a deal moving through the CRM's pipeline stages (open, won, lost, reserved), so a reservation is a lifecycle state with money and a named buyer behind it, rather than a word someone typed into a cell.

This is where the vocabulary gets genuinely confusing, and the confusion is worth naming. In resale property, an agent's MLS has a status called Hold, and it means something precise: the seller has paused public viewings on a listing that is still active, usually for repairs or a family reason, without withdrawing it (CRMLS Knowledgebase). That is a seller taking a home off the shelf for a while. It is a different animal from a new-build team holding one specific unit for one specific buyer who is mid-deposit. Same word, two mechanics. Search for what "on hold" means and most of what you find is describing the first one.

The deposit-and-contract side of that reservation (what makes it binding, the refund terms, the cooling-off rules) is its own subject, covered in the off-plan reservation and deposit playbook. Here the scope is narrower: the structure a hold needs before it means anything at all.

A hold is a record, not a word in a cell

Here is the point the whole thing turns on. A hold has three parts, and a spreadsheet cell can carry none of them: the buyer it is held for, its release date, and the deposit behind it. A cell can store the text HOLD. It cannot store that Anna in the sales team reserved 4B for the Okonkwo family, that the hold lapses on Friday, and that a refundable deposit has cleared. Those facts are the hold. The word is a label pointing at facts that live nowhere.

The expiry is the part generic content misses entirely, and it is where the quiet damage happens. A hold with no release date is a note that ages badly. Nobody clears it, because clearing it is nobody's explicit job, and the cell keeps reading HOLD long after the buyer walked away. The unit is sellable, but it looks taken, so no agent offers it. You have not double-sold anything this time; you have done the reverse, losing a live unit to a stale label without a single error message to warn you. That failure hides in plain sight because nothing broke.

The sheet breaks on editors and velocity

Ask when a spreadsheet stops working and most people answer with a number: it is fine until 200 units, or 500, or whatever the estate happens to have. That number does not exist. One person maintaining a 500-unit sheet, editing it slowly and alone, is completely fine. Five people editing the same 40 fast-moving units during a launch weekend is where it falls apart. The driver is concurrent editors multiplied by reservation velocity. The size of the estate barely enters into it, and the package tiers a vendor sells against mark nothing at all: a 250-unit project can be safe, and a six-unit one under five editors can already be in trouble.

And it does not break so much as degrade, which is worse. A spreadsheet never throws an error at unit N. Under concurrent editing it produces conflicting copies (the final_v2_REAL.xlsx fork everyone recognizes), silent overwrites where one person's save quietly buries another's, and no trustworthy record of who did what. Microsoft has moved its old Shared Workbook feature to legacy status and now steers teams to co-authoring instead. Its change history was never built to survive, so the question a sales manager most wants after a mix-up, namely who changed 4B's status and when, is one the sheet often cannot answer at all.

This is a different problem from the same data disagreeing across your website, your brochure, and the CRM. That cross-surface version, where a public page still shows a sold unit as free, is its own topic, covered in one record, not four copies in sync. The failure here is smaller and closer in. It happens inside one team's own list, before the data ever reaches a second surface.

When the spreadsheet is still the right tool

The honest version of this argument names the case where the sheet wins. A small project (a boutique block of a handful of units, sold by one coordinator, with a new reservation every week or two) has no real double-booking surface. One editor means no overwrite. Low velocity means a hold is cleared while it is still fresh in memory. Buying and onboarding a CRM for that is over-buying; the spreadsheet is the right-sized tool, and it stays that way until either the team or the pace grows. A 528-unit development in Riyadh worked by several agents (Vinode's Safa Al Fursan project) is nowhere near that line. Most projects live somewhere between. That is exactly why the test has to be about the work itself, and why the raw unit count predicts so little.

What actually predicts a double-sale

So stop counting units. Ask the one question that actually predicts failure: can our tool make a hold a real record, and account for who last touched 4B and when? If the answer is no, and more than one person edits fast-moving units, the sheet has already begun to degrade. You just have not hit the wrong cell yet. The near-miss is coming. The only open question is where you find out first: from your own system, or from the second buyer's lawyer.