GenAI Parts &
Support Assistant

A large industrial enterprise wanted an internal AI assistant capable of helping technical-support representatives quickly identify parts, interpret documentation, and answer operational questions without manually searching through thousands of pages of material. The problem wasn't a lack of information — it was that the information was fragmented and inaccessible at the speed of a live support call.

The environment was large: SharePoint-based documentation repositories, technical manuals, product support documentation, internal procedural data, and a parts catalog spanning 16,240 rows — with naming inconsistencies across systems and real-world support terminology that often differed from the language used in formal documentation. Reps were context-switching between multiple systems, cross-referencing PDFs, and relying on institutional knowledge that newer employees simply didn't have.

The goal was not to build a chatbot. The goal was to build an assistant support teams could actually trust during live customer interactions — where a wrong answer has real operational consequences. A hallucinated answer in a casual chatbot is annoying. A hallucinated part number inside an industrial support workflow can cause incorrect orders, shipping delays, operational downtime, and a complete loss of confidence in the system.

AOtech designed and deployed the GenAI Parts & Support Assistant using Microsoft Copilot Studio and Azure AI Foundry. The system was architected around retrieval-first behavior rather than freeform generation — responses had to be grounded in enterprise data, not model memory or probabilistic guessing.

The SharePoint documentation environment was processed and indexed for semantic retrieval, allowing support reps to search operational knowledge conversationally instead of manually navigating document libraries. The 16,240-row parts catalog was enriched and optimized specifically for AI retrieval workflows — normalization work that improved matching accuracy across part numbers, aliases, abbreviations, support terminology, partial matches, and legacy naming conventions accumulated across years of product history.

During testing, one critical failure mode emerged: the model occasionally hallucinated part numbers. The responses often appeared technically believable, which made this failure mode particularly dangerous — a rep following a confidently-stated but incorrect part reference would have no obvious signal that something was wrong. AOtech rebuilt the orchestration behavior through a v2 system prompt architecture that enforced stricter grounding and retrieval validation. The updated logic constrained the model to prioritize retrieved catalog data, avoid speculative part generation, refuse answers it couldn't validate, and maintain consistent formatting for reps in live calls. The hallucination problem was resolved. The trust problem — which had been building since v1 — was reversed.

Support representatives gained a single conversational interface for knowledge that had previously been scattered across disconnected systems. Parts identification became faster. Documentation retrieval no longer required navigating libraries manually. Newer reps were able to operate at a higher level earlier because the assistant surfaced institutional knowledge that had previously lived only in the heads of experienced staff.

The v2 system prompt architecture resolved the hallucination issue and restored confidence in the system. Reps in live customer interactions could rely on the assistant's output because the system had been engineered to refuse answers it couldn't validate — not to guess confidently and produce wrong results that looked right.

The project reinforced something AOtech builds for consistently: the model is rarely the hardest part. The difficult work is structuring data correctly, controlling retrieval behavior, eliminating ambiguity, and designing systems people can trust operationally. Anyone can build a chatbot demo. Building an AI system that technical-support teams trust enough to use during real customer interactions is an entirely different engineering problem. That is what this project solved.