You have 722 CRM properties. You need about 200.

The last CRM I audited had 722 custom properties. About 200 of them earned their place. The rest were boxes a rep had to scroll past - or worse, fill in - every time they opened a record.

If your number is anywhere near that, you don't have a data problem yet. You have a property problem. It becomes a data problem the moment you ask people to populate fields nobody actually needs.

The fix is a Keep/Cut audit, run in a fixed order, with a heavy bias toward cutting. Here is why the bias matters, and how to run it without spending a month in meetings.

Nobody designed 722 properties. They accreted.

No one sat down and specified 722 fields. It happened one reasonable request at a time. A campaign needed a field. A one-off report needed a field. A new hire from a different CRM wanted the one they were used to. Every single one made sense on the day it was added.

And none of them ever got removed, because removing a field feels risky and adding one feels free. So the count only goes in one direction. This is the same accretion behind most messy HubSpot CRMs - the mess was built on purpose, in tiny sensible steps, by people doing their jobs.

Every property is a tax, not an asset

The instinct is that more fields mean more data, and more data must be better. It runs the other way.

Every property a rep can see is a small decision you have handed them. Fill it, skip it, or guess. Multiply that by a form with sixty fields and you have quietly taught your team that data entry is something to survive, not something to do carefully. The good reps resent it. The rest just click through.

And here is what actually becomes of a required field nobody understands. It does not get left blank. It gets filled with whatever makes the form submit and lets the rep get on with their day. Empty is honest. Garbage looks like data - and garbage is precisely what you will later build your reports, your forecasts, and your AI on top of.

An unused property is not neutral. It is a standing invitation to enter something wrong, on a record you will trust later.

How to run the Keep/Cut audit, in order

The order is the whole method. Do it out of sequence and you will waste a week arguing about fields that should have been cut in the first ten minutes.

First, usage. Pull the fill rate for every property. Anything empty or near-empty goes straight on the cut pile. In that 722-field audit, 203 were completely empty - never populated once. Those are not a debate. They are a delete.

Second, dependency. For whatever survives the first pass, check what relies on it. Workflows, reports, integrations, required-field settings. A half-empty field feeding a live report can stay - but now you know exactly why it exists, which you did not before you looked.

Third, decision value. For the fields that are both used and depended on, ask the last question: does anyone make a decision from this? A property that changes nobody's behaviour is one you are maintaining out of habit. Sentiment is not a reason to keep a field.

Usage, then dependency, then decision value. Most of the cutting happens in that first pass - which is exactly why the empty fields are the easy win almost nobody bothers to take.

Why deleting beats maintaining, every time

You could keep the 500 and simply resolve to govern them better. It will not hold, and it never does. A kept field is a permanent cost - someone has to keep it clean, keep reps filling it correctly, keep it from drifting as the business changes underneath it. Every property you keep is a small standing liability on the books.

Deleting is the only move that reduces the total load. Cleaning, documenting, training, adding validation rules - every one of those adds work. Removal subtracts it. When you are genuinely unsure, that asymmetry is the tie-breaker. The cost of cutting a field you turn out to need is one afternoon rebuilding it. The cost of keeping 500 you don't is paid every day, forever.

Archive first if it makes you nervous. Hide the field, watch for a quarter, delete whatever nobody missed. But be honest that archiving is a stop on the road to deletion, not a destination of its own. A field parked "just in case" is clutter with a better excuse. The full property teardown is written up as a CRM audit case study if you want to see the method run end to end.

You don't need 722 properties. You never did. Start with the 203 that are empty. Nobody will miss a box they never once filled in.

Common questions