Technical Support Chatbot for a Small Supplier: Build, Buy or Skip?

Skip the chatbot if your technical enquiries are few or mostly one-off, buy one if the same documented questions arrive dozens of times a week, and build only when you have a developer and volume that an off-the-shelf tool cannot handle. Whatever you choose, a chatbot should quote your datasheets and hand safety and compatibility decisions to a person.

Technical product support is different from shop FAQs. The customer is often mid-job, a wrong answer can mean a failed installation or an unsafe use, and many questions depend on details only an engineer sees. So the real choice is not "chatbot or no chatbot" but how much of the question mix a bot can answer with a cited source, and what happens to the rest.

Follow me on Instagram@sagnikteaches

Sort your enquiries before you shop

Take the last 100 technical enquiries from email, phone notes and web forms and sort each into one of four piles. This single exercise usually decides the build-buy-skip question better than any product demo.

Connect on LinkedInSagnik Bhattacharya

1. Lookup. The answer is printed in a datasheet or price list: dimensions, thread size, temperature range, certifications, lead time, whether a part is in stock.
2. Selection. The customer describes an application and wants the right part. A bot can shortlist, but a mistake costs money.
3. Judgement. Compatibility with a chemical, a load, a pressure or a standard. This needs a qualified person and often a record of the advice.
4. Admin. Order status, returns, invoices, delivery. Not technical, and the easiest to automate.

Suppose a ten-person supplier of hydraulic fittings sorts its 100 enquiries and finds 34 lookup, 21 selection, 12 judgement and 33 admin. A bot can carry the 34 lookups and most of the 33 admin messages with low risk. The 21 selection enquiries are for assisted use with a human check, and the 12 judgement ones should never be answered without a person. That is a 67% share that is plausibly automatable, and 33% that is not.

Subscribe on YouTube@sagnikteaches

A volume rule you can run on a napkin

Count technical enquiries per week and minutes per enquiry, then multiply by the safe share. Using the fittings supplier: 40 enquiries a week at 12 minutes each is 8 hours. If 60% are safe for a bot, 4.8 hours a week come off the desk, about 250 hours a year. At $30 an hour fully loaded that is roughly $7,500 a year. This is an illustration; your numbers will differ.

These bands are a working rule, not a published benchmark. The cost side matters as much: a tool that costs $100 a month but needs two hours a week of checking is not cheap when the checker is your most senior technician.

Skip: when the answer is a better website

Skipping is a fair outcome. A small packaging-materials supplier that gets 15 technical enquiries a week, mostly about unusual board sizes, gains little from a bot. Three cheaper moves usually do more:

• Put the five most asked questions, with the number of the part they concern, at the top of each product page.
• Add a short form that asks for the application, quantity and deadline, so the first reply from a person is complete instead of a string of clarifying emails.
• Keep a shared document of verified answers that your sales team can paste from. The company knowledge base tutorial shows how to structure one so that an assistant can later use it.

If your team already uses an AI assistant, paste the question and the document into it and ask for a draft reply for a human to check. That is a staff tool, with no customer-facing risk.

Buy: what to look for in an off-the-shelf tool

Buying suits suppliers whose answers live in documents and who want a bot on the website within weeks. Compare tools on behaviour rather than brochures. Ask each vendor, in writing:

• Does every answer show the source document and page, so a customer or your staff can check it?
• Can I restrict the bot to my documents and have it refuse when nothing matches?
• Can I set topics that always go to a person, such as safety, load ratings and chemical compatibility?
• Do I get full conversation logs, and can I export them?
• What happens to my documents and chats: are they used to train models, and can I delete them?
• How is pricing counted: seats, conversations, resolutions? What does a busy month cost?

Prices change often and many vendors quote by conversation volume, so check each vendor's current page rather than relying on an article. For the related buying question in an online shop, the comparison of chatbots for Shopify stores covers the commercial side.

Build: when it is justified and what it really involves

A custom build means someone connects a language model to your documents through a retrieval pipeline, writes the instructions, builds a chat window, adds logging and handover, and then maintains it. Build only if all of these are true: your catalogue is too complex for the tools you tried, someone on the team can maintain it, and the enquiry volume pays for that person's time. Model API usage is priced per token, separately from a chat seat (some plans now include a monthly allowance of API credits, so check yours), which means a build has running costs that a chat plan does not.

A middle path costs little: create a project in ChatGPT or Claude, load your datasheets, and let sales staff use it internally. Both offer projects that hold files and instructions. Sharing one project with colleagues needs a team plan (ChatGPT Business or Claude Team, each $20 a seat a month on annual billing or $25 monthly, from two seats), but one person can test the idea on a free or individual plan first. This tests whether your documents are good enough for any bot, and the answer is often no, which is useful to find out before paying for a tool.

Accuracy and liability: write the refusal rules first

