How does an interactive building model apartment selector work in multi-building projects?

Interactive building model apartment selector: what the buyer actually does

An interactive building model is a 3D view of a building in the browser. Instead of scrolling through a list, the buyer rotates the building, zooms in and clicks on a floor or a unit. Behind the scenes, each unit is linked to a database record: reference, area, number of rooms, orientation, balcony or terrace, status. The model is therefore first and foremost an interface to data, not just an attractive image.

Unlike a static facade rendering, the buyer chooses their own route. They pick a view of the building first, then a floor, then a flat. A click opens the unit card with the floor plan and, where available, a free-roaming 3D walkthrough of the interior.

Because the model runs in the browser with no installation, you can embed it on the project website, send it by email or open it on a tablet during a conversation in the sales office. The link is the same for everyone and the display is identical, regardless of who opens it.

From building to unit: how navigation works

Typical navigation has three levels: building, floor, unit. At floor level, the model highlights the selected slab, so it is clear how the units are arranged around the stairwell and core. At unit level, the floor plan and the details the buyer needs for a first decision are displayed.

Filters shorten the journey. A buyer searching for “three rooms, south-facing, upper floor” does not want to click through every unit. The filter and the model must stay in sync: once the buyer sets their criteria, the matching units in the building are highlighted in colour and the rest fade out.

The unit card should contain only what has been verified and is actively maintained:

• a unit reference that matches the drawings and the contract
• net and gross area, plus the area of external spaces
• number of rooms, floor, orientation
• floor plan and, ideally, a free-roaming 3D walkthrough
• availability status
• price or a “price on request” button, depending on the developer’s decision

Availability: keeping unit status in line with reality

Unit status is the most sensitive piece of data in the model. If a buyer sees “available” but the unit is already reserved, you lose trust and, in the worst case, end up with a double commitment. So define a single source of truth: usually the developer’s CRM or sales list, with the model only reading the status.

In practice there are three ways to update it: manual entry in the model’s admin panel, import from a spreadsheet, or automatic synchronisation with the CRM. The first suits small projects; the third suits any project where several sales agents work at the same time.

Agree on terminology too. In German-speaking markets you will often see the trio frei, reserviert, verkauft; in the UK it is available, reserved, sold. If the model runs in several languages, the meaning of each status must be identical in all of them.

CRM connection: what is recorded when a buyer selects a unit

Selecting a unit in the model is a clear signal of interest. When the buyer submits an enquiry, the CRM records the contact together with the chosen unit, building, language and visit source. The salesperson can then call with knowledge of what the buyer actually cares about, rather than opening with a generic question.

A small set of fields is enough for a useful picture:

• contact details and a record of consent
• the building, floor and unit the buyer selected
• type of request: viewing, offer, reservation
• source and campaign the buyer came from
• interface language
• timestamp

Using a 3D apartment finder in multi-building projects

For a development with several buildings, an additional level is added above the building: a site plan or a combined model of the whole scheme. The buyer first selects a building, then a floor and a unit. Building names (A, B, C or Haus 1, Haus 2) must be identical in the model, the CRM, the price list and the contracts.

Buildings are rarely at the same stage. One is already on sale, another is in preparation, a third is only planned. For buildings not yet on sale, the model can show just an outline marked “in preparation” and collect contacts from interested buyers, without displaying individual units or statuses.

Consistent identification is key: every unit has a unique ID that is the same in the model, the CRM and the documentation. The same applies to garages, storage rooms and parking spaces that can be sold separately. At ARHIX, we therefore treat them as standalone units linked to the flat, not as a note on the card.

Common mistakes and a checklist

The most common mistake is a model that is really an image with clickable areas: it looks similar, but without a database behind it, statuses cannot be maintained reliably. The second is manual updating with no one responsible, so the data lags behind sales.

Before launching the project, check:

• whether every unit has a unique ID that matches the documentation
• whether a single source of truth for status has been defined
• whether the model works smoothly on a mobile phone
• whether every unit has a floor plan, not just a label on the facade
• whether the form includes clear GDPR (DSGVO) consent
• whether building and status names are the same in all languages
• who updates the data after a reservation, and how quickly

Next steps for a 3D building view in sales

If you are still planning the project, start with the data, not the visuals: put together a list of units with IDs, statuses and areas, and decide where the source of truth sits. Only then does it make sense to choose the level of visual detail.

For larger projects, it is worth starting with a pilot on one building, checking the path from click to CRM record and only then extending the model to the remaining buildings. To get a feel for how a buyer uses the view in the browser, you can try the public demo of a free-roaming 3D walkthrough of the ARHIX sample house: https://moderna-hisa-3d.netlify.app/.