Website chatbot: template or custom

Search “chatbot for my website” and the first screen is widget builders: Intercom, Drift, Tidio, a dozen clones. Each promises a bot in fifteen minutes and a conversion miracle.

On the other side of the market: a custom assistant, grounded on a catalog, scoped from a written brief.

The useful question is the boundary. Overpaying for engineering on a five-question FAQ is waste. Spending a month on a widget that then invents a discount is also waste.

What a ready widget is

Most site chat products are SaaS. One JavaScript snippet, a bubble in the corner.

Two families:

1. Button trees. You draw the flowchart: catalog / prices / talk to a person. Each click has a next node.
2. Hybrid widgets with a model bolted on. The same bubble, plus an API over uploaded files or crawled pages.

Start is fast. A marketer can ship in a couple of days. The limits are not on the pricing page.

When a template is enough

Not every site needs a custom agent. Custom is overkill when:

• The job is a static FAQ. Location, hours, delivery, pickup, returns. The answers do not move for months.
• First-touch capture is the only job. Interrupt, offer a magnet, drop the phone into a sheet or a Telegram notice.
• The list is short and the prices are fixed. Five to ten services with a printed card. Buttons are enough.
• The hypothesis is untested. A new landing, unknown whether anyone chats at all. A small SaaS month is the right experiment.

If the scenario fits, put the widget on and do not hire a repo.

Where the template hits the wall

Trouble starts when a linear widget is stretched over a non-linear job: a real catalog, an expert match, a live database.

People do not think in buttons. “I need a septic for a four-person summer house, high water table, must not float.” The tree says “please choose from the menu.” The visitor leaves.

The traffic tax. SaaS bills per seat, or per unique, or per “lead.” As sessions grow, so does the invoice — including spam, duplicates, and accidental taps. Two years of that bill often exceeds a owned system.

No live system of record. A thousand SKUs, or a clinic grid, cannot be a PDF you remember to re-upload. When the price moved this morning and the file did not, the bot quotes yesterday or promises a unit that is gone.

Hallucinations. A generic model in the widget, with no grounding, will invent a discount, free shipping across a continent, or a competitor’s spec. A promised thirty percent off is not a joke to the person who screenshotted it.

Custom: the model is the mouth, not the catalog

In a grounded build the language model parses the question and writes the sentence. It is not the source of SKUs.

Knowledge sits in an isolated store: catalog, price list, policy, stock. The loop is strict:

1. Parse the turn into parameters.
2. Query the operator’s base.
3. Speak only from hits.
4. If the item is missing or the file is thin — say so, offer a person, do not complete the sentence from the pretraining prior.

On a stand, that pattern grades at 100% on in-catalog items and 100% refusal on absent ones. That is a gate, not a personality.

Two levels of depth:

• Catalog consultant. Structured catalog and price list, hundreds to tens of thousands of rows. No write into the ERP. Most buyers’ questions close here.
• Live system. API into CRM, inventory, or a vertical package (a clinic MIS, a workshop book). Live stock, account prices, open slots.

The second level is the same engineering as an appointment bot. The first level is enough when the question is “which of these fits,” not “is bay three free at 16:00.”

Who owns the loop

A custom bot on the operator’s VPS:

• Code and store are yours. Tariff changes and a vendor shutdown are not a product event.
• No per-contact rent. Token use and hosting are the bill, not a commission on every visitor.
• Commercial confidentiality. Threads, phones, and order lines are not a training corpus for a public network.

Formats, not a shop window of packages

Work is scoped from the catalog size, the match logic, and whether the ERP is in the loop. A first slice on a subset of SKUs before the full book is the sane path. There is no public price table on this site. “Base / standard / premium” as a storefront is a different kind of page, and it is not this one.

A template-then-custom sequence is legitimate: collect the real questions on a widget, then ground a bot on that log.

Models are chosen for the residency brief: hosted Claude or GPT where the data may leave; a local or EU-hosted model where it may not. The widget snippet is a fifteen-minute install. The project time is the knowledge base, the grounding, and the tests that punish invention.

If the product needs a person to choose among three tariffs, a button tree is honest. If it needs a match on area, voltage, or a live slot, the template is the wrong object. Request a scope with the catalog and the answers you will not allow to be invented.