A generic CRM models a deal as one record moving through one pipeline with one owner. A commercial real estate deal is none of those things. It has two sides, often two brokers, a property that outlives the deal, a client who is a company one week and a landlord the next, and a fee that is decided by a plan rather than a price. Most brokerages run their business on a CRM that cannot see any of that, and then wonder why the CRM is the one system nobody trusts.
This post is about the shape of a commercial real estate deal, the four places a generic pipeline gets it wrong, and what a CRM that fits the business actually looks like. It is written for the managing broker or operations lead who has been told the CRM problem is an adoption problem. It is not. It is a modelling problem.
Every mainstream CRM ships with the same deal object: one name, one amount, one stage, one owner, one close date, attached to one account and some contacts. That object was designed for a software sale, where a rep works a single buyer through a single decision to a single price. It is a good model for that business.
Apply it to a brokerage and four things break at once.
A lease or a sale has a landlord side and a tenant side, a seller side and a buyer side. A brokerage may represent one or both. When it represents both, two brokers in the same firm are working the same deal from opposite ends, with different clients, different activity, different fee arrangements and different information rights. When it represents one, the other side is an outside broker whose co-broke has to be recorded against the deal.
A generic pipeline has one owner field. So the second broker becomes a note, a custom field, or a second deal record with the same property and half the story. Every downstream report, from pipeline by broker to commission by side, is then built on a record that is structurally incapable of being right. We wrote about what that does to payouts in the piece on brokerage commission reconstruction, and it starts here, at the deal object.
The fix is not a field. It is a deal record whose sides are first-class: each side with its client, its broker, its share and its source, both attached to the one deal, so that a two-sided deal is one record with both ends and a one-sided deal is the same record with an outside broker on the other end.
In a software CRM the account is the customer and it persists; the deal is transient. In a brokerage the persistent thing is the property. It gets leased, the tenant leaves, it gets leased again, it sells, the new owner leases it. Five deals over ten years, one building. The tenant of one deal is the prospect of the next. The landlord is a client on the listing side today and a buyer next year.
A generic CRM forces the property into the account slot, or into a custom module bolted onto deals, or into the listing platform where the CRM cannot see it. Then the history that makes a broker valuable, who has been in this building, who is coming off lease when, what the last deal cleared at, is spread across systems and memory. The property should be its own record, the deals hang off it, and the parties on each deal are contacts and companies that can play a different role on the next one. Our commercial real estate CRM development piece describes that model in detail.
The default stages are qualification, proposal, negotiation, closed. A brokerage deal moves through tour, proposal, letter of intent, lease draft, execution, commencement, and on a sale through offer, contract, due diligence, closing. The listing side and the procuring side are not always at the same stage: the landlord side is negotiating with three prospects while each prospect's side is at a different point. One pipeline with one stage per deal cannot represent a listing with three live procuring sides.
This matters beyond tidiness. The stage is where a brokerage's process rules should live: no letter of intent goes out without the approved template, no deal reaches execution without the signed agreement on file, no commission is computed before the lease is executed and dated. In a generic pipeline those rules are training. In a CRM modelled for the business they are enforced, which is what a blueprint is for, and which is why we typically put contract execution inside the CRM rather than beside it.
The amount field on a generic deal is a price. A brokerage fee is a calculation: a percentage of consideration over a term, sometimes stepped, split by side, split again inside the firm by a plan that depends on the broker's production, less chargebacks, paid in instalments contingent on events. Put a single number in the amount field and every report that sums it is wrong; leave it blank and the CRM has no idea what the business is worth.
The fee has to be a structure on the deal, defaulted from the commission plan when the deal is created and edited when terms change, with the edit logged. Then the pipeline report shows expected fee by side and by instalment, the forecast is real, and the payout at closing is a read, not a reconstruction.
The usual diagnosis, when brokers will not use the CRM, is that brokers do not like CRMs. The honest diagnosis is that the CRM asks them to describe a two-sided, property-centred, plan-priced deal in a form built for a one-sided, account-centred, fixed-price sale. It is not that they will not do it. It is that the form is wrong, so what they enter is an approximation, so the reports are approximate, so nobody reads them, so there is no reason to enter anything. Adoption follows the model. Fix the model and the adoption problem mostly stops being a topic.
A commercial real estate CRM that fits the business has a short list of properties.
Property is a record. Deals hang off it; parties change roles across deals; the history stays with the building.
Deals have sides. Listing and procuring, each with its own client, broker, share and source; an outside broker is a side, not a note.
Stages match the work, per side. Tour to commencement on a lease, offer to closing on a sale; the rules that gate each stage are enforced, not remembered.
The fee is a plan applied at creation. Expected fee by side and instalment is on the record from day one, and the payout is a read at closing.
The listing data lives once. The marketing platform reads the property from the CRM, or the CRM reads it from the listing system, but nobody keys it twice. Where market data such as CoStar feeds the record, it arrives through an integration rather than a paste.
Accounting is downstream of the deal. Invoices and broker payables post from the deal's own fee structure.
None of this requires a specialist CRM. It requires a general one, configured by someone who has modelled the business rather than the demo. The brokerage we did this for came to us to fix a CRM nobody used, and the story of what we found is in the brokerage CRM article. The CRM was fine. The deal was the wrong shape.
Open your CRM and find a deal your firm worked from both sides in the last year. Count how many records it took to represent it, how many of the four items above are fields rather than notes, and whether the fee on the record matches what was paid. If it took two records, the sides are notes and the fee does not match, the problem you have is the one this post describes, and it is a modelling job of a few weeks rather than a change-management program of a year.
We run discovery for that job at no risk: you pay for it only if you proceed. What comes out is a deal model drawn from your own last twenty deals, a stage map per side with the rules that belong on each stage, and a guaranteed estimate to build it into the CRM you already pay for. If we estimate low, we absorb it.
In a no-risk discovery we look at how a deal moves from listing to commission across your CRM and accounting today and show what one connected system would change. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Commercial Real Estate CRM Development: When a Generic CRM Stops Working (article)
Your Forecast Is Wrong Because Nobody Configured A Pipeline | Zoho CRM Stage Probability (video)
The property is a persistent record with its own history. Deals hang off the property, and each deal has two sides, each with its client, its broker, its share and its source. Companies and contacts can play different roles on different deals: tenant on one, landlord on the next. The fee is a plan attached to the deal, not a single amount. Stages exist per side, because the landlord side and the tenant side move at different speeds.
Because the standard deal object has one owner, one amount, one stage and one account. A lease has two sides with two brokers and two clients, a property that outlives it, and a fee decided by a plan. Forcing that into one record loses the second side, the co-broke and the property history. Reports built on the record cannot be right, so brokers stop trusting them, which gets misdiagnosed as adoption.
As a side of the deal. When the brokerage represents one side, the other side's broker is an outside firm recorded on that side with its percentage. When the brokerage represents both, two internal brokers appear, one on each side. Either way the deal is one record with both ends, so commission by side, pipeline by broker and referral tracking all read from the same place.
Stages that match how a CRE deal moves, not a software sales cycle. For a lease, something like tour, proposal, letter of intent, lease out, executed and commenced. For a sale, offer, contract, due diligence, closing. And there are two sets, because each side of the deal has its own stage. A single stage field inherited from a generic template cannot describe where a two-sided deal actually is.
Pick a recent two-sided deal and try to answer three questions from the CRM alone: who was on each side and what was each broker's share, what other deals has this property had, and what was the fee plan and when does each installment pay. If any answer requires a spreadsheet or an email search, the CRM is not modelling the deal; it is storing a label for it.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
