Choosing a real estate CRM for developers: what a new build sales CRM must do

Why a generic CRM quickly hits its limits on new builds

Most systems are built around a contact and a deal: a person enquires, a salesperson calls them, the deal closes. In a new build, the centre of gravity is elsewhere. The buyer chooses from a limited number of units, each with its own price, floor, area, orientation and an associated parking space or storage room, and each can be sold only once.

So the question of how to choose a CRM is really a question of whether the system treats a unit as a standalone record with its own status. If it does not, the real state of the project ends up in a spreadsheet on the side. That is the most common source of double bookings and mismatched prices.

A developer also has several stakeholders: an in-house sales team, external agencies, a project manager and finance. All of them need the same picture of the current position, each with different viewing rights.

Unit linking: the central criterion in a new build sales CRM

When choosing, check whether you can create a unit as an object with its own fields and link it to several prospects. The link must work in both directions: on the buyer’s card you see which units interest them, and on the unit’s card you see who else is competing for it and who holds an active reservation.

Pay particular attention to ancillary parts. In Slovenia, parking spaces and storage rooms are often sold separately, while in Germany and Austria they more commonly come bundled with the unit, so the system needs to support both models.

• a unit as a record with floor and number fields, plus area, price, orientation and status
• ancillary parts (parking, storage, garden) as an attachment or as standalone units
• several prospects on one unit, but only one active reservation
• a history of price and status changes, with date and user
• import and export of the price list from a spreadsheet
• several phases or buildings in the same project, without duplicating accounts

Statuses: separate the buyer’s status from the unit’s status

A common mistake is to use a single set of statuses. In reality you need two. The buyer moves through steps such as new enquiry, contacted, viewing completed and offer sent. The unit has its own state: available, reserved, preliminary contract or Reservierung, sold, temporarily unavailable.

A reservation must have an expiry date and a reminder when it lapses. Without this, units stay reserved for weeks after the buyer has already dropped out. For the DACH market, add the steps dictated by the process: Notartermin, Beurkundung and payment milestones under the Bauträgervertrag. In Slovenia, these correspond to the preliminary contract, the deposit and the sale and purchase contract.

It helps if a change in unit status triggers the next action: a notification to the salesperson, an update of the public availability display and a task to prepare the contract.

Integrations: what a real estate CRM must accept and send

A CRM is not an island. Enquiries arrive from the project website, listing portals, email and telephone, while data on sold units has to flow on to finance and contract documentation. Check whether the system has an open API or webhooks and working built-in connections, not just a promise of integration.

The greatest benefit comes from a shared unit code. In projects where ARHIX connects an interactive building model to the CRM, the buyer selects a unit in the browser and the enquiry arrives in the CRM with the exact floor and unit reference. The salesperson knows what the conversation is about before picking up the phone.

For the DACH market, data protection matters too. Require data storage in the EU, a data processing agreement and the ability to delete data at an individual’s request, since GDPR and DSGVO are taken for granted by buyers.

• website forms that pass on the unit and the source of the enquiry
• email and calendar for viewing appointments
• a digital sales platform or 3D view that records which units the buyer opened
• electronic signature and contract storage
• accounting or ERP for payment milestones
• a buyer portal showing the status of their unit

Reporting: what a developer really needs

A report is useful only if it answers a decision. A developer needs to know where sales are stalling, which channel brings serious buyers and which units remain unsold, and why. A system that can only draw a general funnel struggles to show this.

Check whether you can filter reports by project, building, floor, unit type and agency, and export them for the board or a lender. It is also important that reports are built on the same data as day-to-day work, not on manually prepared exports.

• availability and occupancy by floor and unit type
• funnel from enquiry to contract by project and source
• time between enquiry, viewing and reservation
• reservations that have expired or are about to
• comparison of agencies and channels by completed sales
• planned and received amounts by payment milestone

When your existing CRM is enough

If a CRM is already running in your company, there is no need to replace it just because a new project has appeared. It is enough if it allows custom objects or tables in which you can enter units, if you can manage unit statuses separately from buyer statuses and if it has an API for connecting to the website.

It is usually also enough for a smaller project with one phase, one sales team and no external agencies. There, the cost of introducing a new system outweighs the risk of errors.

Replacement makes sense when salespeople still manage units in a spreadsheet, when double bookings occur or when the board cannot get an overview without manual reconciliation. Before you decide, run a two-week trial with the real price list of one building.

Common mistakes and a checklist

Most problems arise because a system is chosen for the look of its interface, not for its data model. Before signing the order, check the points below in a demo environment filled with your own data.

If the system fails on several of these points, sales will in practice run around it.

• Can you import a price list of 40 or more units in a single operation?
• Does the system prevent a double reservation of the same unit?
• Does a reservation have an expiry date and an automatic reminder?
• Does an agency see only its own buyers and the available part of the offer?
• Can all data be exported if you change supplier?
• Who on your side will maintain the fields, statuses and permissions?

Next steps

Start by describing the process on a single sheet: from first contact to the notary or contract signing, with status names and responsible people. Then compare that description with your current CRM and mark where data gets lost.

If you find that you are missing only units and integration with the website, adapting your existing system is usually faster than replacing it. If the gaps are wider, you now have the criteria for a requirements document to send to suppliers.