Available, Reserved, Sold: Defining Unit Status Rules

For real estate developers, digitizing project inventory is not only a software task. It is an operations decision.

Before your team uploads projects, phases, blocks, lots, units, prices, buyers, and reservations into a system, you need to answer a basic but important question:

What exactly makes a unit available, reserved, sold, blocked, or cancelled?

This sounds simple until the sales team, admin team, and finance team use the same words differently. One person may mark a unit as reserved after a buyer verbally confirms interest. Another may wait for reservation payment. Finance may not consider the unit sold until required payment documents are complete. Management may want a separate approval step before a unit is removed from available inventory.

If these rules are unclear, digitizing inventory can simply move confusion from spreadsheets into software.

A real estate development system can help centralize unit inventory, reservations, buyer records, sales, collections, approvals, and reports. But the system works best when your business first defines the rules behind each inventory status. This is especially important for developers that want better real-time visibility and lower double-selling risk.

Why unit status rules matter before digitization

Many real estate development teams start with manual inventory files. Sales may have one spreadsheet. Admin may have another. Finance may update collections separately. Management may receive reports after several rounds of checking.

As long as the project is small, this may feel manageable. But as the number of projects, agents, buyers, and unit types grows, manual status tracking becomes harder to control.

Common problems include:

• A unit appears available in one file but reserved in another.
• Sales staff continue offering a unit that admin already processed.
• A buyer reservation is accepted but not reflected immediately in the inventory list.
• Cancelled reservations are not reopened properly.
• Management receives delayed or inconsistent project sales reports.
• Finance and collections data are not aligned with sales status.

This is why developers should define unit status rules before going digital. Software can centralize the workflow, but your team must first agree on the meaning of each status and the action required to move from one status to another.

Start with a shared inventory language

A strong real estate inventory system needs a clear status dictionary. This does not have to be complicated. It only needs to be consistent.

For many developers, the core statuses include:

• Available: The unit can still be offered to qualified buyers.
• Reserved: A buyer has started the reservation process based on the developer's internal rules.
• Sold: The unit has passed the required sales confirmation process based on the developer's workflow.
• Blocked: The unit is temporarily not available for selling, often due to management decision, internal allocation, pricing review, or other operational reasons.
• Cancelled: A previous reservation or sale process did not proceed and must be reviewed before the unit is reopened.

The exact naming can differ per company. Some developers may use terms such as on hold, pending approval, for management hold, paid reservation, booked sale, or closed. The important point is not the label itself. The important point is that every department understands the label the same way.

This is where workflow-based customization matters. iGotSolutions publicly positions its Real Estate Development System as configurable around a developer's unit types, pricing, reservation flow, approval process, project stages, and teams. That customization is more effective when your team has already defined the rules it wants the system to follow.

Suggested unit status rule table

Use a simple table like this as a starting point during your internal planning meeting. Adjust it based on your actual project process.

Unit status	What it means operationally	Common next action
Available	Unit can be offered by sales	Show to buyers or start reservation
Reserved	Buyer has entered the reservation workflow	Check payment, documents, and approvals
Sold	Sale has been confirmed based on internal requirements	Monitor collections and buyer records
Blocked	Unit is not open for selling	Wait for management or admin decision
Cancelled	Reservation or sale process stopped	Review before reopening or reassigning

This table should not be treated as a legal template. It is an operational guide. Your company should still align the definitions with your internal policies, contracts, finance rules, and management approvals.

Define what triggers each status change

After defining each status, the next step is to define the trigger.

A trigger is the event or requirement that allows the unit status to change. Without clear triggers, users may update inventory based on personal judgment instead of company policy.

For example, your team may need to decide:

When does Available become Reserved?

Is a unit reserved when:

• A buyer verbally confirms interest?
• A reservation form is submitted?
• A reservation fee is recorded?
• Admin validates the buyer details?
• Management approves the reservation?

There is no single answer that fits all developers. The right rule depends on your process. But the rule must be clear.

