Unit Status: One Source Everyone Can See

Part one named the visibility gap and the places it opens, and closed with a one-week counting exercise that gives you a number for the size of the problem. Assume you ran it. You are now holding a list of your units with a note beside some of them: recorded as leased but actually empty, a lease that expired and was never updated, a payment that arrived with no entry against it. The next question is direct: where do you record reality so the record never drifts from it again?

The answer is not a better file or a more careful employee. It is one declared status per unit, visible to everyone who needs it at the same moment, changed only by a recorded action that carries an owner, a timestamp and a document. The difference between that and what you have today is not a difference of tooling. It is the difference between storing information and knowing a state. Information is written once and goes stale in silence; a state obliges its owner to keep it current, because a later action depends on it.

Every unit is in exactly one state at any moment

Before any tool, the list of states itself has to be agreed. In most offices no approved list exists, so one employee writes empty, another writes available, a third writes in process — three words with no clear action behind them and nothing anyone can filter on. A status is not free-text description. It is one slot from a closed list, and every slot carries a single operational meaning nobody can argue about:

• Vacant, not ready. The tenant has left and the unit is being cleaned, repaired, or waiting to be photographed. It is not listed yet, but the clock has been running on it since day one.
• Ready and listed. Photographed, priced and advertised. Any unit that is ready but not listed is deferred income for no reason, and this state is what exposes it.
• Reserved. There is a serious applicant who has paid a deposit or a good-faith amount. A reservation is temporary by nature, so this state must carry an expiry date — otherwise it becomes disguised vacancy that shows up in no report.
• Leased. There is a live contract with a start date, an end date and scheduled payments. Here the status is not one slot but an entry point into a file: the lease, its documents and its dates.
• Under maintenance. Occupied or empty, but with work in progress that prevents handover. It must be tied to a maintenance request with a number, or the state becomes a hiding place for everything that broke and nobody followed up.
• Out of service. An owner's decision to pause letting, or a regulatory or structural constraint. Keep it separate from vacancy, because it does not count against marketing performance and nobody is supposed to be working on it.

One rule governs the list: a unit is in exactly one state at any moment, and there is no state called unknown. If nobody knows a unit's status, that is not an empty cell — it is an urgent task for a named person. An empty cell in a spreadsheet bothers nobody, which is precisely why it stays empty for months.

Why a spreadsheet cannot represent a state

The expected objection: all of this is already in my sheet, I have a column called status. The difference is that a sheet stores a value, while operations need a state. A value is text in a cell; a state is a commitment that triggers an action. Here is what the file cannot do, however neatly you keep it:

• It does not know who changed it or when. A unit flips from leased to vacant in one keystroke, and two months later, when the owner asks exactly when the tenant moved out, there is no trace. A record with no modification history is an opinion, not evidence.
• It alerts nobody. A sheet waits for you to open it. Operations need the opposite: the record should come to you and say a lease ends in a month, and a unit has been ready but unlisted for twelve days.
• Multiple contradictory copies. The file gets sent into a chat so a partner can look at it, they edit it, and now you have two correct versions at once. A single source is not organisational luxury; it is the condition that makes the question what is the status meaningful at all.
• It does not tie the state to what proves it. You write vacant — where is the handover record? You write reserved — where is the deposit receipt? A state that does not carry its document collapses at the first dispute.
• It permits impossible states. A sheet will happily hold a unit marked leased whose contract expired two months ago, because it does not understand the relationship between the two columns. A system that does understand it either refuses the contradiction or flags it immediately.

Notice that none of this is a flaw in Excel. Excel is an excellent calculation tool; it is not an operations tool. The trouble starts when we ask a spreadsheet to manage obligations between people over time.

What every status change must carry

This is the practical core of the whole part. Changing a status is not updating a field; it is a complete operational event. And every event must carry four things with it, or it is just a recorded rumour:

• Who changed it. A named person, not a shared account. Responsibility that is not attributed to someone does not exist.
• Exactly when. The time of the event itself, not the time somebody remembered it. The distance between those two timestamps is the same gap part one described.
• To which state, and why. A short reason from a fixed list: lease ended, eviction, termination, maintenance completed, owner's decision. The reason is what later becomes the report that tells you why your units actually sit empty.
• The accompanying document. Every state has its natural document: a move-out carries a handover record with dated photos and meter readings, a reservation carries the deposit receipt and the reservation's validity period, a letting carries the contract and its papers, and entering maintenance carries the request number.

Above the four, the most important: every status change should generate the next action automatically. A move-out opens a cleaning task, finishing the cleaning opens a photography and pricing task, and pricing opens a listing task. That is how a ready unit stops sitting unlisted for two weeks because nobody remembered. A state that does not push toward an action is nothing more than elegant archiving.

One screen for the portfolio, not a file per building

The common arrangement gives every building its own file, and every owner theirs. That is convenient for archiving and fatal for decisions, because every real question crosses buildings: which units are vacant across the whole portfolio right now, and for how long? Which contracts end in the next sixty days? Which units carry an overdue balance or an open maintenance request? Answering any of them out of separate files means manual consolidation that nobody performs except when the owner demands it.

The practical test for any tool you are considering is simple: does it answer those three questions in seconds while you are standing, or does it need an export and a merge? A single screen that sorts the entire portfolio by status and by time since last change is what turns a record into a decision tool. Sorting by elapsed time in particular is what exposes what a static status hides: a unit vacant for three days is normal, while a unit in the same state for seventy days is a pricing or listing problem, not a market problem.

The Origami view

Real estate and hotels is one of our specialisation sectors, and we start any project in it by fixing the list of states and their owners before designing a single screen. The reason is that a beautiful screen built on states nobody agreed on produces a dashboard showing numbers nobody trusts — and within months the team is back on chats and phone calls, having paid for a tool that goes unused.

The order we recommend: define the states and their owners, then make changing the status be the process rather than an extra step after it, then build collection, renewals, maintenance and reporting on top. That order is what the rest of this series follows, and it is how we approach the real estate and hotels sector, because every later layer reads from the status — and if the status is wrong, everything above it is wrong with more confidence.

What you can do this week

The first improvement requires no purchase. It requires small decisions, written down and adopted:

• Write the list of states on one page and adopt it formally, with no descriptions allowed outside it. Six states cover most portfolios.
• Give every state a single owner — the person authorised to move a unit into it and accountable for moving it out.
• Name the document each change requires, and treat the change as incomplete without it rather than accepted on a promise to send it later.
• Tie every state to the action it opens, even with a simple task list at the start.
• Review weekly the units whose status has not changed in a long time, because stillness in this record signals a fault, not stability.

In the next part

The status is fixed, with an owner, a timestamp and a document behind it. The next part builds the heaviest cycle in property on top of it: money. A scheduled due date for every contract, a reminder before the due date rather than after it, the payment posted the moment it arrives, an escalating path for chasing arrears, and a renewal alert that reaches you early enough to negotiate rather than evict.

Sources

• Real Estate General Authority (REGA) — regulation of the Kingdom's real estate sector, its services and platforms.
• Ejar network — documentation of lease contracts, their parties and their terms.
• Ministry of Tourism — licensing of tourist accommodation facilities and their operating requirements.
• Ministry of Municipal and Rural Affairs and Housing — policies governing the municipal and housing sectors.
• Saudi Vision 2030 — the national direction for the housing and tourism sectors.