Replacing mandatory fields with data people use
A fictional adoption case: every record is complete; much of it is not true.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01The outcome
Fewer fields, each used by a named decision; values derived or prefilled where they exist elsewhere; required only where known; and a view that gives the entering role something back.
To force adoption, most opportunity fields were made mandatory. Records are complete—and full of placeholder values nobody trusts.
Which data does each decision actually need—and how do we get it without asking people to type what they do not know?
Audit every field against the decision that uses it; remove what no decision uses, derive or prefill what exists elsewhere, make stage-dependent values conditional—and measure data used, not fields completed.
After a slow start, a CRM programme made most opportunity fields mandatory from the first stage. Completeness reports turned green. But forecasts built on the data were unreliable, “TBD” and default values dominated several fields, and reps spent time on data entry they saw no return from. Managers kept asking for the real picture by email.
02The reality · current state
How work actually happens today.
- Fields required at stages where the value is unknown
- Default values and “TBD” in fields used for forecasting
- Data available in the ERP typed again by hand
- Reps get nothing back from what they enter
- Completeness measured instead of use
03Approach
Not the obvious response—the approach.
Validation guarantees a value, not a true one. Completeness rises while trust in the data falls.
- 01Audit the fields
Who enters each field, at which stage, and which decision uses it.
Data owner with process owner - 02Remove and derive
Drop unused fields; derive values the system can compute.
Platform owner - 03Prefill from authority
Bring ERP and master data into the working context instead of retyping.
Integration owner - 04Require at the right stage
Conditional requirements where the value becomes known.
Process owner - 05Give value back
A prioritized view for reps built on the fields they enter.
Platform owner - 06Measure use
Replace completeness with placeholder and data-in-decision signals.
Adoption owner
04Role value
What each role gives, gets and decides.
| Role | Gives | Gets | Decides | Should not have to |
|---|---|---|---|---|
| Sales rep | Values they know, when they know them | A prioritized view built on those values | Next actions | Type ERP data or guess unknown values |
| Sales manager | Review decisions | Data trustworthy enough to review from | Coaching and escalation | Ask for the real numbers by email |
| Data owner | Definitions, quality rules at the source | Fewer fields to govern | What each field means | Chase completeness for its own sake |
05Key dimension · Field audit & role value
Every field earns its place—or leaves
Each field is checked against who enters it, who uses it and for which decision. The verdict follows from the answers.
| Field | Entered by | Used by | Verdict | Why |
|---|---|---|---|---|
| Expected close date | Rep, at every stage | Forecast, pipeline review | Keep | A real decision uses it; reviewed in the weekly review |
| Competitor | Rep, at creation | Nobody | Conditional | Required only when a deal is lost—where it informs win/loss analysis |
| Billing address | Rep, retyped from ERP | Order entry | Prefill | The ERP is the authority; show it, do not retype it |
| Deal size band | Rep, by hand | Segmentation | Derive | Computed from the amount—one less thing to type |
| Legacy region code | Rep, at creation | A retired report | Remove | No decision uses it |
The number of required fields fell; the share of records a manager could review without asking went up.
06Adoption signals
How we know it is working—each signal with an owner.
| Signal | Level | Owner | Meaning | Action |
|---|---|---|---|---|
| Placeholder values in decision fields | L2 · Process compliance | Data owner | Required too early, or not understood | Move the requirement to the stage where the value is known |
| Fields used by a downstream decision | L3 · Management adoption | Data owner | Fields earning their place | Remove or derive the ones with no user |
| Requests for data outside the system | L3 · Management adoption | Sales manager | The data is still not trusted | Find which field, fix its source or timing |
07The trade-offs
Credible options, judged against these premises.
More mandatory fields
Values always known at entry
Cost: Complete, untrustworthy dataEverything optional
Exploratory early stages
Cost: Decisions without dataAudited fields: removed, derived, prefilled, conditional or kept
Data that feeds real decisions
Cost: A field audit and ongoing data ownership08The second layer
Questions that change the design.
Use
- Which decision uses each field?
- Who reads it, and when?
- What happens if it is wrong?
Source
- Is the value known at this stage?
- Can it be derived or prefilled?
- Which system is the authority?
Value
- What does the entering role get back?
- How is placeholder data detected?
- Who owns each field’s definition?
09Decisions & outputs
What the work produces.
- 01Field audit
- 02Removal, derivation and prefill plan
- 03Stage-conditional requirements
- 04Role-value view for reps
- 05Data-in-decision signals