You can delegate bounded CRM updates when every change has an approved source, an authorised field and a verifiable outcome. Separate confirmed facts, inferences awaiting review and unknown information. Standardising or proposing an update differs from merging or deleting records: possible duplicates require an explicit decision from the responsible person.
A populated field is not necessarily better data
An incomplete CRM creates work when the person taking over a contact must reconstruct the last conversation, identify the organisation involved and find the next step. Filling every box does not solve the problem if information is inferred, outdated or lacks a source. Define quality against the record's purpose: which information is genuinely needed for the next task?
Begin with a limited set of fields and authorised sources. You can assess recording a note, standardising a format or proposing an update. Treat ownership changes, sensitive information, contact merges and deletion as separate operations requiring their own rules and authorisation.
Separate verified, awaiting confirmation and unknown
“Verified” means supported by a source permitted for that field, such as a contact confirming their role. “Awaiting confirmation” identifies an inference or conflict for a person to review. “Unknown” means the information is unavailable, not that it should be generated. Keep the source, date and reason for the change with each proposal.
Do not turn “seems interested” into a confirmed sales stage. It is a judgement attributable to the person who handled the contact. The ICO's UK guidance on data accuracy distinguishes facts from opinions and addresses the origin of information. Here, that distinction helps design an understandable record; it does not establish compliance for your processing.
A before-and-after record with its sources
This illustrative example uses fictional names. Record C-204 belongs to Elena Riva at Arco Services. A reply from the contact, E-81, confirms her role; meeting note N-12, approved by the sales owner, sets out a next step. A proposal is not applied until it meets the rules for the relevant field.
Scroll the table horizontally to read every column.
| Field | Before | Proposed after | Origin and decision |
|---|---|---|---|
| Organisation display name | “ARCO services” | “Arco Services” | Approved organisation record A-17: display formatting only; legal identity unchanged. |
| Role | Not recorded | Operations Manager | Contact email E-81: verified under the agreed rule. |
| Next activity | General note: “follow up” | Send the requirements sheet, assigned to the sales owner. | Approved note N-12; recording the activity does not send the message. |
| Employee count | Unknown | Remains unknown | No authorised source available; do not infer it from the size of the website. |
| Opportunity stage | Initial contact | No automatic change | “Interested” in N-12 is a judgement; the sales owner confirms any stage change. |
A useful execution note reads: “C-204: three changes proposed from A-17, E-81 and N-12; employee count unchanged; stage change referred to the owner.” After approval, the register must distinguish successful, rejected and unperformed updates. A correct proposal does not demonstrate that the CRM saved it.
A possible duplicate is a question, not a merge instruction
Suppose C-319 also exists: “E. Riva”, linked to the same organisation but an older opportunity. Similar names and a shared organisation are clues, not proof that a record is redundant. There could be two people, two roles or activities that need to remain separate.
Prepare a comparison showing IDs, sources, authorised contact details, opportunities and owners. The responsible person decides whether to retain, correct or merge records using the CRM's actual capabilities. Before an irreversible operation, check what can be recovered and retain the relationship between old and new identifiers. Deletion should never be a side effect of “cleaning”.
Keep updates small and reviewable
Agree which fields can be changed and retain their previous values. If a sales colleague edits the record while a proposal is being prepared, read the current value again or flag the conflict before overwriting it. If a write fails, record the result and check the actual state before retrying: blindly repeating an action can create duplicate activities.
You can start with authorised exports and a review queue, then assess writing back later. Feasibility depends on the CRM, version, permissions and integration constraints. The service describes work on statuses, notes and next steps; it does not guarantee universal connectors. Use the guide to permissions and approvals to define operating boundaries.
Measure work recovered, not the percentage of filled cells
Check how many updates are accepted, how many need correction and how many activities are duplicated or assigned incorrectly. Include the owner's time reviewing proposals. Leaving a field empty may be correct; a seemingly complete but false record can create more work than it removes.
Test missing information, conflicting sources and simultaneous edits in your pilot. Agree when to suspend an update category and how to hand work back to staff, as described in the guide to measuring pilot results. If the problem starts with emails that never become activities, connect the project to shared inbox management while keeping responsibilities and permissions explicit.