Custom field completion rate

Custom field completion rate is the percentage of records that have a given custom field populated, out of the records where that field should be filled. If 1,000 opportunities should carry a value in a field called deal_source and 620 of them do, the custom field completion rate for that field is 62%. It is a direct, unglamorous measure of whether the information your team thinks it has actually exists in the system.

It matters because almost everything downstream depends on it. Segmentation, reporting, routing rules, scoring, and automations all assume the fields they read are filled. When completion is low, those processes silently skip records or fall back to defaults, and the gaps are invisible until a report looks wrong or a campaign misses half its audience. Measuring completion rate makes the data quality of a specific field visible before it quietly breaks something built on top of it.

The calculation divides the count of records with the field validly populated by the count of records where the field is expected, then multiplies by 100. The two judgement calls that decide whether the number is trustworthy are what counts as populated and which records belong in the denominator.

1. 1

   Records where the field is expected

   The denominator. Many custom fields only apply to certain record types, stages, or segments. Including records where the field is irrelevant understates completion and points attention at a gap that is not real.

2. 2

   Definition of populated

   What counts as a valid value. A field containing a placeholder, a stray space, or an obvious junk entry is technically not empty but is not really complete. Decide whether you are measuring presence or validity.

3. 3

   Source of each value

   Whether the field was filled by a person, an import, or an automation. The same completion rate means very different things if values are entered by hand versus populated automatically, and it tells you where to look when completion drops.

4. 4

   Time and lifecycle point

   When in a record life the field is expected to be filled. A field that should be set at creation has a different completion target from one filled later in the process. Measure at the right point or the rate looks worse than it is.

A worked example shows how the denominator shapes the result. Suppose you have 5,000 contact records but the field industry only applies to the 3,000 company-linked contacts. If 1,800 of those 3,000 are filled, the true custom field completion rate is 60%. Measured against all 5,000 records, the same 1,800 reads as 36%, making the gap look almost twice as bad and sending the team chasing records that never needed the field at all.

A metric tree decomposes custom field completion rate into the reasons a field ends up empty, then traces each reason back to the team or system that can close the gap. This turns a flat completion percentage into a map of where the data is leaking.

The first level splits completion by source: values captured at creation, values filled by people later, values brought in by imports and integrations, and values produced by automation. Each branch decomposes further. Creation-time completion depends on whether the field is required at entry and how clear the form is. Manual completion depends on whether the team knows the field exists and finds it worth filling. Import completion depends on field mapping and source data quality. Reading the tree tells you whether a low rate is a process problem, a tooling problem, or a source problem.

KPI Tree attaches RACI ownership to every node, so the team accountable for, say, the integration mapping or the manual entry step is named on the branch. When completion drops, the push goes to the accountable owner of the source that changed, and the verified impact loop checks whether a fix, such as making the field required at creation, actually raised completion rather than just shifting empties into a later stage.

Targets depend on how the field is filled and how much rides on it. A field required at creation should sit near complete, while a field filled manually by busy people will always trail. The useful benchmark is against the field role, not a single universal figure.

A rising completion rate is only progress if the values are actually correct. Teams can hit a target by filling fields with placeholders or guesses, which produces a complete-looking field full of unusable data. Always pair completion with a sense of validity, and never read a high rate alone as a sign the data is good.

Improving completion means closing the gap at the source that is leaking, not asking the whole team to be tidier. The most common mistake is to run a one-off cleanup that fills the existing gap while leaving the cause untouched, so the rate decays straight back down.

The metric tree approach starts by finding the source node with the largest gap. If most empties come from a single integration, fixing the mapping lifts the rate more than any amount of manual chasing. If the field is optional at creation and that is where the gap sits, making it required closes it at the point of entry.

KPI Tree connects each branch of the completion tree to the team or system that owns it. Operations owns the creation form rules. Data engineering owns the integration mappings. The teams entering records own the manual fields they touch. When the completion rate drops, the accountable owner of the source that changed is notified, so the gap is closed where it opened rather than cleaned up after it has already broken a report.

1. 1

   Measuring against every record

   Many fields only apply to some records. Counting completion across all of them, including ones where the field is irrelevant, understates the rate and points attention at a gap that does not exist.

2. 2

   Counting junk as complete

   A placeholder, a stray space, or an obvious guess is not empty but is not really filled. Measuring presence rather than validity produces a complete-looking field full of unusable data.

3. 3

   Cleaning records without fixing the source

   A one-off backfill raises completion briefly, but if the form or import that caused the gap is unchanged, the rate decays straight back down as new records arrive.

4. 4

   Treating all sources as one number

   A completion rate averaged across creation, manual entry, imports, and automation hides where the gap actually is. Decompose by source so the fix lands on the pipe that is leaking.