Your CRM doesn't know what a transaction is

Pull up a contact in almost any real estate CRM and look at what it knows.

Name, contact details, source, some tags. A timeline of emails and calls. A stage on a pipeline. Maybe a lead score, maybe some notes from a showing eight months ago.

Now ask it when the inspection contingency expires.

It has no idea. It doesn’t know there’s a deal. As far as the CRM is concerned, this person moved to a stage called “Under Contract” and then, weeks later, to one called “Closed,” and the entire substance of what happened in between took place somewhere else.

Why it’s built this way

Not because anyone decided it should be. It’s an accident of when these products were built and who bought them.

CRMs were sold to agents to solve lead follow-up. That was the problem in 2010 and it’s still a real problem. Transaction management was sold to brokerages to solve compliance — brokers carry the liability for file completeness, so brokers bought the software, and it was designed around the review queue rather than around the agent.

Two different buyers, two different problems, two categories of product. The agent ended up with both and the job of joining them.

That made sense when they were both simple. It makes less sense now that a CRM costs $69 a user and a transaction platform costs another $35 and neither one can answer a question about the other.

What the gap actually costs

Deadlines live outside your task list. This is the expensive one. Your inspection deadline, your financing contingency, your appraisal window: they’re in the transaction platform, which emails you about them. That email goes to the same inbox as everything else. Meanwhile your actual daily task list — the one you work from — is in the CRM, and it has no idea any of this exists.

Most agents catch these anyway, through diligence and a good calendar habit. But “most” and “anyway” are doing heavy lifting in that sentence, and the failure mode is expensive.

The past client is a stranger again. Eighteen months after closing, they call about selling. The relationship is in the CRM. The transaction — the actual thing you did for them, the property, the numbers, the problems you solved — is in a system you may not even still be paying for. So you go looking.

Nobody can tell you how long anything takes. Average days from contract to close. Which lender consistently runs late. Whether your file completion actually improved after you changed your process. All of these need transaction data joined to contact data, and if those live in two systems with no shared key, the analysis just doesn’t happen.

What it looks like joined up

A transaction as a stage of a relationship, not a separate object in a separate app.

The deal hangs off the contact. Its deadlines are tasks on the same list as your follow-up calls. Its documents sit on the same record as the emails you exchanged before there was a deal. When it closes, it doesn’t leave — it becomes part of what the system knows about that person, which is exactly what you want eighteen months later when they call.

And the AI, if there is one, can actually answer questions, because “who has a deadline this week and hasn’t been contacted in ten days” is a question that only makes sense if one system knows both halves.

That last one is worth dwelling on. A lot of the AI in this category is bolted onto a CRM that only knows about leads, so it can draft follow-up emails and not much else. An assistant that can see the pipeline and the deals and the calendar is a different animal, and the difference isn’t the model. It’s the data model underneath it.

The counterargument

There’s a real one, and it’s worth stating.

Brokerage compliance is a specialised job. SkySlope and its peers have spent years on review workflows, state-specific requirements and audit trails, and a broker signing off on four hundred files a year has needs that a general-purpose system doesn’t cover as deeply. If compliance at scale is your primary problem, the specialist tool exists for good reasons.

There’s also a network effect in transaction software. dotloop is easier when the agent on the other side of the deal is already on dotloop. That’s genuinely valuable and it’s the strongest argument for staying put.

So the honest position isn’t “transaction platforms are obsolete.” It’s that the split was never designed, and most agents inherited it rather than choosing it. Worth asking whether you’d choose it now.

If you want to test this

Take your three most recent closings. For each one, count how many separate systems you’d have to open to reconstruct the full story: first contact, showings, offer, contract, deadlines, documents, closing.

If the answer is one, you’re in good shape and you can ignore all of this.

If it’s three or four, that’s the shape of the thing. Whether it’s worth changing depends on how often you actually need that story — which, if you do any repeat or referral business at all, is more often than you’d think.