A wrong answer from a bot is your wrong answer. Customers will not distinguish between the chatbot and the company. So the instructions you give the bot matter more than the model behind it. Here is an illustrative rule set for the fittings supplier.

You answer questions for a hydraulic fittings supplier using ONLY the supplied documents.
Rules:
1. Quote the exact figure and name the document and page. Never estimate or round.
2. If the documents do not contain the answer, say so and offer to pass the question to the technical team.
3. Never recommend a part for a pressure, temperature, fluid or load unless the datasheet states that exact rating.
4. Questions about safety, regulatory approval, chemical compatibility or suitability for a specific installation
   always go to a person. Reply: "That needs a person to confirm. I have sent it to the technical team."
5. Never say a part is "safe", "compatible" or "approved" unless a document states it in those words.
6. Show the part number in every answer. Say that you are an AI assistant if asked.

Rule 5 matters. Language models produce fluent confident text, and "yes, that will be fine" is exactly the sentence that creates liability. Insist on the document's own words.

A risky question and the right reply

A customer writes: "Will the 3/8 inch brass fitting handle hot water at 90 degrees for a heating loop?" A well-set bot replies, illustratively: "The datasheet for this part lists a maximum operating temperature of [figure from document] and a maximum pressure of [figure]. I cannot confirm suitability for your specific installation, so I have sent your question to the technical team, who will reply by email." The bad reply is a smooth "Yes, brass is fine for hot water". The difference between those two is the instructions, not the model.

Where the bot will be wrong anyway

• Superseded documents. A catalogue from two years ago says a part exists that you have discontinued. Delete old files and keep a "discontinued, replaced by" list.
• Tables read badly. Dimension tables in PDFs sometimes lose their column alignment when text is extracted, so the bot pairs the wrong size with the wrong rating. Spot-check ten table-based answers.
• Units. Mixed metric and imperial figures get conflated. State the unit in every document or ask the bot to repeat the unit with each number.
• Similar part numbers. Parts that differ by one character are easy to confuse. Test with deliberately similar numbers.

A four-week trial that cannot hurt a customer

Run the trial in stages so that risk rises only after the bot has earned it. The principle is the same as the baseline step in setting a baseline before you introduce AI: know your current numbers first.

1. Week 0, baseline. Count technical enquiries, minutes to first reply and the share reopened because the first answer was wrong.
2. Week 1, test set. Write 60 real questions, with the correct answers checked by your best technician, split across the four piles. Include 10 you expect the bot to refuse.
3. Week 2, staff-only. Staff ask the bot the test set and score each answer. Do not publish yet.
4. Week 3, shadow mode. Run the bot on live enquiries but show its answers only to staff, who send or edit them.
5. Week 4, limited public release. Put it on one product category, with a visible "talk to a person" button, and read every conversation daily.

Score the test set with a plain table. Illustrative results for 60 questions:

Here 50 of 60 are acceptable outright (83%) and 56 of 60 are safe (93%), but four answers are unacceptable. Decide your gate before you start: for example, no wrong or should-have-refused answers on safety topics, and at least 90% correct or safely refused overall. If the bot fails, find the cause (document, instruction or tool) and rerun the full test set, because fixing one answer often changes another.

Three suppliers, three answers

• A valve and fittings distributor with 120 enquiries a week and large datasheet library: buy, restrict to lookups and admin, escalate every application question.
• A specialist electrical-components wholesaler with 25 enquiries a week, many involving wiring standards: skip the public bot, use an internal assistant for staff to find datasheet answers faster.
• A workwear and safety-equipment supplier where almost every question touches certification: skip customer-facing automation for technical questions, automate order status and returns only, which is the lower-risk work in the order tracking and returns tutorial.

Preparing the documents: the unglamorous half of the job

Whether you buy or build, results depend on the files you load. Spend a day on this before any trial.

1. Inventory. List every document a customer might need: datasheets, installation guides, certificates, compatibility charts, warranty terms, price lists, delivery terms.
2. Retire. Mark anything superseded. If you cannot tell whether a file is current, it is not loaded.
3. Name each file with its part number and revision date, so a cited source shows the customer which version was used.
4. Check scanned PDFs. A scan that is only an image may not be readable by the tool at all. Open the file, try to select a line of text, and if you cannot, get a text version from the manufacturer.
5. Add a plain-language layer. Write a one-page "which part for which job" summary for your top 20 products, checked by a technician, because raw datasheets rarely answer in the customer's words.

Imagine a supplier loading 140 files and discovering during the audit that 31 are older revisions and 9 are image-only scans. Without the audit, one in four answers could have drawn on the wrong source. This is why the document step is where accuracy is won.

What a good and a bad exchange look like

Illustrative exchange with a customer of the fittings supplier, bot answers in italics.

Customer: "What is the thread on part 0471?" Bot, correct: "Part 0471 has a 3/8 inch male thread according to datasheet 0471, revision 4, page 1. Would you like the matching female coupling?" This is a lookup, cited, with a useful next step. The thing to fix, if anything, is the offer of a coupling: check that the bot only suggests parts that the compatibility table lists.

