Salesforce for Real Estate: The Implementation Playbook for Brokerages

Most brokerage Salesforce projects fail the same way. The org goes live, the managing broker is happy for a month, and by quarter end the agents are back in their phones and spreadsheets. The pipeline in Salesforce is a lagging copy of reality, and the back office still reconciles commissions by hand.

The cause is almost never the software. It is that the org was built as a generic sales CRM with the words changed. Opportunity renamed to Deal. Account renamed to Property. That gets you a demo, not a brokerage system.

This is the playbook we use when a brokerage asks us to implement Salesforce for real estate. It covers what the org has to model, when to buy a package instead of building, and the rollout order that protects agent adoption.

Why a renamed Opportunity is not a Deal

A commercial deal has parties on both sides, a property, a listing that may or may not be yours, comps that justify the number, and a commission that splits across brokers, teams, and the house. An Opportunity has an Account, an Amount, and a Stage.

You can bolt custom fields onto Opportunity until it looks like a deal. Three things break when you do:

• Reporting. A broker wants production by property type and by deal side. The house wants GCI by month with splits applied. If the deal side, the property, and the split live in text fields on Opportunity, none of that is a report. It is an export.
• Relationships. One property has many listings over its life. One deal references one listing, many comps, and two or more brokers. Salesforce handles this well when those are separate objects with real lookups, and badly when they are fields.
• Automation. Hold expiry on a listing, a commission voucher on close, a comp record created from a closed deal. Each of these is a Flow on a specific object. If there is no object, there is nothing to trigger.

The brokerage-grade minimum is six objects: Property, Listing, Deal, Comp, Requirement (what a tenant or buyer is looking for), and Commission Split. Contact and Account stay standard. Everything else is optional until a report demands it.

Package or custom: the decision that sets the budget

There are two mature managed packages for commercial brokerages on the Salesforce AppExchange, and both ship the objects above in some form. Buying one is the right call more often than a consultancy likes to admit. Building custom objects is the right call in a narrower set of cases than a brokerage usually thinks.

Buy a package when:

• Your workflow matches the package's workflow. Tenant rep, landlord rep, investment sales, and capital markets are all covered by the leading packages. If you do those and only those, you are paying for a decade of other brokerages' edge cases.
• You have fewer than 50 users and no dedicated Salesforce admin. Packages come with upgrades and support you do not have to staff.
• Commission handling is your pain and the package already does splits, vouchers, and payouts.

Build custom objects when:

• Your deal structure does not fit. Mixed-use developers who also broker, brokerages that run property management, and teams whose "deal" is a multi-year lease program all hit the package walls fast.
• You already own a Salesforce org with heavy customization and an admin who can carry it. Adding a managed package on top of a custom org is where upgrade conflicts live.
• You need the data model to be yours. Packages own their objects. If you ever leave the package, the data migrates but the automations do not.

The honest answer for many brokerages is a package plus a thin custom layer: the package for Property, Listing, and Deal, your own objects for the thing the package does not model. We wrote a separate comparison of the two leading packages against custom objects, with their current AppExchange pricing, so the choice can be made on evidence.

The rollout order that survives contact with agents

Brokerage CRM projects die from adoption, not from bugs. Agents are paid on closings, not on data entry, and any system that asks for entry before it gives value will be ignored. The rollout order below is built around that fact.

Phase one: the back office first

Start with the people who are paid to be in the system all day. Deal administration, marketing, and accounting. Give them Property, Listing, Deal, and Commission Split with the reports they already produce by hand. When the commission statement comes out of Salesforce instead of a spreadsheet, the back office becomes the system's loudest advocate.

This phase also cleans the data. Every property and contact the back office touches gets deduplicated before an agent ever sees the org. Agents forgive a lot, but not duplicate contacts.

Phase two: give agents something before asking for anything

The first thing an agent sees in Salesforce should be a report or a page they could not get before. Their own pipeline with deal sides, their production against goal, comps on the property they are pitching this afternoon. Only after that do you ask them to log an activity.

Mobile matters here more than any other phase. If the agent cannot update a deal stage from the parking lot after a tour, the update happens never.

Phase three: automation that removes work

Now the automations that were the reason for the project. Listing expiry alerts, hold expiry that releases a listing back to available, a comp record created automatically on close, a commission voucher generated from the deal without anyone typing the split twice.

This is also where an AI agent earns its place. A portal lead that hits an inbox waits hours. A portal lead that hits an Agentforce qualification agent gets a reply and a qualified record in the CRM in seconds. We have built exactly that pattern for a commercial brokerage and documented it as a case study on this site, including the part where photos and documents stopped being retyped into the CRM at all.

Phase four: integration

Email and calendar sync should be live from phase two. Everything else waits until the data is clean and the agents are in. Marketing platforms, listing syndication, accounting, and document signing each connect to a specific object, and connecting them to a messy org copies the mess into three more systems.

What "done" looks like

A brokerage Salesforce implementation is done when three things are true:

1. The commission statement for last month came out of Salesforce, and accounting did not open a spreadsheet to check it.
2. The managing broker's Monday pipeline review runs from a Salesforce dashboard, not from asking each agent.
3. Agents log deal stage changes on their phones the same day, because the report they care about depends on it.

If any of the three is false, the project is not done, no matter what the go-live date says.

What it costs

We publish every price. A fixed-scope Real Estate Salesforce Quickstart for one team starts at $8,000, and the free Real Estate AI Audit comes first so the number is written down before you commit. Managed packages carry their own per-user licence on top of Salesforce, and those figures are in the comparison post.

Frequently Asked Questions

How long does a brokerage Salesforce implementation take?

For a single office on a fixed scope, a Quickstart is measured in weeks. A multi-office brokerage with commission automation and integrations typically runs 6 to 10 weeks, and the variable is almost always data readiness rather than build effort.

Do we need a managed package to use Salesforce for real estate?

No. Salesforce ships no native Property or Listing objects, so you either install a package that provides them or build them as custom objects. Both are common. The choice depends on how closely your workflow matches the package and whether you have an admin to carry a custom build.

Can Salesforce handle commission splits?

Yes, either through a package that includes commission processing or through a custom Commission Split object with Flow automation. What matters is that the split is a record tied to the deal, not a number typed into a field, so it can be reported and audited.

What is the biggest reason brokerage CRM projects fail?

Agent adoption. The rollout order in this playbook exists to fix that: back office first, value to agents before asking for entry, and automations that visibly remove work.