Your CRM has no way for a record to leave

Open your CRM and look at the contact count. Whatever the number is, it has only ever gone up.

Every form fill, every imported list, every business card, every scrape, every “let me just add them so I don’t forget.” All of it flowed in. Almost none of it ever flowed out. The database grew for three years and never once shrank.

That’s the graveyard. Not the dramatic kind with obviously broken data. The quiet kind: thousands of records that are technically fine and functionally dead. A name, maybe an email, a company that may or may not still employ them. Nobody’s worked them in two years. Nobody ever will. But they’re still there, counted in your total, showing up in your lists, padding every export.

The usual reaction is to schedule a cleanup. Someone spends a Friday filtering and deleting, declares database bankruptcy on the worst of it, and feels better for about a month. Then the count starts climbing again, because nothing changed about how records live in the system, only which ones happened to exist that Friday.

That’s the tell that this is a design problem, not an effort problem. A cleanup is a one-time event applied to a system that produces the mess continuously. You can run it every quarter forever and the graveyard will refill every quarter forever, because the system has an entrance and no exit.

Here’s what almost no CRM is set up to express. A contact isn’t a permanent fact. It’s a relationship in a particular state, and that state changes over time, all the way to “over.”

Most CRMs model the entrance beautifully. Lead stages, pipeline stages, lifecycle stages on the way in: subscriber, lead, MQL, SQL, opportunity, customer. Rich, deliberate, well-designed. And then, nothing. There’s no stage that means “this went cold and isn’t coming back.” No stage that means “this was never real to begin with.” No structural way for a record to leave the active population without someone manually deleting it, which nobody wants to do, because deleting feels like losing history.

So records get promoted inward and never demoted outward. The system is a ratchet. Everything moves one direction, and the population only accumulates.

The redesign is to give the record a full lifecycle, one that includes an ending.

1. Define the states that mean “not active.” Alongside the states that move a record toward a deal, you need the states that move it out of the working set. Two are usually enough:

Dormant: was a real relationship, has gone cold, could plausibly come back. A former customer, a deal that went quiet, a champion who changed jobs. Not dead. Just not now.

Archived: will not be worked. Bad fit, permanently bounced, never engaged, or simply wrong. Kept for history, removed from everything active.

The point isn’t the labels. It’s that leaving the active set becomes a state you assign, not a delete you agonize over. History stays intact. The record just stops pretending to be live.

(Keeping the living records current as the world moves around them is its own separate design problem: a buyer changes jobs, a company gets funded, and the record has to catch up. I wrote about that freshness pattern a couple of months back. This piece is about the other half: letting the dead ones leave.)

2. Make the transition automatic where it can be, deliberate where it must be. Some exits should fire on their own: a hard email bounce moves a record to Archived; no activity for N months with no open deal moves it to Dormant. Those are safe to automate because the signal is unambiguous.

Others are a judgment call, and the system should ask rather than act. It surfaces the record in a review queue where a human confirms “yes, dormant” or “no, still live.” The rule of thumb: automate the approach to the exit, keep a human on the final call, and never let an automation declare a relationship dead on its own.

3. Filter every working view to the living. This is the decision that makes the other two matter. Every list an AE pulls, every view, every export that feeds a campaign filters to active states only. Dormant and Archived records still exist, still hold their history, still surface when you deliberately go looking. They just don’t show up in the places where people work.

The moment you do this, the graveyard stops being a tax on everything. The count on your working views reflects real, workable relationships. The dead are still buried, still searchable and revivable and auditable, but out of the way.

The database stops being a number that only grows and starts being a population you can actually read. “How many active relationships do we have” becomes a real answer instead of a total inflated by three years of accumulation.

The cleanup ritual disappears, because it’s no longer a ritual. Records leave the active set continuously, as a normal part of their lifecycle, the same way they entered it. There’s no Friday-afternoon bankruptcy because there’s no backlog building up to force one.

Reps trust the list again. When every view is filtered to the living, pulling a list stops being a coin flip between real records and fossils. People start working from the CRM instead of around it, which, quietly, is the whole game. A CRM people work around is just an expensive graveyard with a login.

And revival becomes a feature instead of an accident. A Dormant former customer who suddenly opens three emails and lands on your pricing page isn’t lost in a pile of ten thousand dead contacts. They’re a small, watchable population you can wake up on purpose.

You didn’t design a bad database. You designed half of one. You built a beautiful entrance, every way a record can arrive and move toward a deal, and never built the exit.

A contact isn’t a permanent fact you’re stuck with. It’s a relationship in a state, and one of the states is “over.” Give your records a way to leave, and the graveyard stops being something you clean up. It becomes something your system never builds in the first place.

Talk soon,

Marco

Founder / CEO, Novrith