← All writing

Essay · Marketing operations

The database is the strategy: running a marketing CRM like an operating rhythm

Every cleanup works. None of them last. A marketing database stays healthy for exactly one reason: somebody owns it, on a cadence, against a written definition of healthy.

Essay · Published October 18, 2026 · Updated October 24, 2026

The cleanup that never sticks

Many marketing teams have run the same project more than once. Someone exports the contact database, a contractor or a vendor dedupes it, the bounces get suppressed, and the team enjoys a quarter of clean sends. Then the trade show list gets imported without a source field. A rep adds forty contacts by hand with no job titles. A form starts accepting personal email addresses. Eighteen months later, the deck for the next cleanup project looks exactly like the last one.

The effort was never the problem. The cleanup did what it promised. What it could not do was keep anyone responsible for the database after the project closed. A cleanup is an event. Decay is continuous. You cannot beat a continuous process with an occasional one.

Here is the claim this essay defends: a marketing database stays healthy only when one defined health metric, named owners, and written standards are reviewed in the same weekly cadence the company uses to execute its strategy. Take away any one of those four and you are back to scheduling the next cleanup.

I came to this view from the operating side. As VP of Marketing at Fullintel, I inherited an email program sending from a dead domain, blacklisted before I arrived. Over the same period, I grew the marketing database from 140,000 records to 700,000 ICP aligned, deliverable contacts through third party enrichment, raised database health from 71% to 96%, and saw engagement climb as mail reached inboxes again. The growth is the number people notice. The part that mattered most was building ownership, standards, and validation into the workflow rather than running a one time cleanup. That is what let a database five times larger also be the healthier one.

Data decay is an execution failure

I spent my years at Rhythm Systems writing about why good strategies fail in the doing. The diagnosis was rarely a bad plan. It was a plan with no owner, no review cadence, and a scoreboard made entirely of lagging numbers that only reported the damage after it was done. Frameworks like Think Plan Do are useful precisely because they give the doing step the same structure as the planning step.

A CRM fails in the same three places.

  • No owner. Sales adds records, marketing imports lists, integrations sync fields, and nobody answers for the result.
  • No cadence. Data quality comes up when a campaign underperforms, after the cost has landed.
  • Lagging measures only. Teams watch open rates and pipeline. Both are downstream of the database, so by the time they move, the decay is months old.

A new tool migrates the same habits into a cleaner interface. The fix is to treat the database the way a disciplined company treats any priority: assign it, measure it, and review it on a schedule. KPI Evaluation and Review made the case that metrics need regular evaluation, not just regular reporting. My corollary: a number that nobody reviews stops being managed, and a number that is reviewed but never questioned slowly stops measuring the right thing.

Give the database a Critical Number

At Rhythm Systems I wrote about the Critical Number, the single measurement that tells a company whether it is moving toward its top goal for the quarter or the year. A database needs the same thing. Not a dashboard with thirty tiles. One number, defined in a sentence, that the owner is accountable for.

The definition has to be written down before anyone quotes a percentage, because health means nothing until its components are explicit. A workable definition names a small set of record level tests and how they combine. The shape I recommend looks like this:

An example structure for a database health definition
ComponentWhat a record must pass
DeliverableThe email address validates and has not hard bounced.
CompleteThe fields your segmentation and routing depend on are populated.
In ICPThe account and role fall inside the ideal customer profile you sell to.
UniqueThe person exists once, not three times under three spellings.

Whatever components and weights you choose, publish them. The process in Creating Effective Company KPIs applies directly: define the metric, set the target, name the owner, and agree on how often it gets reviewed. A health score with a hidden formula invites argument every time it moves.

The most important design choice is that fit to the ICP outranks raw size. A database of contacts who will never buy is not an asset. It costs money, drags down deliverability for the contacts who matter, and inflates every reach number. Size and health only pull against each other when growth skips the standards. The Fullintel result shows the other path. Starting from a dead email domain, the database grew from 140,000 records to 700,000 contacts through third party enrichment, health rose from 71% to 96%, and engagement went up, all over the same period. The new contacts counted because they were ICP aligned and deliverable, not because there were more of them. Growth that passes the definition raises the score. Growth that skips it is how the next cleanup project starts.

Put it on the weekly agenda

