From Hidden Shame to Sales Tool: Rebuilding Service Diagram Search with AI
Industry: Industrial Parts Distribution Challenge: Critical vendor software discontinued, leaving broken feature buried for 6 years Solution: AI-powered OEM/transmission diagram-to-part mapping Timeline: 6 months | 1 engineer using Cline + Claude Sonnet 3.5 Results: Restored capability, +30% coverage, sales agents actively using it
The Problem
When a third-party software vendor went out of business, a mid-market industrial parts distributor lost the ability to map service diagrams to part numbers—a critical capability for both customers and sales teams.
For 6 years, the company was stuck with:
- Half-working exploded diagram feature buried in deep menu navigation
- So broken it was intentionally hidden from most customers
- Coverage limited to a small percentage of parts
- Key transmission diagrams completely missing or non-functional
- Product team paralyzed—couldn’t update, fix, expand, or remove it
- Growing technical debt and quiet customer frustration
The pain: Customers expected industry-standard OEM and transmission diagrams to work. Instead, they had to dig through menus to find a feature that barely functioned. Sales agents stopped even mentioning it.
Why it stayed broken for 6 years:
- Rebuilding manually was cost-prohibitive (thousands of diagrams)
- Required computer vision (diagram parsing) + catalog domain knowledge
- No viable vendor replacement for this niche problem
- No internal AI/ML capability to tackle it
The Approach
With a newly built AI team in place, the company decided to solve the problem in-house:
Team: 1 engineer Timeline: 2 quarters (6 months) Stack:
- Cline (AI coding agent) + Claude Sonnet 3.5 in VSCode
- AWS deployment, API Gateway integration
- Modern AI tooling (pre-MCP, pre-memory features—early vibe-coding days)
The technical challenge:
- Parse OEM and transmission service diagrams (visual data, inconsistent formats)
- Map diagram callouts to internal part number catalog
- Handle variations in diagram quality and structure
- Make it maintainable by product team (not an engineering dependency)
Key decisions:
- Build vs. buy: No viable vendors for this niche catalog problem
- AI-powered development: Used early agentic coding tools to accelerate development
- API-first design: Integrate with existing catalog infrastructure
- Product team enablement: Self-service tooling for non-technical users
The bet: One engineer with bleeding-edge AI coding tools could solve a 6-year problem in months.
The Results
6 months after launch:
✅ Capability restored: Customers and sales agents now use OEM/transmission diagrams to find parts
✅ Coverage increased 30%+: New diagrams added across product lines (still expanding)
✅ From hidden to highlight: Feature went from buried/broken to actively promoted by sales
✅ Product team empowered: Can now update and maintain diagrams independently
✅ Technical debt removed: Modern architecture replaces unmaintainable legacy system
✅ Sales enablement: Agents reference diagrams in customer conversations (wasn’t happening before)
Business Impact:
- Feature transformed from liability to competitive advantage
- Customers can self-serve parts lookup from industry-standard diagrams
- Product team responsive to market needs (add diagrams, fix errors, expand coverage)
- Foundation for future AI catalog enhancements
- System architecture applicable to other diagram types/industries
Why This Worked
1. AI capability was in place
The company had spent 18 months building an AI team and infrastructure—this project was only possible because the foundation existed.
2. Right problem selection
High business value, clear scope, tractable with AI, impossible to solve manually at reasonable cost.
3. AI-powered development
Early adoption of agentic coding tools (Cline + Claude Sonnet 3.5) meant 1 engineer could accomplish what would’ve taken a team using traditional methods.
4. Pragmatic execution
Didn’t wait for perfect tools (pre-MCP, pre-memory). Shipped with what was available. Proved value early.
5. Product thinking
Didn’t just rebuild what was lost—built something better that the product team could own and expand.
Lessons for Traditional Companies
If you have “zombie features” from dead vendors:
- AI can solve problems that were cost-prohibitive manually
- Small teams with modern AI coding tools > large teams with legacy approaches
- Build vs. buy depends on problem specificity (niche problems favor build)
- Early/imperfect AI tools still deliver ROI (don’t wait for “perfect”)
- Foundation first: You need AI team/infrastructure before you can tackle these
ROI calculation:
- Old approach: 6 years paralyzed, broken feature hidden from customers
- New approach: 1 engineer × 6 months = capability restored + ongoing product control
- Multiplier effect: Product team maintains/expands without engineering dependency
The meta-lesson: This company used AI to build AI solutions. The same tools they recommend to customers, they used to solve their own problems.
What “Impossible” Problems Are Sitting in Your Backlog?
I help mid-market companies identify which problems AI can actually solve and build the foundation to tackle them.
Contact me via LinkedIn to discuss your situation.