Customer assistants grounded in your own data

A customer assistant grounded in your own data is a chat assistant that answers only from material you control, such as your product catalog, your documents and your policies, and that hands the conversation to a person when it cannot. It is for companies that answer the same customer questions every day by email, phone and WhatsApp and want those answers to be fast, consistent and correct.

Key takeaways

• An assistant is only as good as the data behind it. Start with the sources, not the chat window.
• Grounding means the assistant retrieves passages from your material and answers from them, with the source visible to you.
• "I do not have that information, let me connect you with a colleague" is a correct answer. Guessing is not.
• Hand-off to a person is a feature, not a fallback. Design it from day one.
• Place the assistant where customers already are: your website, WhatsApp, or both.
• Measure usefulness by reading conversations and tracking resolved versus handed-off, not by counting messages.

What grounded means in practice

A general-purpose chat model answers from what it learned in training. It does not know your prices, your delivery times or your return policy, and when asked, it will produce a plausible-sounding answer anyway. For a business, that is a liability.

A grounded assistant works differently. Before answering, it searches a prepared index of your own content, selects the passages that match the question, and writes an answer based on those passages only. If nothing relevant is found, it says so. The model's role is to read and phrase; your content is the authority.

This changes what the project is about. Most of the work is in collecting, cleaning and structuring the sources. The chat layer is the smaller part.

Step 1: Decide what the assistant may talk about

List the questions customers actually ask. The support inbox, the WhatsApp history and the sales team's memory are the best sources. Group them: product facts, availability and price, delivery and returns, how-to and troubleshooting, account and order status.

Then decide, per group, one of three things: the assistant answers directly; the assistant answers and offers to connect a person; the assistant does not answer and hands over immediately. Complaints, price negotiations and anything involving a legal commitment belong in the last group.

Step 2: Prepare the sources

Each group needs a source the assistant can read:

• Product catalog: a structured export (name, variants, specifications, price, stock status) from your shop or ERP, refreshed on a schedule rather than copied once.
• Documents: manuals, datasheets, terms, FAQs. PDFs are fine; scanned images need text extraction first.
• Policies: delivery, returns, warranty, payment. Written in plain language, dated, and owned by someone who updates them.

Remove outdated versions. Two conflicting documents about the same thing are worse than none, because the assistant will pick one without knowing which is current.

Step 3: Set the rules for refusing

Write down, in plain sentences, what the assistant does when it is unsure: it says it does not have that information, offers to connect a person, and collects the details a colleague will need. These sentences become part of the assistant's instructions, and they are tested like any other requirement.

A second rule: the assistant never states facts that are not in its sources. Test this deliberately by asking about products you do not sell and policies you do not have. The expected answer is a clean refusal.

Step 4: Design the hand-off

A hand-off is where the assistant stops and a person continues. It should carry context: the conversation so far, the customer's contact details, and the assistant's note on what the customer wanted. It should land where your team already works: a shared inbox, a CRM task, a WhatsApp thread or a ticket.

Define when the hand-off happens: on request ("I want to talk to someone"), on topic (complaints, orders above an agreed value, anything legal), on repeated failure (the assistant could not answer twice), and outside working hours (it tells the customer when a reply will come and logs the request).

Step 5: Choose the placement

On your website, the assistant sits on product pages and the contact page. It helps a visitor compare, find a specification, or check delivery before they fill out a form.

On WhatsApp, the assistant answers in the channel many customers in Europe already use. Through the WhatsApp Business Platform, a business can reply freely within 24 hours of the customer's last message; outside that window, outbound messages must use pre-approved message templates (https://developers.facebook.com/docs/whatsapp/cloud-api). Plan the hand-off and any follow-up around this rule.

Both channels can share one assistant and one set of sources. The difference is tone and length: WhatsApp answers should be short.

Step 6: Tell people they are talking to a system

Under the EU AI Act, Regulation (EU) 2024/1689, Article 50 requires that people interacting with an AI system are informed of this unless it is obvious from the context (https://eur-lex.europa.eu/eli/reg/2024/1689/oj). These transparency obligations apply from 2 August 2026. A clear sentence at the start of the conversation is the usual way to meet this and also sets expectations; ask a lawyer where in doubt.

Conversations contain personal data, so the processing has to be covered in your privacy notice and in your agreements with any provider involved, under the GDPR, Regulation (EU) 2016/679 (https://eur-lex.europa.eu/eli/reg/2016/679/oj).

Step 7: Measure usefulness without invented numbers

Message counts say nothing. What matters:

• Resolved versus handed off: how many conversations ended with the question answered from the sources, and how many went to a person.
• Refusals: how often the assistant said it did not know, and whether a source should have existed.
• Hand-off quality: did the colleague receive enough context to continue without asking the customer again?
• Corrections: cases where the answer was wrong even though it was grounded, usually a sign of an outdated source.

Read a sample of conversations every week, especially in the first months. This is the single most useful practice. The figures will come from your own logs, not from a vendor's slide.

How we do it at Hot Skulls Labs

We start with the sources, not the interface. In discovery we go through the support inbox and the WhatsApp history with the people who answer customers, group the questions, and agree which groups the assistant answers and which it hands over. We then build the index from the catalog export, the documents and the written policies, and connect it to a refresh schedule so it does not drift.

The assistant itself follows the pattern we use across our automation work: a trigger (a customer message), an AI step (retrieve from the sources and draft an answer), a review step where it is needed (hand-off to a person for the groups that require it), and execution (the reply goes out, the hand-off lands in the team's tools). In the pilot phase, the team reviews drafts before they are sent. Once the refusals and hand-offs behave as agreed, direct answers are enabled for the low-risk groups.

On lavinlight.eu, the assistant visitors talk to is Strady's embeddable voice assistant, our own product, running on a brand site we built ourselves. It is scoped to answer from the product range and specifications and to hand everything else to a person. That work shaped how we structure catalog sources and refusal rules today.

We host in the EU, keep the sources and the conversation logs under the client's own accounts wherever the tools allow it, and review the conversation sample together with the client in the first weeks of operation.