A metric with an owner still decays if nobody looks at it between quarterly reviews. The database needs a standing place in a meeting that already happens. In Weekly OKR Meeting I wrote about bringing goals and their measures into the weekly team meeting so they get attention every week instead of every quarter. A database item fits that format in five minutes: the owner reports the number, flags anything off track, and the meeting moves on.

The mechanics are simple to describe and hard to keep up, which is why they need a cadence.

  1. Named owners. Assign an owner per segment or per field group. One person answers for the health number overall; others answer for the slices they control, such as event imports or the inbound form.
  2. Written entry standards. Every way a record can enter the database gets a short written rule: required fields, accepted formats, source tagging, and who approves a bulk import. If a rule is not written, it is not a standard.
  3. A weekly look at leading indicators. The health score itself moves slowly. The indicators that predict it move fast: the bounce rate on recent sends, the count of incomplete records created this week, and the count of new records that fall outside the ICP. Those three numbers tell the owner where decay is entering before it shows up in the score.
  4. A quarterly ICP review. The ICP is a strategic decision, so it belongs in the quarterly planning conversation, not in the marketing operations backlog. When the company changes who it sells to, the database definition has to change with it.

This is the same discipline I argued for in Track Business Success with Leading Indicators and Dashboards: lagging results tell you what happened, leading indicators let you act while there is still time. Applied to a CRM, the weekly meeting catches a bad import the week it lands.

Automate the checks, not the judgment

The strongest objection to all of this deserves a fair hearing. Modern CRMs dedupe on entry. Enrichment services fill in titles and company data. Validation tools reject bad addresses at the form. AI models can flag likely duplicates across spellings no rule would catch. If the software keeps the data clean, a human review cadence looks like overhead.

Part of that objection is right. Automation runs checks better than people do, and it should run every check it can. At Fullintel I built automation across database management, email validation, and manual reporting that returned roughly 900 hours a year to client facing teams.

The objection fails on what tools cannot do. A tool enforces a standard; it cannot set one. It cannot decide which fields matter for routing, choose the ICP, or weigh a big list from a new market against the damage it would do to deliverability. Most of all, it cannot notice that the health metric itself has stopped measuring the right thing, for example when the ICP shifts and the score keeps rewarding records the company no longer wants. That review is a judgment call, and it needs a person with the authority to change the definition.

There is a sharper risk too. Automation without an owner hides decay faster. An enrichment rule that fills a field with a plausible wrong value produces a database that looks complete and is wrong, while the dashboard stays green. The weekly review, run by someone who knows what the numbers should look like, is how you catch it.

What sales and enablement get back

Database health gets framed as a marketing operations concern. Sales and enablement often benefit more.

Consistent records make consistent messaging possible. If industry, role, and segment fields are reliable, enablement can build plays and content mapped to those segments and trust that reps will reach the people the plays were written for. If those fields are half empty, every rep improvises. I wrote about the cost of that drift in The Messaging Consistency Gap That's Killing Your Pipeline: when marketing, PR, sales, and customer success tell conflicting stories, prospects notice, and so do the AI systems that summarize a company for them.

Clean records also make the handoff cleaner. A lead that arrives with a verified address, a real title, and a source tag can be routed on rules instead of judgment, and the rep who picks it up starts with context instead of research.

And a healthy database shifts the conversation from volume to quality. In Lead Quality Over Volume I argued that the better prospect is worth more than the bigger list. Every marketing metric in a template like Digital Marketing KPI Examples with Template (email performance most of all) is only as trustworthy as the records beneath it. Fix the database and the metrics sales relies on start to mean something.

A starting checklist for the reader

None of this requires a new platform. It requires a decision and a calendar slot. Start this week:

  1. Write a one sentence definition of database health. Name the components and how they combine. Share it with sales and operations before you report a number against it.
  2. Assign one owner to that number. A person, not a team. Then name owners for the entry points they do not control directly.
  3. Write entry standards for every source. Forms, imports, integrations, and manual entry each get required fields and a source tag.
  4. Pick three leading indicators. Recent bounce rate, incomplete records created this week, and new records outside the ICP are a good default.
  5. Add a five minute database item to a meeting that already exists. The owner reports the health number and the three indicators. Anything off track gets an action and a name.
  6. Put the ICP on the quarterly planning agenda. When the strategy changes, change the definition of a good record with it.

Then stop scheduling cleanups. If the cadence holds, you will not need the next one. For how this work fit into a broader operating program, see the AI adoption case study; more of my writing on execution and measurement is collected on the writing page.

Sources