Most CRMs were designed for a simple pattern: a customer has a deal, and the deal moves through stages and closes.
Real estate does not work that way. A single person can be a landlord on one property, a tenant on another and a buyer on a third. A property outlasts every deal done on it. A client’s requirement can exist for months before any specific property is involved. A deal often has two sides, several organizations and more than one agent.
Forced into a generic CRM, this produces workarounds. Below is where generic models break, and a property-centred model built from six record types.
Where generic CRMs break
The property has nowhere to live
In a generic CRM, the property usually ends up as a text field on the deal, or in the deal name. That works until the same property is listed again, leased to a new tenant, or comes up in a conversation with a different buyer. Each time, the history starts from scratch. Nobody can answer a simple question like “what have we done on this building?”
One person, many roles
A generic CRM tends to give each contact a single type: lead, customer, partner. Real estate contacts hold several roles at once, and those roles change. A tenant becomes an owner. A buyer’s lawyer refers the next client. A single type field forces agents to pick one role and lose the rest.
Requirements get lost
Before a buyer or tenant has a specific property in mind, they have a requirement: a use, a size range, an area, a budget, a timing window. A generic CRM has no natural home for this, so it ends up in notes. Notes cannot be searched by size or area. When a matching property comes up, nobody remembers who was looking for it.
Deals have more than two parties
A commercial lease can involve a landlord, a tenant, the tenant’s parent company, two brokerages, lawyers and a lender. A generic deal record has one “account” and one “contact”. Everything else is squeezed into notes or lost.
Follow-up is an afterthought
Generic CRMs treat tasks as optional reminders. In real estate, the next action is the work.
The six record types
A property-centred model separates the things that are genuinely different and connects them deliberately.
Contacts
A contact is a person. It holds identity and communication details: name, email, phone, preferred channel, consent status for marketing, and the agent responsible for the relationship.
What a contact does not hold is a single role. Roles come from the relationships the contact has to other records. The same person can be linked to one property as owner and to a requirement as the decision-maker.
Organizations
An organization is a company, trust, partnership or institution: a landlord’s holding company, a tenant’s operating company, a developer, another brokerage, a law firm. Contacts are linked to organizations with a role and a date range, so the CRM still knows that someone used to work at a tenant company after they move on.
Properties
A property is a physical asset that exists independently of any deal. Core fields include address, municipality, property type, size, zoning or permitted use where relevant, unit or suite structure, and current ownership.
For multi-unit or multi-tenant buildings, a property can have child records for units or suites. This matters for landlords and leasing teams, because each unit has its own tenancy, lease dates and history.
Properties link to organizations and contacts through roles: owner, property manager, tenant, previous owner. Over time, the property record becomes the firm’s memory of that asset.
Requirements
A requirement describes what a client is looking for, before or alongside any specific property. Typical fields:
- Transaction type: buy, sell, lease, sublease
- Use and property type
- Size range, with units
- Areas or submarkets
- Budget or rent range
- Timing: target date and how firm it is
- Must-haves and deal-breakers
- Decision-maker and source
Requirements are structured, so they can be matched against properties. When a new listing comes in, the firm can find every open requirement that fits it. When a requirement is entered, the firm can see which known properties already match.
Opportunities
An opportunity is a specific potential transaction the firm is working on. It usually links one requirement or one listing to one or more properties, and it carries the stage, estimated value, estimated commission, expected timing and outcome.
Opportunities link to many parties through roles: client, counterparty, co-operating brokerage, lawyer, lender. Each role is explicit. This is what lets the firm report on, say, every deal done with a particular co-operating brokerage, or every lease a particular landlord has signed through the firm.
One requirement can produce more than one opportunity. A tenant may negotiate on two properties in parallel before committing to one. Keeping requirements and opportunities separate lets the firm see that clearly.
Next actions
A next action is a dated, assigned piece of work tied to a record: call the landlord’s representative, send the shortlist, book the tour, chase the signed offer. Every open requirement and every open opportunity should have one.
Next actions differ from activity logs. The log records what happened. The next action records what will happen, who will do it and by when. A report of open records with no current next action is one of the most useful views a managing broker can have.
How the records relate
The relationships are what make the model work. In plain terms:
| Record | Links to | Through |
|---|---|---|
| Contact | Organizations | Employment or role, with dates |
| Contact or organization | Properties | Owner, tenant, manager, previous owner |
| Contact or organization | Requirements | Client, decision-maker, influencer |
| Requirement | Opportunities | The requirement the opportunity serves |
| Opportunity | Properties | The property or properties in play |
| Opportunity | Contacts and organizations | Client, counterparty, co-operating brokerage, lawyer, lender |
| Next action | Any record | The record the work is about |
With these links, these questions become simple:
- What has the firm done on this property, ever?
- Who is looking for a space like the one that just came available?
- Which tenants in our landlord clients’ buildings have leases ending soon?
- How many deals have we done with this co-operating brokerage?
- Which requirements have had no next action in the past two weeks?
A short example
The following is a hypothetical example, for illustration only.
A contact, Priya, works at a logistics company. She first appears as the decision-maker on a requirement: lease, industrial, a stated size range, two preferred areas, a target date about nine months out.
The firm enters the requirement and immediately sees three known properties that match. It creates an opportunity on the two that Priya wants to tour. Next actions are set: send floor plans, book tours.
A year later, Priya’s company buys a building. The property record now shows the logistics company as owner. When it later decides to lease out part of the space, Priya appears again, this time as the landlord’s contact. Her history, the building’s history and the firm’s relationship with her company are all connected. Nobody has to retype anything or search old emails.
Designing it without overbuilding
A property-centred model can be over-engineered. A few principles help:
- Start with the six records and the roles between them. Add specialized records, such as units, listings or leases, only when a real workflow needs them.
- Use controlled lists for anything you will report on. Property type, transaction type, stage, source, role. Free text is fine for notes, not for categories.
- Make a few fields mandatory at the right moment. Size and area at requirement creation; estimated commission at Qualified; closing date at Closed. Not everything at once.
- Assign an owner to every record. Shared ownership means nobody follows up.
Where to start
- List the questions you cannot answer today because the property or requirement has no record of its own.
- Sketch the six record types on one page and the roles that link them, using your own vocabulary.
- Pick one workflow, such as tenant representation, and model it fully before adding others.
- Decide which fields must be controlled lists, and agree their values with the team.
- Introduce one rule from day one: every open requirement and opportunity has a dated next action.
Multiunit builds real estate CRMs on exactly this structure, connected to the reporting that shows how the pipeline is moving. To talk about your current setup, use the Contact page.
This article is general information, not legal, financial or brokerage advice. Examples and figures are illustrative unless a source is given.