AI Features That Earn Their Place on a Business Website

Most "add AI to your website" pitches end in a chatbot nobody uses. Here are the integrations that return more than they cost, and the volume you need before any of them make sense.

The difference between a demo and a feature

A generic chat widget bolted onto a homepage is a demo. It answers from general knowledge, knows nothing about your pricing or your stock, and users work that out within two questions.

A feature is different. It answers from your material: your documentation, your product catalog, your policies, your past support tickets. The technical name for the pattern is retrieval, and it is the part that most implementations skip. Your content gets indexed into a vector database, the user's question retrieves the passages that actually relate to it, and the model is asked to answer using only those passages.

That constraint is what turns a novelty into something a business can rely on. It also means the quality of the output is mostly determined by the quality of your content, not by which model you picked.

Four integrations that tend to pay for themselves

Support that answers from your own documentation. If the same fifteen questions arrive every week, answering them from your existing help content removes a large share of first-line volume. The measurable result is tickets that never get opened.

Search that understands intent. Keyword search fails when the customer does not know your vocabulary. Semantic search matches meaning, so someone asking for "something for a leaking pipe under the sink" finds the right product without knowing what you called it.

Qualifying inbound enquiries. Instead of a contact form that produces a one-line message, a short guided conversation collects budget, timeline and scope before the enquiry reaches you. Fewer calls that were never going to convert.

Content operations behind the scenes. Drafting product descriptions, tagging and categorizing a catalog, summarizing long documents. This one is invisible to customers and often the easiest to justify, because you can count the hours it replaces.

What it actually costs

There are three costs, and only one of them is the build.

Per-request cost. Every question costs a fraction of a cent to a few cents depending on how much context you send. Small at low volume, worth modeling before you launch something on a high-traffic page.

Latency. A retrieval step plus a model call is typically one to three seconds. That is fine for a support answer and too slow for a search box that should feel instant, which is why the two get built differently.

Maintenance. This is the one people forget. When your prices, policies or product range change, the index has to change with them. An assistant confidently quoting last year's prices is worse than having no assistant at all. Budget for the content pipeline, not just the feature.

The failure mode worth designing around

Language models produce fluent answers whether or not they know the answer. On a business website that is a liability, because a confident wrong statement about a refund policy or a delivery time is something a customer will hold you to.

The controls are practical. Restrict answers to retrieved content and have the system say it does not know when retrieval comes back empty. Show the source next to the answer so a customer can verify it. Route anything involving money, cancellations or personal data to a human rather than answering it. Log every conversation and read them, especially in the first month.

On personal data, decide early what leaves your infrastructure. If customer details would be sent to a third-party API, that belongs in your privacy policy and, depending on where you operate, in your compliance review.

When it is not worth doing

Volume decides this. If you handle twenty support emails a month, an assistant will cost more to build and maintain than the time it saves. If you handle two thousand, the arithmetic reverses quickly.

The same applies to search. A site with forty pages does not need semantic search, it needs a clear menu. A catalog with four thousand products is a different situation.

It is also worth being honest about ordering. If your site is slow, your content is thin or your checkout loses people, AI will not fix any of that. It will just be a well-built feature sitting on a weak foundation.

Where to start

Pick the single question your customers ask most often and build the narrowest thing that answers it well. One use case, indexed against real content, measured against what it replaces.

That gives you a number to judge the next one by. It is a slower way to adopt AI than launching a chat bubble on every page, and it is the reason the feature is still running six months later.