Your CRM Is the Bottleneck: Fix the Data Before Adding Agents

THE AGENTIC SALES BRIEF / SYSTEM 07

An account brief can be beautifully written and still refer to the wrong company. A next-step recommendation can sound sensible and still rely on a deal stage nobody has updated. An enrichment workflow can fill every empty field while making the underlying record less trustworthy.

Before adding another AI sales agent, define which CRM records it can safely use for one specific job.

This playbook builds a CRM readiness gate for an internal account-preparation workflow. It checks identity, evidence, freshness and ownership; holds uncertain records for review; and produces a small correction queue. It does not ask an agent to clean the whole database.

If the category is new to your team, Start Here explains how data, actions, human decisions and measurement fit together.

Current documentation gives two reasons to check the route by which data enters the CRM.

HubSpot says companies created through its API are not deduplicated by the Company domain name property. Its property-validation documentation also lists enforcement exceptions, including workflows. These are documented product behaviours, not findings from an Agentic Sales Lab production test. HubSpot deduplication; property validation.

Microsoft documents that Dataverse duplicate detection is suppressed by default for create and update operations through the Web API or SDK for .NET. Detection also depends on enabled settings and active rules. Microsoft documentation.

The operational implication is straightforward: a form warning does not establish what an integration will do. Test the actual entry path with synthetic records before giving it write access. This is a control requirement, not an argument for replacing either CRM.

Use a narrow starting point: prepare an internal brief for an account owner before a scheduled sales conversation.

The seller uses the brief. A named RevOps operator owns the readiness rules and exception queue. The account owner resolves business context. A CRM administrator controls integrations and any approved corrections. In a small team one person may hold several roles, but the responsibilities still need names.

The workflow reads an approved CRM view containing record IDs, account relationships, owner, relevant commercial context and evidence references. It may also read an authorised meeting record. It excludes unrelated correspondence, sensitive personal details and the rest of the contact database.

The output is either a source-backed internal brief or an exception card explaining what is missing. Neither outcome creates permission to contact anyone.

This is the upstream companion to the discovery-to-CRM system: that system proposes updates after a call; this one decides whether existing data is usable before the next task.

A contract is a short agreement about meaning and acceptance. Start with the fields the brief actually depends on.

Require a stable CRM record ID and a confirmed company association. Keep the source-system ID when records cross systems. Treat names and domains as matching evidence rather than universal identity keys: a group and its subsidiary may share a domain while representing different selling relationships.

When the record cannot be matched unambiguously, hold it. Do not choose the nearest-looking company or create another one as a shortcut.

Dataverse supports alternate keys for integrations when the primary key is unknown, but those keys must be defined on the table. That capability does not decide which entities your business considers equivalent. Microsoft alternate-key documentation.

Document what each required field means. Does “customer” mean an active contract, any historic purchase or a seller's label? Does a next-step date represent a buyer commitment or an internal reminder?

Choose one accountable owner and one authoritative source for each material field. A website may support the company's stated product offering. It cannot prove that a buyer agreed to a meeting. An approved call note may support that agreement; an inferred intent score cannot.

Keep the value, source reference and verification time together. A CRM modification timestamp is useful operational metadata, but it is not automatically the date someone verified a specific claim.

Set freshness rules by purpose. For example, a team might require the next action to be confirmed after the latest meeting, while reviewing basic account attributes less frequently. These are policy choices to test, not universal expiry periods.

Preserve the difference between unknown, not applicable, not yet checked and a confirmed negative. A blank budget is not a budget of zero. An absent next step is not evidence that the buyer rejected the deal.

Never reward the system simply for filling fields. Unsupported completion hides the work a human still needs to do.

The UK Government Data Quality Framework distinguishes completeness, uniqueness, consistency, timeliness, validity and accuracy. It explicitly separates complete data from correct data. The six checks below are our proposed sales-workflow application of that framework. Government framework.

Automate format and presence checks with ordinary rules. Use AI, if needed, to extract candidate facts from approved text and explain possible conflicts. A model's confidence score is not an accuracy check.

Report failures by rule and consequence. An invalid optional website field and an uncertain company identity should not cancel each other out inside an average score. Government Digital Service guidance similarly connects data-quality rules to purpose, impact and priority; our hold-and-review policy is an editorial adaptation. Data quality issues framework.

Read a bounded snapshot. Capture the approved view, retrieval time, record IDs, permitted fields and pagination coverage. If retrieval stops halfway, label the run incomplete. Do not report unread records as passing.

