What Data a Unit Selector Actually Needs

Unit selector projects are scoped as design work and delivered as data work, which is why the schedule slips in the middle rather than at the end.

The interface takes a predictable amount of time. Assembling a unit schedule that is accurate, complete and internally consistent takes as long as it takes, and on most developments the information starts in four places that disagree with each other.

This is a specification of what is actually needed, written for the person assembling it rather than for the person commissioning it.

The minimum viable schedule

Six fields per unit. Without these there is nothing to build.

Unit reference. One canonical identifier, used consistently across the drawings, the price list, the sales system and the tool.

Type reference. Which plan this unit is, since the plan is shared across many units and the tool needs to know which to show.

Floor or level. Numbered consistently, including how mezzanines, ground and any skipped floors are handled.

Internal area. Stated on one measurement basis, with the basis named.

Bedrooms. The primary filter for almost every residential buyer.

Status. Which state the unit is in, from a defined list rather than free text.

The fields that make it useful

These separate a working tool from a functional one, and they are the ones most often missing at handover.

Aspect or orientation. Which way the unit faces. Cheap to record, constantly asked about, and absent from a surprising number of schedules.

External area. Balcony, terrace or garden, stated separately from internal. Buyers compare it explicitly and combining the two misrepresents both.

Position in plan. Corner, end, mid, adjacent to core. Frequently inferable from the drawing and worth recording explicitly so the tool can use it.

View description. By floor band or by aspect rather than per unit, which keeps it maintainable.

Price. With the basis clear, and with a note on whether it is current or indicative.

Parking and storage. Included, optional or unavailable, which varies by unit in many developments and drives real enquiries.

Availability date. For anything not immediately available, which matters more in leasing and in phased delivery.

The state list is a decision, not a field

The part of the schedule that requires a conversation rather than a lookup.

Available, sold and reserved are the states everybody has. The useful schedule also distinguishes: held without deposit, reserved with an expiry date, contracted but not completed, released for sale, not yet released, allocated to a broker or preview group, and withdrawn.

Not every development needs all of them. Every development needs the list agreed before the tool is built, because the states determine the interface, the permissions and what the public sees.

The test is simple: ask the sales team to describe every situation a unit can be in, and check that the list covers all of them. Anything missing will be tracked outside the system, and that is where errors originate.

Content the selector displays

Data alone produces a table. The content is what makes it a selector.

A marketing floor plan per type. Drawn for display rather than construction, with dimensions and room labels.

At least one rendering or image per type. Ideally the primary living space, since that is what buyers want to see.

A building diagram or plan geometry. The spatial layer the selector is built on.

Specification by type or tier. What is included, which is the question most likely to send a buyer to a phone call.

View imagery or description by floor band. Where view drives price, which in tall buildings it does.

If this content does not exist, producing it is the majority of the project and it should be scoped as such rather than discovered during the build.

Where the data usually lives, and why it disagrees

On a typical development the same information exists in several places, each maintained by different people for different purposes.

Reconciling those is the real work, and it should happen once, deliberately, before the tool is built. Doing it during the build means doing it under deadline with incomplete authority to decide which source wins.

Naming, which causes more trouble than it should

A small problem that becomes permanent if not fixed early.

Units are frequently identified differently across sources: a drawing reference, a marketing name, a sales system record number and a legal plot number. When those are not mapped, every conversation between systems requires translation and every export introduces a chance of error.

Pick one canonical reference for the tool, map it explicitly to the others, and record the mapping somewhere durable. It takes an hour and it prevents a category of confusion that otherwise persists for the life of the development.

What happens when data is missing

Assembling it without doing it twice

Four practices that work.

Build one schedule, not several. A single spreadsheet or table that becomes the source for the tool, the brochure and the price list, rather than three that drift.

Record the drawing revision it came from. So a later discrepancy is traceable rather than mysterious.

Fill every column, including uncertain ones. Marking a value as provisional is far more useful than leaving it blank, because blank is indistinguishable from not applicable.

Get sales to review it before it is used. They will spot units that are actually held, prices that changed, and types that were reconfigured, which is exactly the drift a documentary process misses.

One boundary worth stating

Assembling this data well does not sell units. Unit selectors support a sales process, they do not obtain approvals and no vendor obtains approvals or can guarantee them.

What good data does is narrower and reliable: it lets the tool be built once rather than reworked, it prevents the parallel spreadsheet that causes double bookings, and it means the answers a buyer sees are the same answers the sales team would give. That last one is the whole point, and it is entirely a data problem rather than a design one.

Area measurement, which causes disputes

