A visitor asks a fair question about your pricing or checkout flow. Your team member asks how to complete a task in admin. The chatbot answers confidently — and confidently wrong.

That is the gap between "we added AI" and "AI that understands how your business actually works."

This post shares how we approach grounded assistants on custom platforms: one for customers on the public site, one for staff inside the admin portal. We recently shipped this pattern for Great Lakes Additive, a manufacturing client whose platform we built after outgrowing WooCommerce — but the ideas apply to any business with a non-trivial buyer journey or internal operations.

Who this is for: founders and operators evaluating AI on a product or commerce site, and technical leaders who want LLM integration that prioritizes trust over novelty.

The short version

If you are…Here's the headline
Business / productDon't bolt on a generic chat widget. Restrict answers to approved business knowledge, live product data where it matters, and — for internal users — a snapshot of what needs attention today. When the assistant doesn't know, it should say so.
EngineeringTreat the LLM as a language layer over a curated knowledge base, not an open search engine. Pass page context with each request, keep sensitive config editable in admin, and test answers against real workflows — not demo scripts.

Why "just add ChatGPT" fails

Most off-the-shelf chatbots share the same weaknesses:

  • They don't know your product — policies, edge cases, and workflows live in people's heads or scattered docs
  • They don't know where the user is — checkout questions get FAQ answers; admin questions get marketing copy
  • They hallucinate with confidence — especially dangerous on pricing, fulfillment, and compliance topics
  • They can't see today's work — staff still need a separate dashboard to know what needs action

A static FAQ page avoids hallucination but misses the moment: the user is already on a specific screen with a specific question.

The goal is credible, in-context help that reduces support load without inventing answers.

Design principle: grounded, not generative freelancing

We treat the model as a natural-language interface over a strict knowledge layer.

What grounded assistants draw from

  1. Curated business knowledge — how your product works, what you offer, how customers move from interest to purchase
  2. Live data where accuracy matters — e.g. current catalog, pricing tiers, or availability pulled from the same source your app uses
  3. Owner-editable overrides — text fields in admin so policy and SOP updates don't require a deploy
  4. Page context — the assistant knows whether someone is browsing, configuring, or checking out
  5. Operational snapshot (internal only) — queue counts and recent activity so staff get situational awareness, not generic IT help

What they must not do

  • Guess prices, timelines, or capabilities outside the knowledge base
  • Fabricate customer-specific records the public assistant cannot access
  • Invent UI steps or settings that don't exist

System rules should be explicit: if it's not in the knowledge base, defer to a human channel.

That is the difference between AI on a landing page and operations-grade assistance.

Two assistants, one product

Customer-facing assistant

  • Available where people actually need help — product pages, forms, checkout, support content
  • Context-aware prompts change with the page so suggestions feel relevant, not generic
  • Grounded on approved content plus live data your team already maintains

Internal assistant

  • Lives inside the admin or ops portal — where staff already work
  • Can include a live snapshot of queues and recent activity (orders, requests, tickets — whatever your domain uses)
  • Action-oriented starter prompts reflect what needs attention now, not static FAQs
  • Grounded on internal workflow docs plus editable SOP text

Configuration (provider, model, enablement, knowledge text) belongs in the product, not buried in environment variables — so the business can iterate without engineering for every tweak.

Accuracy is a feature, not an afterthought

The most common failure mode in testing is not gibberish. It is plausible wrong answers — steps that sound right but don't match your software.

That usually means the knowledge base is incomplete, or the model is filling gaps from general training data. The fix is not a cleverer prompt. It is:

  1. Document workflows the way you'd onboard a new hire
  2. Run real staff and customer questions through the assistant before launch
  3. Correct the knowledge base when the model gets something wrong — and add a system rule if it's a recurring mistake

Grounded AI is an ongoing product discipline, not a one-time integration.

UX details that matter in production

Context-aware starter chips — Empty chat widgets feel broken. Suggested prompts should match where the user is standing.

In-app navigation — If replies link to pages on your site, use client-side routing so opening a link doesn't destroy the conversation.

Conversation history — Most LLM APIs have constraints on message order and role sequencing; design the UI layer accordingly (e.g. display greetings without sending them as model turns).

Aligned metrics — If the internal assistant references business numbers, they should match what leadership sees elsewhere in the product.

What we skip (on purpose)

For many products, you do not need:

  • A vector database on day one
  • Crawling every PDF in Google Drive
  • Fine-tuning on customer emails

Start with structured knowledge you already trust, wire in live data where stale answers would hurt, and expand only when retrieval genuinely adds value. Complexity budget should go toward correct behavior, not infrastructure theater.

What we learned

Patterns we reuse across clients:

  1. Ground first, generate second — The knowledge base is the product; the model is the interface
  2. Context beats clever prompts — Page-aware help outperforms one global "How can I help?"
  3. Test against real workflows — Especially operations flows where a wrong answer costs money or trust
  4. Keep config in the product — Keys, model choice, and knowledge text should be owner-controlled
  5. Ship two surfaces when needed — Customers and staff have different questions; one bot rarely serves both well

This extends the platform work described in our Great Lakes Additive case study. If you are weighing AI for a storefront, portal, or internal tool, we can help you scope it — with the same bias toward systems you own and answers you can trust.

Great Lakes Additive is a Cusic Digital client. The approach above reflects work on their custom Next.js platform and API.