Run deterministic checks. Compare records with the versioned input contract. Give each failure a reason code, such as IDENTITY_AMBIGUOUS, EVIDENCE_MISSING, OWNER_MISSING or SOURCE_STALE. Keep model suggestions in a separate proposed-value field.

Hold affected work. Identity ambiguity blocks the entire account brief. Missing optional context can appear as an explicit unknown if the contract allows it. “Quarantine” means excluding a record from this workflow and assigning a review task; it does not mean deleting or hiding the original CRM record.

Review proposed corrections. The account owner supplies business evidence. The CRM administrator approves the exact record and field changes. In the first pilot, make corrections manually through the normal CRM process.

Read back and rerun. Confirm that the saved values and associations match the approved change. Then rerun the gate. Release the internal brief with its evidence links, remaining limitations and check time.

The minimum tool set is a scoped CRM read connector or approved export, a rules engine or spreadsheet, a protected review queue and a log. An approved language model is optional. Keep its connector read-only during the pilot; no CRM-write, merge, delete, email-send or sequence-enrolment tool is needed.

Consider this fictional fixture, not a customer case or measured result.

The approved view contains an account called Northstar Services with two candidate company IDs. One record has a next action copied from an older call. The other has the current owner but no source supporting the action. An agent combines them into a confident account brief.

The correct result is a hold. Better prose cannot resolve identity or reconstruct a buyer commitment.

Give the reviewer a compact packet:

A reviewer may decide the records are legitimately separate. Preserve that resolution in the matching policy instead of repeatedly flagging the same pair. If they are duplicates, merging follows a separate administrator-led process with a plan for associations, history and downstream effects. The agent does not merge them.

Keep eligibility and suppression controls separate from data readiness. A complete, current contact record is not permission to send. The send-permission playbook explains that boundary.

For this workflow, the agent may read approved inputs, flag issues, propose evidence-backed corrections and draft an internal brief. It may not invent missing facts, alter consent, change ownership, merge records, update pricing or stages, enrol contacts or send messages.

Apply permissions in the connector and downstream system. OWASP's excessive-agency guidance recommends restricting tool functionality, permissions and autonomy, with authorisation enforced outside the model. OWASP LLM06:2025.

Use these failure responses:

For each run, log coverage, rule version, record IDs, failure codes, evidence references, proposed changes, reviewer decisions and verified outcomes. Protect logs as carefully as the source data. Keep access restricted, redact unnecessary values and apply a documented retention period.

The ICO's data-minimisation guidance calls for personal data to be adequate, relevant and limited to the purpose. A practical design consequence is to pass only the fields needed for the brief, with approved provider terms and retention settings. This does not establish a lawful basis or resolve every jurisdiction's requirements. The ICO flags this guidance as under review following the Data (Use and Access) Act. ICO guidance.

This is a proposed operating method. We have not run a customer deployment or measured its effect on pipeline or seller time.

Start with a bounded cohort that your reviewer can inspect completely. Define the cohort and acceptance rules before reviewing results. Keep the same records for the before-and-after comparison; log additions separately.

Use a short measurement card:

These measures answer different questions. Higher readiness may simply mean the team weakened a rule. Faster brief production may be offset by a larger review queue. Record policy changes and compare cohorts before claiming improvement.

Session 1: define. Pick the internal brief, name its owner and write the field contract. Approve the data access and manual fallback. Record a baseline for the existing task.

Session 2: inspect. Run read-only checks on the bounded cohort. Review every hold and a documented sample of passes. Separate identity, evidence and format problems.

Session 3: repair the source. Have authorised people correct approved fields. Identify whether recurring issues come from an import, a sync, a form or unclear field definitions. Fix the entry rule after testing that path.

Session 4: rerun. Verify saved corrections, repeat checks on the same cohort and exercise the synthetic failure cases. Review useful output and human effort together.

Session 5: decide. Continue only if the owner accepts the remaining limitations and review workload. Stop if critical identity errors escape, unauthorised writes occur or exceptions cannot be reviewed. A successful pilot earns consideration of a larger cohort; it does not automatically grant write or send authority.

Test shutdown before expanding: disable triggers, freeze queued work, revoke the workflow's credentials, reconcile any correction in progress, preserve the restricted audit log and return sellers to the manual brief. The owner must confirm that no background job continues after the switch is off.

Use the free Agentic Sales System Starter Kit to scope the workflow, record its data requirements and define the human gate, fallback and test.

Documentation checked 25 September 2026. Product behaviour is documentation-verified, not tested in a customer tenant. The workflow, thresholds and pilot sequence are Agentic Sales Lab proposals. General operational information, not legal advice.