Worth isolating because it is the field most likely to produce a complaint after contract.

Internal area can be measured several ways, and different sources within the same development frequently use different bases. Whether balconies are included, whether internal walls are counted, whether the measurement is to the internal face or the centre line, whether common area is apportioned.

A buyer comparing your unit against another development is comparing numbers that may not be measured the same way, and a buyer who later measures their own home is comparing against whatever you published.

The practical requirement is to state the basis explicitly alongside the figure, keep external area separate, and use one basis consistently across the drawings, the price list, the brochure and the tool. That consistency is worth more than precision, because a number that is slightly conservative and consistent creates no problems while a number that varies by source creates several.

Fields that change and fields that do not

A useful distinction when designing the update process, because they need different handling.

Fixed for the life of the development: unit reference, type, floor, area, aspect, position. These are set by the building and should be entered once, carefully, from the drawings.

Changes occasionally: plan assignment if types are reconfigured, specification tier, parking allocation. Handled as amendments with a record of what changed.

Changes constantly: status, price, availability date. These need an owner and a mechanism, and they are the reason integration matters.

Treating all three the same is a common design error. It produces a system where changing a price requires the same process as correcting a floor area, which makes people avoid using it.

A schedule template that works

One row per unit, with columns grouped by how they behave.

Identity first: unit reference, type reference, legal or plot reference if different, floor. Then physical: internal area with basis, external area, bedrooms, bathrooms, aspect, position. Then commercial: status, price, availability date, parking, storage, specification tier. Then content: plan file reference, image reference, view description reference.

Keeping content as references rather than embedded means the images and plans can be updated without touching the schedule, which matters because they usually are.

Add a revision column recording which drawing set each row was verified against. It looks bureaucratic and it is the thing that resolves an argument two years later in about thirty seconds.

Who should assemble it

A question that determines quality more than any tooling decision.

The schedule needs somebody who can read a drawing set, understands the commercial structure, and has authority to decide which source wins when they disagree. That combination is rarer than it sounds and it is frequently nobody's job.

The architect is authoritative on geometry and typically has no view on pricing, status or marketing names.

Sales knows what is actually happening and rarely has time to reconcile drawings.

Marketing owns the output and usually lacks the technical reading to verify areas against a plan.

A project manager or development manager is usually the right owner, because they span all three, and assigning it explicitly rather than assuming it happens is what separates a clean schedule from a reconciled-under-deadline one.

Verifying before you build on it

Four checks that take an afternoon and prevent the errors that surface publicly.

Areas against the drawings. Spot check ten units across different types. Drift between the price list and the plans is common and it is the error buyers are most likely to find.

Counts. Does the number of units in the schedule match the number in the building. It sounds trivial and it catches missing rows regularly.

Aspect against the site plan. Easy to get wrong when transcribing and easy to verify.

Status against sales. Read the list back to the sales team. They will correct things nobody else knows.

Keeping it accurate afterwards

The schedule is not a one off document, and the developments where it stays reliable do three things.

One source, not copies. The moment somebody exports a version to work on, two versions exist. Whatever holds the schedule should be edited in place by everybody who needs to.

Changes recorded, not just made. Knowing that a price changed is useful. Knowing when, by whom and from what is what lets a discrepancy be traced rather than argued about.

Periodic reconciliation against the drawings. Buildings change during construction. A unit reconfigured on site and never reflected in the schedule produces an image and an area that stop matching the home somebody bought.

That third one is the least done and the most consequential, because it is the error a purchaser discovers at handover rather than a prospect discovering it online.

Frequently asked questions

What is the minimum data a unit selector needs?

Unit reference, type reference, floor, internal area, bedrooms and status. Without those six there is nothing to build. Aspect, external area, view, price, parking and availability date are what make it useful rather than merely functional.

Why does the state list matter so much?

Because the states determine the interface, the permissions and what the public sees. Anything the sales team tracks that the system cannot represent gets tracked outside it, and that parallel record is where double bookings originate.

Where does unit data usually live?

In several places that disagree: drawings are authoritative for geometry, the price list for pricing, the CRM for status, and an agent spreadsheet for what is actually happening. Reconciling them once before the build is the real work.

Why does naming cause problems?

Units are identified differently across drawings, marketing, sales systems and legal documents. Without an explicit mapping, every export risks error. Picking one canonical reference and recording the mapping takes an hour and prevents years of confusion.

What if the marketing plans do not exist yet?

Then producing them is the majority of the project rather than a prerequisite, and it should be scoped that way. A selector with no plans to show is a table with a diagram attached.