Should your CRM be where your business remembers things?

A seller walks you out to your car after a listing appointment and mentions, standing in the driveway, that her mother is moving in around March and that is really what is driving the timeline. She asks if you know a decent handyman. You say you will send two names. You drive off. Fourteen months later she calls, ready to go, and you have no idea what you promised her, when, or why March mattered.

You have a CRM. You pay for it every month. It did not lose that conversation, because it was never built to hold it.

Two jobs pulling against each other

A CRM that satisfied the right hand column would stop being good at the left hand column. Free text everywhere means nothing sorts. Records that never archive means the pipeline view fills with people who are not in a pipeline. The design constraint is real and the vendors are not being lazy.

What follows is that the second job needs somewhere to live, and in most businesses it lives in a phone note, a text thread, and the head of the one person who was there.

The question what is your CRM usually has more than one answer

This is more common than the software category admits. One system arrives with your brokerage or your franchise and you cannot switch it off. A second gets adopted because the team will use it. A third still holds four years of history from before the last move. Ask where a given client lives and the honest answer is two of the three, differently.

That matters here because the usual advice, put everything in your CRM, assumes there is one and that you chose it. For a large number of working agents both halves of that assumption are false.

The sorting problem hiding in your contact list

Most contact databases are sorted on one axis, and that axis is warmth. Hot, warm, cold. A tier, a letter grade, a star rating. Whatever it is called, it is one dial running from people you know well to people you barely know.

One axis hides an inversion, because two separate things are going on in a sphere and warmth mixes them together. The first is the strength of the relationship. The second is how close that person is to a move.

Split them apart and the shape of the list changes. The small group with a strong relationship near a move holds nearly all the revenue in the database. The large group with a weak relationship far from a move is roughly 80 percent of most lists and is worth close to nothing. One axis makes those two groups look like the same list, ordered.

How a promise gets recorded

The mechanism we use is a PAD vault, worth explaining because you can build the whole thing yourself in an afternoon with no software purchase. PAD is People, Assets, Deals. Three folders of plain text files on your own computer. One file per person, forever. One per asset, meaning anything that appreciates or decays depending on whether it is maintained. One per deal, meaning work that closes. Alongside them sits an operating file, a plain document telling an AI assistant how to work inside the three folders.

The promise rule has one sentence at its center. A promise is recorded on the person it was made to, and nowhere else. A deal links to it and never carries its own copy, because two copies means two truths and one goes stale without announcing it.

Every promise carries four things: direction, the words as they were said, the date, and the source. Direction means owed by you or owed to you, and it is the one people leave out. Something you promised is yours to move and can be called late. Something you asked of somebody else stays open, waiting or pending, however long it has sat, and calling that overdue reads as though you were at fault for an open loop belonging to somebody else.

State changes by addition and never by edit. Open, done, dropped, snoozed, each a new dated line in the words you would use. You never go back and change the original. A later read then shows why something left the list, which is the difference between a record and a checklist.

Here is the driveway conversation, written down. An illustration rather than a real client file.

• 2025-04-18, owed by me: send two handyman names. Source: listing appointment, said in the driveway on the way to the car.
• 2025-04-19, done: sent both names by text.
• 2025-04-18, context: her mother moves in around March, which is what is driving the timeline. No task, no stage. Kept because it is the reason for everything that happens later.
• 2026-01-06, owed to me: she said she would confirm the March date once her brother had spoken to the care home. Open. Asked once. Never overdue, because it was never mine to move.

Four lines of plain text. When she calls fourteen months later you open one file and you know what you said, when, what she said, and what is still hanging. No CRM field on earth was going to hold the third line.

A promise made to a company goes on a person

You did not promise the builder. You promised Dana at the builder, who was standing in the model home when you said it, and Dana is the one who will hold you to it. An entity does not remember. A person does.

So the promise lands on the person file. When Dana leaves, it moves by adding a dated line naming who holds it now. You do not edit the original, because the original is the record of what happened. When nobody can be named, that is the moment to ask rather than guess.

This holds across a referral business. The promise to the title company is a promise to the closer you always work with. The promise to the lender is a promise to the loan officer. Put it on the company and it evaporates the day somebody changes jobs, which in this industry is roughly always.

What goes where

What this does not fix

The question in the title has a short answer. Your CRM should be where your business tracks what happens next. Somewhere else should be where your business remembers. Most people run the first one and hope it quietly does the second, and it has never once done that, for anybody.