What AI implementation looks like at catalog scale

An industrial distributor wins accounts by answering one question fast: "here's the part number I buy from your competitor — what's your equivalent?" At this client, that answer ran through an internal lookup tool that failed three or four times out of ten. What followed the failure was the real workflow: catalog PDFs, supplier websites, a colleague who might remember, and an educated guess that a customer's production line would end up depending on.

That lookup is where our build for this client — a publicly traded industrial supply distributor — starts. This article walks through what we built: a product knowledge graph and the tools on top of it. What each one is, how it works, and why it's built the way it is.

Tool one: a catalog that knows what equals what

The foundation is a knowledge graph — a database where relationships are first-class data — holding more than 155,000 products across four catalogs: the distributor's own, a sister division's, and two national competitors'. Every product is connected to its supplier, its category, and — this is the point — the other products it's equivalent to. Nearly 78,000 verified cross-references between the two in-house catalogs went in on day one, extracted from a workbook that had never been queryable before.

Getting products in is a pipeline, not an import. Crawlers scrape the competitor catalogs, with a semantic-search fallback for sites that fight automation. A normalizer per source reconciles four suppliers' inconsistent field naming into one schema. A parsing pass digs specifications out of free-text descriptions — material, thread size, diameter — and promotes them to real, queryable properties. Sizes are stored twice on purpose: the display string a human expects ("1-1/2") and the numeric value a range query needs (1.5). About 45,000 products carry that numeric length today.

Why a graph instead of the spreadsheets and flat exports it replaced? Because equivalence is a relationship, not a column. In a table, cross-references are lookups you chase one at a time. In a graph, they're paths you can traverse: if product A matches B, and B matches C, the chain from A to C is right there — which is exactly how a distributor finds matches nobody ever manually recorded.

Tool two: matches a human signs off on

On top of the graph sits the workflow consultants actually live in: paste a competitor part number — or upload a whole list for bulk matching — and the system searches the graph, scores the candidates, and lays the evidence out side by side: specs, materials, dimensions, source.

The human makes the call. An approval writes a permanent equivalence relationship into the graph, stamped with a confidence score, who approved it, and when. A rejection is stored too — as a not-equivalent relationship — so a bad suggestion never resurfaces to waste a second person's time.

No match commits without a person, by design. A wrong cross-reference isn't a software bug; it's the wrong part arriving at a customer's production line. But the deeper reason is compounding: every decision a consultant makes becomes data the next search benefits from. The old lookup tool never learned. This one never forgets.

Tool three: search for parts that were never named for humans

Industrial part names look like "HHCS 3/8-16 x 1-1/2 GR8 ZP" — and every supplier abbreviates differently. Keyword search alone dies here. So search runs several strategies at once: a full-text index across names and spec fields, vector similarity over text embeddings, vector similarity over product-image embeddings, and spec-aware matching — blended with configurable weights.

The embeddings — 768-dimension vectors from a multimodal model — live directly on the product records in the graph, so a similarity hit and a relationship traversal are part of the same query. Text vectors catch same-part-different-words across suppliers. Image vectors handle the request every distributor knows: a customer's photo of a part on a shelf, no label in sight.

The why is blunt: consultants don't fail to find products because the products aren't there. They fail because the words don't match. Meaning-based search takes the words out of the equation.

Tool four: questions in English, answers from the graph

The top layer is a natural-language query interface next to a live dashboard of the catalog: product counts, category coverage, match progress. An account manager types "which competitor fasteners have no equivalent in our catalog yet?" and gets an answer — not a report request, not an export.

Under the hood, Claude translates the question into a graph query and runs it — and, the detail that makes it production-grade, reads any error the database throws back and corrects its own query before answering. Results come back summarized in plain language, with the numbers pulled from the graph rather than from the model's imagination.

Nobody on an account team is going to learn a graph query language, and they shouldn't have to. The graph grounds every answer in real records; the model's only job is translation, in both directions.

Tool five: one screen instead of a dozen Salesforce tabs

The daily workflow around the catalog lived in a second kind of fragmentation: the CRM. Tracking a single job from first profile to installed solution meant hopping between Salesforce list views, record pages, and comment threads — plus a set of tracking spreadsheets that existed precisely because nobody could see the pipeline in one place. The data was in Salesforce; the workflow wasn't.

So the app pulls it all into one workspace, organized the way consultants actually work a day: every open job grouped by milestone — profile, data collection, presentation, signature, scheduling, install, handoff — with the oldest waiting deals surfaced first. Aging is visible at a glance: a heat indicator goes yellow at thirty days and red at forty. Summary cards keep the counts honest — total, active, warning, overdue.

It isn't a read-only report. Consultants update jobs right in the flow — notes inline on the row, stage-gated checklists per milestone, the reference documents for each account type attached where the work happens — and the changes land back on the Salesforce records instead of forking off into another spreadsheet. Mentions from record threads surface as notifications, so "go check the CRM" stops being a standing chore.

Why build a workspace instead of another CRM dashboard? Because the native dashboards answer management's questions, not the daily one: what needs my attention today, and what's stuck? The client's own team had quietly rebuilt that answer in spreadsheets — the surest sign a screen is missing. We built the missing screen and let Salesforce keep doing what it's good at: being the system of record.

So where's the AI?

Here's the honest answer: at the edges, on purpose. AI in this build does two jobs — it translates (English into graph queries, product descriptions and images into vectors) and it summarizes. The core of the system is a deterministic graph where every relationship was either ingested from verified data or approved by a human. The model never decides that two parts are equivalent; it suggests, and its suggestions are grounded in graph structure, not statistical guesswork.

The buzzword version of this project would have been a chatbot bolted over the catalog — one that hallucinates part numbers with total confidence, which in this industry is worse than no answer at all. The next phase builds on the structure instead: match suggestions that traverse the existing cross-references to surface equivalences no text search could find — if A matches B in one catalog and B matches C in another, the graph proposes A-to-C on its own — plus category browsing and a consultant workspace layered over the CRM.

Same lesson as every build we ship: the expertise isn't adding AI. It's knowing which parts of the problem are language problems — and giving everything else to boring, verifiable structure.

The principles underneath

Wondering what the equivalent build looks like for your operation? That's what the free Bottleneck Audit finds: the decision or routine that eats the most of your week, and what it would take to hand it to a system. No pitch — you leave with a plan.