Should a CRE firm use a CRM, a project tracker, or both?
Both — but treat them as one system of record, not two apps. A CRM (customer relationship management: the record of deals, contacts, and pipeline) and a project tracker (the record of tasks, milestones, and hand-offs) describe the same deal at different stages. Split them and you re-key the same data twice and lose the thread at every hand-off.
Most commercial real estate (CRE) firms already run some version of both — a spreadsheet for the pipeline, a shared drive for the deal files, someone's inbox for follow-ups. The problem is rarely a missing tool. It's that the tools don't share a record, so the deal lives in three places and agrees with itself in none of them.
Why the split hurts
- A prospect becomes a signed deal, and nobody copies the terms into the tracker.
- A deadline slips because the person chasing it never saw the pipeline note that moved it.
- Leadership asks "where does this deal stand," and the answer depends on who you ask.
What does a CRM actually do for a CRE firm?
A CRM gives a CRE firm one place where every contact, property, and deal has a current state — owner, broker, tenant, stage, next action, and who owns it. It replaces the "check three inboxes" answer with a single record. Its job is memory: the firm stops forgetting follow-ups because the follow-up lives on the deal, not in a head.
For CRE specifically, the record isn't just "companies and contacts." It's parcels, entitlements, LOIs, lease terms, and closing conditions. A generic sales CRM models a widget sale; a CRE record models a deal that runs for months across brokers, counsel, lenders, and jurisdictions.
The payoff is boring and real: nothing gets dropped between the person who sourced the deal and the person who has to close it.
What does a project tracker add?
A project tracker turns a won deal into a list of who-does-what-by-when: due diligence tasks, entitlement filings, financing milestones, and closing steps, each with an owner and a date. The CRM tells you the deal exists and where it stands; the tracker makes the work happen and shows what's late.
The two are the same record read at different depths:
- CRM view: "This deal is in diligence, closing targeted for Q2."
- Tracker view: "Environmental report due Friday, title commitment received, estoppels outstanding."
When both read from one record, moving a closing date automatically moves the dependent tasks. When they're separate systems, someone has to remember to update both — and eventually, someone won't.
How should CRE firms set up personalized dashboards?
Build dashboards as filtered views of the one shared record, not as separate databases. A dashboard is a saved question — "show me my deals, sorted by next action" — answered live. Give each role its own question. Nobody should export to a spreadsheet to see their own work.
Set them up by role and by the decision the person makes each day:
- Broker / originator: my active pipeline, deals with no next action set, follow-ups due this week.
- Deal lead / analyst: deals in diligence, tasks past due, missing documents by deal.
- Principal / partner: total pipeline value by stage, deals stalled 30+ days, closings this quarter.
- Operations: every deal missing an owner or a date — the governance view that catches what fell through.
The rule: a dashboard should surface a decision, not just display data. "Deals with no next action" prompts someone to act. "Total deals: 47" does not.
Where does governance fit — and why "propose, never commit"?
Governance is the difference between a system that helps and a system that quietly acts on your firm's behalf. Vantrow's principle is propose, never commit: the system can draft the follow-up, stage the status change, and flag the missing estoppel — but a person approves before anything is sent or recorded, and every action lands on an audit trail.
That matters most where CRE firms are tempted to automate: intake, follow-up, and status updates. You want the desk to prepare the work so nobody re-keys it. You do not want it silently emailing a lender or advancing a deal stage because a rule fired. Propose, then a human commits. The record stays trustworthy because a person, not a script, made the call — and you can see who, and when.
This is also what makes dashboards worth trusting. A dashboard is only as honest as the record beneath it. If actions land automatically and unchecked, the numbers drift. If every change is proposed, approved, and logged, the dashboard reflects reality.
What to do first
- Pick one record. Decide that the deal — not the inbox, not the spreadsheet — is the source of truth.
- Model your actual objects: parcels, deals, contacts, tasks. Not a generic sales funnel.
- Require a next action and an owner on every open deal. That single rule kills most dropped follow-ups.
- Build role dashboards as saved views over that record.
- Stage automation as proposals a human approves — never as silent commits.