How a Distributor Finds Equivalent Parts in a Product Catalog
A case study in catalog search and human-reviewed part matching
The numbers behind this build: see the proof entry
On this page
How do you find your equivalent of a competitor's part when each catalog uses different names and abbreviations? For this industrial distributor, the lookup often led to PDFs, supplier websites and colleagues' memory. The build focused on making the evidence easier to find and the approval decision easier to record.
This first-party case study describes the product-graph design and consultant workflow from the original implementation report. The screenshots and design explain the approach; they do not establish the current production catalog size, deployment status or a measured improvement in matching accuracy.
Find candidate equivalents across catalogs
The foundation described in the build is a Neo4j knowledge graph containing records from multiple catalogs. Products connect to suppliers, categories and reviewed cross-references. Imported catalog records and approved equivalences remain distinct: having a product in the database does not mean every proposed substitution is valid.
Getting records into the catalog requires a pipeline, not just an import. Source-specific normalizers reconcile field names; a parsing pass extracts specifications from descriptions into fields that can be searched. A measurement can keep both the original display value and a numeric representation for range queries. Source provenance and validation are needed before those fields are used for a match.
Why a graph? Equivalence is a relationship that can carry its own evidence, reviewer and date. A path from product A to B to C can surface a candidate worth inspecting. It does not prove A can replace C in a particular application: ratings, tolerances and use conditions still need review.
Review and approve a proposed match
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.
Illustrative matching interface. The displayed candidate scores are example ranking signals, not independently validated matching accuracy or approval probabilities. A specialist must check specifications and application before accepting an equivalent.
The human makes the call. An approval records an equivalence decision with its evidence, reviewer and date. A rejection is stored too, so colleagues can see why a candidate was rejected. A changed specification or application may justify reopening either decision.
A proposed substitution needs a person to inspect the relevant specifications and application. Recording approval and rejection decisions gives the next consultant useful context. A changed product specification should trigger a fresh review rather than inherit an old decision forever.
Search by part number, description or image
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.
Text and image embeddings support similarity searches alongside exact part-number and specification matching. Similarity helps retrieve candidates; it is not evidence that two products are interchangeable.
The aim is to make differences in vocabulary less of an obstacle. Exact identifiers, specification filters and human review still matter when descriptions or images are ambiguous.
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.
The natural-language interface translates a question into a graph query and summarizes the returned records. Query validation, access limits and clear handling of incomplete results matter as much as the language model. A successful query is not by itself proof the answer is complete.
Account teams should not have to learn a query language to inspect catalog records. They do need to see where an answer came from and whether the records support it.
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.
The workspace groups jobs by the milestones consultants use: profile, data collection, presentation, signature, scheduling, install and handoff. Aging indicators help surface work that needs attention; thresholds should follow the team's agreed process.
Illustrative pipeline interface. The displayed counts, ages and account records explain the proposed workflow; they are not verified production activity or measured business results.
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.
| Tool | Who uses it | What it replaces |
|---|---|---|
| Product knowledge graph | Everything else is built on it | Flat exports, siloed catalogs, an unqueryable workbook |
| Match-and-approve workflow | Solutions consultants | Manual candidate lookups across catalogs |
| Hybrid search (text, vector, image) | Consultants and inside sales | Keyword search that breaks on supplier abbreviations |
| Natural-language query + dashboard | Account managers and leadership | Report requests and spreadsheet exports |
| CRM pipeline workspace | Solutions consultants, daily | Salesforce tab-hopping and shadow tracking spreadsheets |
So where's the AI?
AI assists with language and similarity: interpreting a question, finding candidate records and summarizing results. The graph stores the records and reviewed relationships. Keep those roles separate so a fluent answer is not mistaken for an approved product substitution.
Further matching work can use graph paths to suggest candidates for inspection. The consultant workspace described above is part of this case-study design; future additions should be identified separately and checked against released implementation evidence.
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
- The client's taxonomy is the source of truth. Competitor catalogs map into the client's category system, never the reverse. The graph speaks the language the business already uses.
- Human decisions become permanent data. Approvals and rejections are written into the graph with provenance — who, when, how confident. Institutional knowledge stops living only in people's heads.
- Data quality is a feature, not a cleanup phase. Scraped catalogs are messy, so the build includes garbage detection, per-product quality scoring, and an audit interface — because one visibly wrong record costs more trust than a hundred right ones earn.
Start with one product category and a known set of lookup questions. Measure whether consultants find the right evidence and whether rejected candidates stay rejected. Expand only after reviewing errors, not simply because the catalog can hold more records.
Frequently Asked Questions
Why use a graph database instead of spreadsheets?
Does the AI decide which products match?
What is the platform built on?
Could this work outside industrial distribution?
Book a 30-minute call to discuss your workflow, ask questions and decide on a useful next step, with no obligation.
Want this working in your business — not just on paper?
Book a 30-min call to talk through your workflow, ask your questions, and discuss a useful next step. No pitch, no obligation.
Book a 30-min call