Why general CRMs struggle in real estate

General-purpose CRMs are designed for products and services that can be sold repeatedly. You can sell one software licence to a hundred customers; you cannot sell the same apartment twice.

That single difference changes the core of the system. In real estate every row is an asset with exactly one state: available, on option, reserved, contracted or sold. Two representatives marketing the same unit is not a merge conflict — it is a commercial problem.

Teams usually try to emulate this in a general CRM with custom fields and automations. The typical result: inventory truth lives in a spreadsheet, customer history lives in the CRM, payment plans live in accounting, and the three disagree.

The core a development sales CRM must carry

These are the capabilities a real estate sales system needs by design rather than as a later bolt-on:

  • Unit inventory: block, floor, type, area, aspect, price and state
  • State lifecycle: available → option → reservation → contract → sale
  • Locking and authority logic that prevents collisions on the same unit
  • Pricing authority and discount approval: who may grant what
  • Payment plan generation: deposit, instalments, interim and handover payments
  • Presentation history: which unit was shown to which customer and when
  • Commission and entitlement calculation across representative, team and agency

What MPANDO Sales OS covers

MPANDO Sales OS is a real estate sales operating system built around that core. Project inventory, customer records, offer and approval processes, payment plans, presentation flow, analytics and commission calculation run in one structure.

What distinguishes it is that it shares an ecosystem with the MTWIN digital twin. While a representative walks a buyer through the twin, the price, state and payment options for the selected unit are visible on the same screen. The offer is generated from that same flow.

This consolidation replaces what a conventional setup handles with three separate tools: a presentation deck, an inventory spreadsheet and a CRM.

Who it fits

Sales OS is designed for developers selling their own schemes and for sales organisations running development sales.

  • Developers of residential and mixed-use schemes
  • Sales and marketing firms focused on new-build project sales
  • Teams running multiple phases or multiple projects concurrently
  • Organisations selling to overseas buyers with multilingual processes
  • Structures selling through agency or broker networks that need commission splits

Decisions to settle before go-live

A sales system's success depends heavily on initial configuration decisions. These should be settled before deployment.

  • Which is the single source of truth for inventory — the system or the spreadsheet? It cannot be both
  • Who can change a price, and what approval does it pass through?
  • How long does an option last, and what happens when it expires?
  • At what stage is commission earned — reservation, contract or collection?
  • Which reports go to whom, and how often?