If the unit becomes reserved too early, your sales team may lose opportunities because units are held without proper buyer commitment. If the unit becomes reserved too late, another agent may offer the same unit to a different buyer.

When does Reserved become Sold?

A developer should also define what sold means internally.

Does it mean the buyer completed required reservation documents? Does it require approval from admin or finance? Does it depend on a specific payment milestone? Does management need to review the transaction first?

The status should match the reporting needs of management and the work needs of the team. Sales, admin, and finance should not be guessing what sold means.

When can a Reserved unit return to Available?

Cancelled or expired reservations are another common source of confusion.

Your team should define:

• Who can cancel a reservation?
• What reason codes should be recorded?
• Does finance need to check payment status before reopening the unit?
• Does management need to approve the reopening?
• Should the unit return directly to available, or should it move to a review status first?

These rules help avoid accidental reopening, duplicate reservations, or unclear reporting.

Assign status permissions by role

Not every user should be able to change every unit status.

A practical developer workflow usually separates responsibilities across departments. Sales may initiate a reservation. Admin may validate buyer details. Finance may check collections. Management may approve exceptions. Project heads may monitor performance.

Before digitizing inventory, define role-based permissions such as:

• Who can create or edit project and unit records?
• Who can update pricing information?
• Who can move a unit from available to reserved?
• Who can approve a reservation?
• Who can mark a unit as sold?
• Who can cancel a reservation?
• Who can reopen a cancelled unit?
• Who can block or unblock inventory?
• Who can view sales and collections reports?

This is one reason real estate development software should be configured around roles and approval flows, not just data fields. iGotSolutions' public materials emphasize systems customized around workflow, naming conventions, roles, and approval flows. For developers, that means the software setup can reflect how your team actually controls inventory.

Connect unit status to buyer and collection records

Unit status should not stand alone. It should connect to buyer records, reservation details, sales records, and collections visibility.

For example, if a unit is reserved, the team should be able to identify:

• The buyer connected to the reservation
• The agent or sales team handling the buyer
• The reservation date
• The reservation requirements still pending
• The approval status
• The payment or collection visibility needed by the team

If a unit is sold, management may need to monitor sales and collections data. Public iGotSolutions materials describe the Real Estate Development System as helping keep sales and collections data current. This matters because unit inventory is not only a sales list. It is also connected to revenue monitoring, buyer servicing, and project reporting.

Decide how to handle blocked units

Blocked units deserve their own rule set.

A blocked status is useful when a unit should not be sold for operational reasons, but is not reserved or sold. For example, management may temporarily hold a unit while reviewing pricing, allocation, project strategy, or internal requirements.

Your rules should answer:

• What are valid reasons for blocking a unit?
• Who can block a unit?
• Is blocking temporary or indefinite?
• Does a blocked unit appear in sales team's available inventory?
• Who can unblock it?
• Should blocked units be included in management reports?

Without these rules, blocked inventory can become a hidden problem. Units may stay unavailable longer than intended, or sales teams may become unsure which units can be offered.

Build approval flows before building reports

Many developers want better dashboards immediately. That is understandable. Management needs visibility across available, reserved, sold, and blocked inventory.

But reports are only as reliable as the workflow behind the data.

If reservations are approved inconsistently, reports will reflect inconsistent information. If cancellations are not reviewed, the available inventory count may be misleading. If finance and sales use different definitions of sold, the sales report and collection report may not match expectations.

Before finalizing dashboards, define the approval flow:

1. Who starts the transaction?
2. What information must be encoded?
3. Who reviews the details?
4. What conditions must be met before approval?
5. What status changes after approval?
6. What report should update after the status change?

This makes reporting more useful because every number comes from a defined process.

Prepare your data before migration

Digitizing inventory usually requires cleaning existing records. If your current files are inconsistent, upload planning becomes more important.

Before migration, review:

• Project names and phase names
• Block, lot, unit, or model naming conventions
• Unit type categories
• Price lists and effective dates
• Current unit status
• Buyer names and contact details
• Reservation records
• Sales records
• Collection references
• Cancelled or pending transactions

