Commercial Real Estate CRM: What the Generic Tools Get Wrong About a Deal With Two Sides.
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.
What a generic pipeline assumes.
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.
Wrong thing one: a deal has two sides.
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.
Wrong thing two: the property is not an account.
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.
Wrong thing three: the stages are the wrong stages, and there are two sets.
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.
Wrong thing four: the fee is a plan, not a price.
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.
Why this is not an adoption problem.
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.
What good looks like.
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 here. The CRM was fine. The deal was the wrong shape.
The test to run this week.
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.
Find out where your deals, listings and commissions fall between systems.
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:
Comments