The problem with technical support at scale
Compressor World has been selling industrial compressors for over 20 years. Their catalog covers rotary screw and reciprocating compressors, dryers, filters, receivers, and accessories from brands like Quincy, Atlas Copco, Sullair, and Ingersoll Rand. Their customers are operations engineers, procurement managers, and chief mechanics at manufacturing plants, food processing facilities, and automotive workshops. B2B buyers who know exactly what they need — and have zero patience for friction.
So they ask. "Which compressor do I need for a 200 CFM application?" "Where's the manual for the Atlas Copco GA90?" "How do I wire 208V to this unit?"
Routine queries. But there were a lot of them, and they were landing on the support and sales team all day. Time that should go toward qualified leads and complex consultations was getting eaten by questions that had documented answers — answers buried somewhere inside 4,000+ PDFs, spec sheets, and FAQ files.
The second problem was traffic. Buyers who couldn't find answers on-site went to Google. And Google sent them to competitors. Compressor World was doing the research work — maintaining deep product documentation — but losing the buyer at the last step.
The third problem was conversion. Visitors in active evaluation mode (comparing specs, checking compatibility, reading manuals) were on the site with high purchase intent. There was no mechanism to capture that intent before they left.
The approach: build the assistant on their own documentation
A general-purpose chatbot pulls answers from the open web. For industrial equipment — where a wrong CFM rating or wiring diagram can be expensive — that's not an option. The assistant had to be grounded in Compressor World's own documentation, and every answer had to be traceable back to a specific source.
We built AskAC.ai using a Retrieval-Augmented Generation (RAG) architecture:
- Document ingestion. PDFs, spec sheets, CSV files, and FAQ documents stored in Google Drive are parsed, chunked, and processed via LlamaIndex.
- Semantic indexing. Chunks are vectorized and stored for semantic retrieval. A user asking "how do I size a compressor for sandblasting?" gets matched to relevant spec sections, not just keyword hits.
- Response generation. OpenAI GPT-4o generates answers from the retrieved context, with structured citations back to the source document. The assistant shows where each answer came from.
- Automatic updates. The indexing pipeline runs on a schedule. When Compressor World updates a spec sheet in Drive or Dropbox, the assistant picks it up automatically — no manual re-indexing required.
The assistant runs as an embeddable widget. It appears on the Compressor World site without redirecting users to a separate help portal. The help finds them where they are.
Lead capture was built in from the start. After answering a technical query, AskAC.ai surfaces contextual follow-up prompts based on the conversation: "Need help sourcing?" or "Want a quote for this unit?" A buyer who just confirmed that a Quincy QGS-15 fits their application sees an invitation to request a quote — at the exact moment they've made their decision.
The stack
The technical architecture was chosen for reliability and the specific demands of a document-heavy AI application:
- NestJS — API routes, document indexing pipeline, admin endpoints, and subscription logic
- Next.js — public chat page, embeddable widget, and admin interface
- PostgreSQL — user records, query logs, and per-account request limits
- AWS S3 — PDF and manual file storage
- LlamaIndex — document parsing, chunking, and semantic retrieval
- OpenAI GPT-4o — response generation from retrieved context
Authentication was built in from day one: email/password login, JWT sessions, and free-tier accounts. The monetization layer — Stripe subscriptions at $19.99/month, sponsored placements within responses, automated price fetching from the Compressor World catalog — is scoped and ready for Phase 2.
The team included a PM/BA for coordination and client communication, backend developers handling NestJS and third-party integrations, frontend developers on the widget and admin panel, and an AI engineer on index architecture, semantic search, and prompt tuning.
What shipped
We launched to production with 4,090 documents indexed and available for semantic retrieval.
Initial Q&A testing against real user queries showed high answer accuracy. User feedback on response tone and length was collected post-launch and is informing prompt improvements for Phase 2. The infrastructure is live, serving real queries, and the indexing pipeline is maintaining the knowledge base automatically as documentation gets updated.
For Compressor World, the practical outcome is straightforward. A buyer at midnight comparing CFM ratings gets a sourced answer from the spec sheet. A mechanic looking for a wiring diagram finds it in seconds. The support team handles fewer routine queries. And every answered query is now a potential sales touchpoint.
When this architecture makes sense for your product catalog
A source-grounded AI assistant is the right build when a few conditions are true at once.
Your support load is documentation queries. If most incoming tickets are "where is X" or "what's the spec for Y," you're paying people to be a search engine. That's the clearest signal this approach will have impact.
You have existing documentation. A RAG pipeline needs source material: spec sheets, manuals, FAQs, compatibility guides, installation instructions. If this exists — in PDFs, spreadsheets, Drive folders, anywhere structured — you have the raw material to index. If documentation is thin or scattered, you'll need to build content before you can build the assistant.
Accuracy matters. Industrial equipment, medical devices, regulated products — any domain where a wrong answer has real consequences. The citation layer (every answer linked back to a source document) is what makes the assistant deployable in these environments. The model can't improvise from general knowledge.
You're losing visitors to competitor search results. Buyers who can't find answers on your site go to Google. If that's happening at volume, the assistant addresses two problems at once: it keeps buyers on-site, and it captures intent before they leave.
You have conversion intent. If visitors in evaluation mode represent real pipeline, the assistant is a conversion tool as much as a support tool. The follow-up CTAs turn a resolved query into a lead.
If four or five of these apply, the build is worth evaluating. If fewer than two apply, better documentation and site search will cover most of the gap at lower cost.
Explore our expertise in AI development and integration.
We build AI-powered tools for companies with complex product catalogs and technical documentation. If you're working through a similar problem, talk to us.
Frequently Asked Questions
A standard chatbot either follows a fixed decision tree or pulls answers from the open web. A source-grounded assistant is different: it generates answers only from a defined set of documents — your spec sheets, manuals, FAQs — and cites the specific source for every response. The model has no access to external knowledge during a query. That constraint is what makes it usable in technical environments where accuracy matters.
The ingestion pipeline we built for AskAC.ai handles PDFs, CSVs, and Excel files — the formats that make up the bulk of most product documentation. Google Sheets and Dropbox are supported as source integrations, so the pipeline can pull directly from wherever your team already stores documentation. Image-heavy PDFs (scanned manuals, for example) require an additional OCR layer, which adds processing time but is fully supported.
The short answer is: constrain what it can draw from. In a RAG architecture, the model generates its response from the chunks retrieved from your own documents — not from its training data. If the answer isn't in the indexed documentation, the assistant says so rather than improvising. The citation layer reinforces this: every response points back to a source, so users can verify answers themselves and so you can audit accuracy over time.
The indexing pipeline runs on a schedule and re-processes documents automatically. When Compressor World updates a spec sheet in Google Drive, the assistant picks up the new content on the next indexing cycle without any manual intervention. For time-sensitive updates — a product recall notice, a corrected wiring spec — the pipeline can be triggered manually to index immediately.
For AskAC.ai, we structured the project in phases. The MVP — document ingestion, core chat with source citations, basic admin panel, and production deployment — was the first phase. Phase 2 covers billing, sponsored placements, price fetching, and additional infrastructure. Timeline depends on catalog size, documentation quality, and how many integrations are needed, but a working MVP with a real document corpus is typically achievable within a few months.
The architecture scales down as well as up. 4,090 documents is a large corpus; the same pipeline works for 200. The case for building it gets stronger as catalog complexity increases (more product variants, more technical specifications, more compatibility considerations), but smaller catalogs benefit too — especially when buyers ask questions that cut across multiple product lines or require comparing specifications side by side.