The goal is not to make every historical file perfect overnight. The goal is to avoid bringing unclear or duplicate records into the new system.

A ready-made real estate development system can help your team move faster compared with building software from scratch because the core system is already developed. However, the timeline still depends on customization scope, data readiness, user roles, approval rules, and reporting requirements.

Questions developers should answer before setup

Before implementing a digital project inventory workflow, gather your sales, admin, finance, and management teams. Discuss these questions:

Inventory definitions

• What statuses do we use today?
• Are the definitions the same across departments?
• Which statuses should appear in management reports?
• Which statuses should be visible to agents or sales teams?

Reservation rules

• What makes a reservation valid?
• What documents or details are required?
• What payment or validation step is needed?
• Who approves the reservation?
• When does a reservation expire or become cancelled?

Sales confirmation

• What makes a unit sold in our internal reporting?
• Who has authority to confirm the sale status?
• How should sales status connect with collection monitoring?
• What exceptions need management approval?

Cancellations and reopening

• Who can cancel a reservation?
• What reason must be recorded?
• Who reviews the cancellation?
• Can a cancelled unit automatically become available again?
• What should finance check before reopening?

User roles

• What can sales users view and edit?
• What can admin users approve?
• What can finance users verify?
• What can management override?
• What should be locked after approval?

Clear answers make implementation smoother and reduce the need for repeated policy changes during setup.

How a real estate development system supports clearer inventory control

A centralized real estate development system helps bring project inventory, reservations, buyer records, approvals, sales reports, and collections visibility into one workflow.

For developers, this can support:

• Real-time unit inventory visibility
• Smoother digital reservation processes
• Lower risk of double-selling through centralized status tracking
• More current sales and collections data
• Multi-project inventory monitoring
• Approval flows that match the company's process
• Better coordination between sales, admin, finance, and management

These are the kinds of operational outcomes iGotSolutions highlights for its Real Estate Development System. The system is publicly described as ready-made and production-ready, then customized around the developer's actual workflow.

The key is to avoid treating software as a magic fix for undefined processes. The strongest setup happens when the developer combines clear internal rules with a system that can reflect those rules.

A practical implementation mindset

When planning your digitization project, start with the workflow, not the screen.

Do not begin by asking only, what fields do we need? Ask:

• What decisions happen when a buyer chooses a unit?
• What checks are needed before the unit is held?
• What approvals protect the company from wrong status updates?
• What information does management need daily or weekly?
• What should sales see to avoid offering unavailable units?
• What should finance see to monitor collections properly?

Once these answers are clear, the system can be configured more effectively.

This is also why a generic tool may not be enough for growing developers. Real estate development has specific workflows: project setup, unit inventory, price lists, reservations, buyer records, approval flows, sales reports, collections visibility, and multi-project dashboards. A real estate-focused system is built around these operational needs.

Final checklist before digitizing unit inventory

Use this checklist before moving your unit inventory into a centralized system:

• Define every unit status your company will use.
• Write clear triggers for each status change.
• Assign who can update, approve, cancel, block, and reopen units.
• Connect unit status rules to buyer records and reservation records.
• Align sales and finance on what sold means internally.
• Decide how blocked units should be handled and reported.
• Clean project, unit, buyer, and reservation records before migration.
• Prepare management reports based on approved workflow rules.
• Train users so the team follows one process.
• Review rules after go-live and improve where needed.

Digitize with clearer rules and a system that fits your process

Available, reserved, and sold should not be loose labels. For real estate developers, these statuses control what the sales team can offer, what admin must process, what finance must monitor, and what management sees in reports.

When these rules are defined before digitization, the system becomes more than an online spreadsheet. It becomes a controlled workflow for project inventory, reservations, buyers, sales, collections, approvals, and reporting.

If your development team is still managing units, reservations, buyers, and collections through separate spreadsheets or scattered records, iGotSolutions can help you explore a Real Estate Development System customized to your project workflow.

Book a demo to see how iGotSolutions can help organize your projects, units, buyers, and collections.