AI features clients actually use (and the ones they don't)

Most AI features for business die in the demo. They look incredible in a Friday show-and-tell, get a round of nods, ship to production, and three weeks later nobody is using them. I have shipped enough of them — chatbots, content generation, intelligent search — with the Vercel AI SDK to see a clear pattern of which ones earn their keep and which become expensive demo-ware. The difference is almost never the model. It is whether the feature was attached to a metric before a single line was written.

This is the honest version. Not a feature list, but what actually moved deflection, conversion and hours saved across real client builds — and the tell that lets you predict it before you spend the budget.

The test I run before building any AI feature

Every AI feature I ship has to name its metric up front. There are only three that matter, and if a proposed feature cannot claim one, it is a demo:

• Deflection — support tickets or sales questions answered without a human.
• Conversion — visitors who buy, book, or sign up who otherwise would not have.
• Hours saved — internal time a human no longer spends on a repetitive task.

That is the whole filter. "It would be cool if the site could chat" names no metric, so it is demo-ware. "Our showroom team answers the same 40 questions about range and charging every day" names deflection, so it is a product. The difference lives in how the client describes the problem, not in the technology. You can hear demo-ware in the brief.

The AI features that actually worked

Intelligent, typo-tolerant search

This is the most underrated AI feature for business, and the one I would build first almost every time. On the NIO regional EV platform the catalogue and content live in Sanity, and a regional audience searches in mixed English and transliteration with inconsistent spelling. Plain keyword search returns nothing for "battary range" or a half-typed model name — and a zero-results page is a lost lead.

Semantic, typo-tolerant search over embeddings fixes that. It matches intent, not just strings, so "how far on one charge" finds the range content even though none of those words appear in it. It is cheap to run, the embeddings are computed once at publish time, and the metric is unambiguous: fewer zero-result searches, more product and content pages reached. It moved conversion because people found things they would otherwise have bounced on. No chat bubble required. If you are weighing search against a bot, I usually argue for search first — more on that in how I think about AI features clients use.

A grounded chatbot, but only on the right surface

Chatbots are where most of the demo-ware lives, because the demo is so easy and the production version is so hard. A bot answering from a vague prompt is a liability. A bot grounded in your real catalogue and docs — proper retrieval, citations, a hard refusal when it does not know — is a deflection machine.

The surface matters as much as the build. The same bot that is useless bolted onto a marketing homepage is excellent inside a logged-in dashboard or a support flow, where questions are narrow and the user already has intent. For a product like alfii's HR platform, "how do I run payroll for a mid-month joiner" is a bounded, answerable question against the product's own docs. That deflects a real ticket. "Tell me about your company" on a landing page does not. This is also why I build the feature into the product rather than a generic widget — it belongs alongside the rest of an AI engineering engagement, not bolted on.

Content generation as a draft engine, never a publish button

Content generation works when it drafts and a human approves, and fails the moment you let it publish unattended. In CMS-backed builds I wire generation into the editor — first-draft product descriptions, alt text, meta descriptions, translation between English and Russian — as a button the editor clicks, reviews, and edits. The metric is hours saved per published item, and it is large: a catalogue migration that used to take a week of copywriting becomes a day of editing. It lives natively in the stack — the same Sanity editor the marketing team already uses — so there is no new tool to adopt. The human stays in the loop, so brand voice and legal exposure stay controlled.

The AI features that became demo-ware

The features that died all share a shape: impressive in isolation, disconnected from a metric.

• The homepage chat concierge. Looks like the future, deflects nothing, because nobody arrives on a homepage with a bounded question. The good version of this is search, not chat.
• "AI recommendations" with no data behind them. A recommendation engine is only as good as the behavioural data feeding it. On a fresh catalogue with no purchase history, it is a random-product widget with a sparkle icon. Ship the analytics first; add the AI when there is signal.
• The autonomous agent that runs the whole workflow. The Vercel AI SDK shipped genuinely good first-class agent loops — multi-step planning, tool sequencing, stop conditions — and they are useful for bounded internal tasks. But "an agent that handles the entire sales process" is the most expensive demo you can build: every extra autonomous step multiplies the failure surface, and one wrong action in front of a customer costs more than the whole feature saves. I keep agents internal, supervised, and narrow.
• The chatbot that ungrounds itself. A bot without retrieval and a refusal path will confidently invent a return policy. That is not a feature, it is a liability with a typing indicator.

Why the model is the least interesting choice

I build these model-agnostic on purpose. The Vercel AI SDK gives one interface over Claude, OpenAI and Google, so swapping providers is a config change, not a rewrite. That matters because the frontier reshuffles every few months — the best model for summarisation, for tool-calling, for cost-per-token, and for your latency budget are rarely the same model, and rarely the same one next quarter.

So I treat the provider as a runtime decision, not an architectural one. Pick the cheapest model that passes the evals for the task; keep a fallback wired in for when an API has a bad day; never let the choice of provider leak into the product code. The interesting engineering was never the model. It is the unglamorous 80% around it.

The 80% that makes an AI feature dependable

Anyone can demo a chatbot. The work that makes an AI feature survive contact with real traffic is the part nobody screenshots:

• Evals. A test suite of real questions with expected behaviour, run on every prompt or model change, so you know if an "improvement" silently broke something.
• Grounding and refusals. Retrieval against real data, citations, and an explicit "I don't know" path. A feature that cannot say no is a feature that lies.
• Fallbacks and cost ceilings. A second provider when the first fails, and a hard spend cap so a traffic spike or a prompt-injection loop cannot run up a five-figure bill overnight.
• Observability. Logging inputs, outputs and cost per call, so you can measure the metric you promised instead of guessing.

This is the difference between an AI feature and an AI demo, and it is most of the engineering. It is also why I wire AI into the existing Next.js or Laravel app rather than bolting on a third-party iframe — the feature has to share the app's auth, data, rate limits and deploy pipeline to be trustworthy.

If you are scoping an AI feature, the first question is not "which model" or even "chatbot or search." It is: which of deflection, conversion, or hours saved does this move, and how will we measure it. Answer that honestly and you will build the few features clients keep using. Skip it and you will build a great demo.