A rep at a manufacturing client quoted a part as SKU 4471-B. The customer's last purchase order had it as SKU-4471B. Same part. Two strings sitting in the same CRM.
Nobody typo'd their way into that. One rep copied it off an old invoice. Another pulled it from the ERP. A third just typed what the customer said on the phone. Three people, three honest inputs, one part number that now exists in HubSpot as three different things.
So the obvious move is to point Breeze's Data Agent at it. That's the instinct this article exists to correct.
This is the same CRM that manufacturers are finally taking seriously, which is exactly why the data sitting inside it is worth getting right.
The first way is absence. A company field is blank. Nobody ever recorded the customer's primary industry, or what equipment category a deal belongs to, or whether the account sits on a service contract. The data was never captured in the first place.
The second way is conflict. The data was captured, more than once, by more than one honest person, and it does not agree with itself. A SKU with two spellings. A part number copied from an ERP export that uses dashes where the CRM uses none. A BOM reference that means one thing to engineering and something slightly different to the rep who logged it on a deal.
Both look like "bad data" from the outside. They are not the same problem, and they do not have the same fix.
Breeze's Data Agent works through what HubSpot calls smart properties, smart actions, and smart columns. You write a prompt, point it at a data source, web research, the company's own website, other properties already on the record, or call and activity transcripts, and the agent runs that prompt and writes a value into a field.
That is a genuinely useful thing to automate. A blank "primary industry" field, a missing company size, an unfilled "equipment type" property on a new account: the Data Agent can research and populate all of it, and it will keep doing so automatically as new records come in through a workflow. It consumes a HubSpot credit every time it runs, even on the attempts where it comes up empty, which is worth knowing before you point it at a few thousand records.
What none of that does is look at a field that already has a value in it and ask whether the value is right. The Data Agent has no concept of "this SKU might be a duplicate of that SKU." It fills silence. It does not referee an argument between two values that both already exist.
A blank field is cheap. Nobody acts on a blank field, because nobody can. The cost sits quietly until someone finally needs that data point and has to go find it.
A conflicting field is expensive precisely because it looks usable. Someone will act on it. A quote goes out with the wrong part number. A production order references a BOM line that engineering stopped using two revisions ago. The data isn't absent, so nobody flags it for cleanup, right up until it causes a shipping error or a warranty call that shouldn't have happened.
This is the trust gap: the distance between the data a company has and the data it will actually act on. We've written before about how HubSpot and an ERP never agree on their own for the same reason. A field full of conflicting SKU formats is not a data gap. It's a trust gap wearing a full field as a disguise.
Enrichment tools are built to shrink the first kind of gap. They were never pointed at the second, and it shows the moment you ask one to do a job it was not designed for.
Fixing SKU and part number inconsistency isn't a setting you flip on. Someone has to decide what the canonical format actually is, SKU 4471-B or SKU-4471B or something else entirely, and then someone has to reconcile every variant already sitting in the CRM against that decision.
That is exactly the kind of work an AI Forward Deployed Engineer, an AI implementer who works inside a client's actual ERP, CRM, and financial systems to deploy AI where it reduces coordination cost or decision latency, rather than delivering a generic product or a demo from a distance, gets brought in to do. A Claude-based workflow reading across HubSpot deal records and ERP part master data can propose a reconciliation: which SKU strings are almost certainly the same part, which BOM references point to a superseded revision, which duplicates to merge. But someone still has to own the standard it reconciles against, and someone still has to approve the merges before they're final. No prebuilt agent ships with your company's canonical part-numbering scheme already loaded, because it can't. Only you have it, and most manufacturers haven't written it down anywhere a tool could read it.
This is also where the soft version of the Debsan pitch actually applies, so it's worth saying plainly once: this reconciliation work is specific enough to your parts catalog that it rarely fits inside a generic rollout. It's implementation work, not a product purchase.
It shows up in the gap between a direct sales branch and a distributor branch quoting the same part under slightly different internal codes. It shows up when an old product line gets a new SKU scheme and half the historical deals never get updated. It shows up in a BOM reference that engineering revised but sales never heard about, because nothing in HubSpot forced that update to propagate.
None of these are glamorous problems. They are also the exact kind of problem that compounds quietly for years, because every individual instance looks like a one-off typo instead of a system issue.
Will Breeze's Data Agent clean up our messy SKU and part number data automatically?
No. It fills in missing property values through research. It has no way to detect that two existing values refer to the same thing, so it won't merge or standardize anything already sitting in a field.
Should we hold off on using the Data Agent until our product data is clean?
No, the two problems don't block each other. Use it now for genuinely blank fields, missing industry, missing equipment category, while fixing SKU standardization as its own separate project.
Who should actually own fixing the SKU inconsistency?
Someone with the authority to define the canonical format and the time to reconcile the variants against it, often paired with an AI Forward Deployed Engineer-style build that proposes the matches a person still has to approve. It is a decision nobody has made yet, not a missing feature.
How do we know if this is actually costing us money and not just annoying us?
Check whether a rep or a production planner has manually looked up a part number in the last month because they didn't trust what HubSpot showed them. If that's a regular occurrence, the trust gap is already live and already expensive.
Fill the blank field. Fine, let the agent do it. But the dirty data you already have was never a research problem, and no amount of AI pointed at it is going to change that until someone decides what's actually correct.