How to answer product catalog questions by phone or chat
Short answer: A searchable catalog page on your site handles this for anyone willing to look it up themselves. For calls and chat that still come in, an AI agent loaded with your actual catalog (via a platform like ElevenLabs' agent builder) can answer spec and availability questions directly, but keep pricing on a live lookup rather than a static document, since catalog prices change more often than people update the document.
Your staff answer the same catalog questions, specs, compatibility, what's in stock, over and over, and you want the routine ones handled without someone looking it up every time.
I'm Ranjit, and I run Blur Studio: 15+ years building software, 120 apps taken live, and clients who have gone on to raise $10M+. I build AI systems and processes that help businesses do a lot more with a lot less time. I also work differently from most of what else is out there, more on that further down this page. Say hello.
This page may contain affiliate links from which Blur Studio earns commissions.
Distributor catalog questions are repetitive by nature: the same handful of product lines get asked about constantly, and most of the information needed to answer already exists in your catalog, it's just not accessible to the person asking without calling or messaging someone who knows where to look. The cost of this isn't just the time spent answering, it's the inconsistency of who's actually fielding the question, a new hire and a 10-year veteran will give subtly different answers to the same spec question if they're both working from memory rather than the same source document.
Start with a search page
If your catalog isn't searchable online already, that's the cheapest first fix: let customers look up specs and availability themselves. It solves the problem completely for anyone willing to self-serve, and it costs far less to build than a conversational agent. The broader habit is covered in stopping the same customer questions all day.
Where an AI agent fits
For calls and chat messages that still come in, an AI agent loaded with your catalog as its knowledge base can answer directly. Upload your catalog documents (PDF, Word, text, Markdown, HTML, EPUB, or URLs, up to 20MB per file) and the agent answers spec and compatibility questions from that content. How much you can load scales by plan, from roughly 1MB on Free up to 1GB on Business and Enterprise, with Creator (20MB) or Pro (100MB) usually plenty for a typical catalog's worth of documentation. See ElevenLabs' current plans for the exact limits and pricing on each tier. The wider method is described in building an AI that answers from your documents.
Keep pricing out of the static knowledge base specifically. Catalog prices change more often than someone remembers to update a document, and a confidently wrong price is worse than the agent saying "let me check the current price for you." If pricing needs to be in the conversation, it needs a live lookup connection, not a static file. Connecting a bot to live data is shown in letting a voice bot look up order status, using order status as the example.
A worked example: an industrial parts distributor carrying roughly 5,000 SKUs across a dozen product lines has a genuinely large catalog, likely well into the hundreds of megabytes once you include full spec sheets and compatibility charts for every line. That pushes past Pro's limit and into Scale or Business territory, which is worth sizing accurately before you commit to a tier, since discovering mid-upload that your plan can't hold the full catalog is a frustrating way to find out. A smaller specialty distributor carrying a few hundred SKUs in two or three product lines fits comfortably inside Creator's much cheaper limit. Catalog size, not call volume, is usually what decides the right plan tier for this specific use case.
Step by step
- Start with a searchable catalog page if you don't have one, and see how much call and chat volume it actually reduces.
- For remaining calls and chats, load your current catalog documentation into an agent's knowledge base.
- Test it with real spec and compatibility questions your team actually gets, including ones about older or discontinued products.
- Decide explicitly whether pricing is in scope. If yes, connect a live lookup rather than loading a static price list.
- Review transcripts regularly and update the catalog documents whenever your actual lineup changes.
Practical tips
- Discontinued products cause more confusion than new ones. Make sure your catalog documents clearly mark anything no longer available, since an agent answering as if an old product is still in stock creates a worse experience than just not having the information at all.
- Compatibility questions need precise source documents. If customers often ask "does X work with Y," make sure your documentation states compatibility explicitly rather than requiring the agent to infer it from separate spec sheets, which is where mistakes creep in.
- Treat pricing as a separate problem from specs. Specs and compatibility change rarely enough that a document works fine. Pricing changes often enough that it shouldn't live in the same static file at all.
Search page vs. agent vs. a person: who should handle what
| Question type | Best handled by |
|---|---|
| "What's the spec on part X" | Search page (self-serve) or agent (phone/chat) |
| "Does X work with Y" | Agent, if your documents state compatibility explicitly |
| "What's the current price" | Live lookup only, never a static document |
| "Can you get me a bulk discount" or custom order terms | A person, every time |
| "Is this part actually in stock right now" | Live inventory lookup, not a static catalog document |
The pattern across all of these: the agent is strong on static, factual information that doesn't change often, and weak the moment a question needs either a live number or actual negotiating judgment. Design the handoff rules around that line clearly, rather than letting the agent attempt an answer on something it was never going to get reliably right.
A mistake worth avoiding
The failure pattern that shows up most with catalog agents is loading in old marketing PDFs alongside current spec sheets, with no clear signal to the agent about which one is authoritative. If your catalog has been through a few redesigns, there are probably older documents floating around with slightly different specs for the same product line. Audit what you're actually uploading before you load it, not just whether it mentions the right product, since two documents disagreeing on a spec is a worse outcome than one document being incomplete. Before any major upload, it's worth a short exercise: pull the three or four most recent spec sheets for each core product line, confirm which one reflects the current version, and archive or clearly label the superseded ones rather than deleting them outright in case you need the history later. That one pass catches most of the stale-document problem before it ever reaches a customer.
Handling cross-reference and substitute questions
A specific, recurring distributor question is worth planning for separately: "I used to buy part X from a competitor, what's your equivalent." This is a cross-reference or substitute lookup, and it's genuinely harder for an agent to get right than a straightforward spec question, since it requires the documentation to explicitly map competitor part numbers or specs to your own catalog, not just describe your own products in isolation. If this is a common question in your business (it often is for industrial and electrical distributors specifically), build a dedicated cross-reference document rather than hoping the agent infers equivalence from separate spec sheets on its own. Getting a substitute recommendation wrong, suggesting a part that doesn't actually match, is a worse outcome than the agent saying it needs to check with a specialist, so keep the confidence threshold high on this specific question type and route anything uncertain to a person who knows the product line. Part numbers and SKUs need their own handling, see stopping a phone bot from reading part numbers wrong.
What I'd tell a distributor weighing this
This is a strong fit for AI agents specifically because catalog questions are genuinely repetitive and the correct answer is almost always sitting in a document somewhere already. The part I'd be careful about is pricing, which is exactly the kind of data that goes stale the fastest and causes the most friction when it's wrong. Split the problem: specs and compatibility from documents, pricing from a live source, even if that means a bit more setup work up front. The businesses that get the most value from this tend to be the ones with a genuinely large, stable catalog where the same questions repeat constantly across a big customer base, not a small distributor with a handful of product lines where a person can already answer most questions from memory faster than any system could look them up.
How I'd approach this
Loading your catalog documentation is something your team can do directly. Where I usually get involved is building the live pricing or inventory lookup, so the agent can give a real current price or stock answer on the call instead of either guessing or always deferring to a human for a question it could otherwise answer cleanly. The cross-reference piece, if that's a common question for your product lines, is the other place a custom build earns its cost: structuring your catalog data so competitor-to-your-brand lookups are reliable, rather than hoping free-text documents happen to cover every substitution someone might ask about. For a distributor with a genuinely large, frequently updated catalog, I'd also set up a process for keeping the agent's documents in sync with whatever system holds your real catalog data, rather than relying on someone remembering to re-upload a file every time the lineup changes.
Questions people ask
Can an AI agent answer catalog questions directly?
Yes, once your catalog documentation is loaded into its knowledge base. It answers spec and compatibility questions from that content rather than a hand-written script.
Should pricing be part of the agent's knowledge base?
Not as a static document. Catalog prices change too often for that to stay accurate. If pricing needs to be answered live, connect a real lookup instead of loading a price list that will go stale.
What about discontinued products?
Mark them clearly in your source documents. An agent that doesn't know a product is discontinued will answer as if it's still available, which creates a worse experience than giving no answer at all.
How much catalog content can I load?
It depends on your plan, from roughly 1MB on Free up to 1GB on Business and Enterprise, with Creator or Pro's limits usually enough for a typical catalog's documentation.
Is a search page enough on its own?
For customers willing to self-serve, often yes, and it's cheaper to build than a conversational agent. Add the agent specifically for the calls and chats that still come in despite having a search page.
What should I test before launching this?
Real spec and compatibility questions your team actually gets, including ones about older or discontinued products, before pointing real customer traffic at it.