Diagnose a Data Quality Objection Before Proposing Automation

A buyer says automation will fail because source records differ. Treat those words as a request for a closer look, not an invitation to defend a product. A phrase such as poor data covers separate problems. Duplicate account names, delayed updates, blank fields, and opposing definitions create different risks. Each problem needs a separate owner and a separate review.

Ask for one recent record. Say, “Please show me one record where this process went wrong. Where did work begin, what changed, and when did someone spot the problem?” A single record gives both people something concrete to inspect. You learn whether a person missed a field, an integration copied an older value, or two groups use different meanings. Broad labels often hide a disagreement. A record shows where disagreement first appears.

Follow information from entry through use. Ask where a field starts, who changes a field, which workflow receives a field, who spots an error, and who approves a correction. Do not present every question at once. Let a buyer finish a real example. Then ask about each stage appearing inside a given example. A rapid checklist makes a serious concern feel like an obstacle you want removed.

Ask what happens after an error appears. Some teams assign daily corrections to a named person. Other teams leave corrections with whoever notices a problem. Those arrangements lead to different readiness conversations. A named owner might inspect a sample and decide whether current cleanup activity covers a proposed workflow. An informal arrangement might need a decision about ownership before an evaluation starts. Neither answer deserves blame. Your role involves naming work already happening and work without an owner.

Consider a fictional practice situation. Priya leads data operations for a software company. She says, “Our account records are a mess. We should wait before automating anything.” The seller replies, “Which field creates your largest concern for this workflow?” Priya describes a renewal record. An account owner changed in one system but stayed old in another. A renewal manager used an outdated owner field and sent a request to a former contact. The error became visible two days later when no reply arrived.

The seller now has a starting point. Rather than claim broad cleanup value, the seller asks, “For this workflow, does an incorrect owner stop work, send work toward a wrong person, or create a result needing review?” Priya identifies incorrect routing as her main concern. The seller asks who approves a correction and how long a correction usually takes. Priya says a data steward checks ownership changes each afternoon. This response supports a limited readiness review. No one needs a claim about every record across every source.

Set boundaries in plain language. Name the workflow, source fields, record sample, and people who will judge results. In Priya’s fictional situation, participants select twenty recent renewal records. They compare owner values from each source, mark differences, and name a source used by the renewal group as its reference. Priya assigns the data steward to decide whether a difference needs correction. The renewal manager identifies cases where incorrect routing disrupts work. Those choices give a review an understandable shape.

Ask for a representative sample rather than a set of unusually clean records. A helpful sample includes ordinary records plus a few known variations. Explain why without promising an outcome. “We need normal variation before we decide whether this workflow fits,” keeps discussion honest. If a buyer offers a spreadsheet, ask which columns connect directly to a decision. A huge export distracts people. Two or three fields linked to a workflow give a stronger first review.

Definitions need equal care. Two groups often use customer for different stages of a relationship. One report labels a record active after signature. Another waits for onboarding. A process built across those meanings often produces unexpected results even when every field holds a value. Ask, “What does active mean for this workflow, and where does your group record this decision?” Then ask whether another group uses active differently. Those questions expose a definition problem without assigning fault.

Separate source quality from process design. A buyer might point toward an incorrect field while a larger issue sits in an unclear handoff or a missing approval. For example, an owner field stays old when no one decides when a territory change becomes final. Automation would reproduce uncertainty until someone defines an approval event. Say, “This record shows a change without a clear approval point. Would your group want to define one before we test this workflow?” The question invites a decision instead of portraying a data team as an obstacle.

Avoid promises about repairing every input, reconciling every source, or removing human review. Such promises create a later dispute. Describe only review work participants agreed to perform. When a technical question appears, record the question, source record needed for an answer, and person responsible for an answer. A short written note helps later participants see where uncertainty sits. Keep opinions apart from observations. “Three records showed an ownership difference” reports an observation. “Data is ready” belongs to a buyer’s designated owner.

Sometimes a data objection signals a prior failed effort. Listen for mentions of wasted work, old consultants, or reports nobody trusted. Do not demand details. Ask, “Which part of earlier work should this group avoid repeating?” An answer often reveals a practical rule. A team might want a data steward present before a demonstration. Another team might prefer one workflow review before a larger scope discussion. Respect for prior effort gives you a clearer path than an argument over whether concern is valid.

Prepare a one page readiness note for a next discussion. Include selected workflow, fields under review, sample source, known variations, correction owner, and decision due after review. Keep open questions visible. In Priya’s fictional renewal situation, a note says participants will compare twenty records before Friday’s review. Priya’s data steward will judge owner differences. The renewal manager will judge routing impact. No broader claim belongs in this note.

At Friday’s fictional review, the seller opens record one and asks Priya, “Does this record meet our agreed rule for renewal routing?” Priya answers from evidence, assigns one correction, and chooses record two. The group moves through nineteen remaining records using the same rule. After record twenty, Priya writes a date beside each unresolved difference and sends her steward a request for decisions before their next review.