Customer: "Can I use it with diesel?" Bot, bad: "Yes, brass fittings are commonly used with diesel." This is a plausible general statement and not from your documents, so rule 3 and rule 5 should have blocked it. The fix is to add "never draw on general knowledge" to the instructions, then rerun the full test set, since the bot may now refuse more often than it should.

Customer: "Do you have the 0471 in stock?" This is an admin question. The bot should only answer if it reads live stock; otherwise it should say it cannot see stock and give the sales contact. A bot that guesses stock levels from last month's price list is a common failure.

Comparing the three routes on cost, honestly

Here is a cost shape for the fittings supplier, using placeholders you should replace with real quotes. The point is which lines exist, not the amounts.

The time estimates are working assumptions from similar small deployments, not measured benchmarks, so replace them with your own after the trial. If the first month's review time is higher than the hours the bot saves, the setup is not ready, whichever route you chose.

A weekly review sheet for the first month

Each week, read at least 30 conversations and record, for each one, what the customer asked, what the bot said, whether the source was right and whether the outcome was good. Count four numbers: wrong answers, correct refusals, missed escalations and customers who asked for a person. Then decide one change. For instance, if three wrong answers share a cause (all came from a table), fix the table rather than rewriting the instructions. If missed escalations cluster around one phrase such as "is it rated for", add that phrase to the always-escalate list. Change one thing a week so you can tell what helped.

The same discipline applies to any customer-facing AI, from rule-based flows to a full language-model bot. If a fixed rules menu answers your top ten questions, it can be the safer option for exactly the topics where invented wording is a risk.

Writing the handover so the customer is not stranded

The moment a bot says "a person will reply" is the moment trust is won or lost. Promise only what you can do. If the technical team answers within one working day, say so. Capture the customer's email, the part number discussed and the full conversation, and send all three to the team in one message, so the technician does not start from zero. An illustrative handover note: "Customer asks whether part 0471 suits hot water at 90 degrees for a heating loop. Datasheet gives a maximum temperature and pressure; the bot did not confirm suitability. Reply needed by tomorrow noon."

Measure the handover as carefully as the bot: how many conversations were escalated, how long the first human reply took, and how many customers left without an answer. A bot that deflects 60% of questions but leaves 15% of customers stranded is not a success.

Keeping the answer current after launch

A bot is only as accurate as the newest document you gave it. Assign one person to update the document set whenever a datasheet changes, and review a sample of conversations weekly for the first month and monthly afterwards. Keep a short log of every wrong answer, with the cause, so you can see whether the fixes are working. If you would like help deciding which questions to automate and which to keep with people, that is what my AI implementation consultation is for.

Questions suppliers ask before trusting a chatbot with technical answers

Can a chatbot answer questions that involve safety or compatibility?

It should not decide them. Let it quote the datasheet, show the part number and hand anything about load ratings, chemical compatibility or safety to a named person. A wrong answer here is a liability problem, so the bot's default must be to refuse and escalate, not to guess.

How many enquiries justify a chatbot?

There is no universal number, but a working rule is that under about 30 technical enquiries a week rarely repays a paid tool, while several hundred repetitive ones usually do. Measure your own count and minutes per enquiry for two weeks before deciding.

What documents does the bot need?

Current datasheets, installation guides, compatibility tables, return and warranty terms and a list of discontinued parts. Old catalogues are the biggest danger, because the bot will quote them confidently. Remove superseded files before you load anything.

Do I have to tell customers it is an AI?

Say so plainly in the chat window and give a visible route to a human. It protects trust, and some customers want the human immediately. Check any rules that apply to your customers' own markets with an adviser.

Is a free ChatGPT or Claude project enough?

For one person testing, often yes: load datasheets into a project, ask real questions and check every cited source. For the sales team to share it you need a team plan, because project sharing is a ChatGPT Business or Claude Team feature. For customer-facing use, you need logging, access control and a clean handover, which a plain chat project does not give.

Further reads

• How to Build the FAQ Your AI Chatbot Needs Before Launch — Write the answers document a bot will draw on.
• Can ChatGPT Read PDFs, Spreadsheets and Photos? What Breaks — What breaks when an assistant reads datasheet PDFs and tables.
• AI Receptionist or Answering Service for a Booking-Based Business? — The same build-or-buy logic applied to phone enquiries.
• Is AI Worth It for a One-Person Bookkeeping Business? — A short worth-it test you can borrow for any small team.
• AI Dispatcher or Dispatch Service? An Owner-Operator Cost Check — Another buy-versus-service cost check in a logistics business.
• How to Offer Multilingual Customer Support With AI Translation — If technical questions arrive in several languages.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: ChatGPT Business and Claude pricing pages (projects, project sharing, seat prices, API credits), checked 5 November 2026; all enquiry volumes, times and costs are illustrative.