Where does the assistant get its answers?

From material you approve: service pages, price lists, policy documents, catalogues, and the support notes your team already uses. We split that material into passages, tag each passage with its source, and the assistant writes answers from the retrieved passages. It can show the source, so your support lead can check any claim later.

What happens when it does not know an answer?

It says so and offers to pass the question to a colleague. The refusal rule sits in the system prompt and in the retrieval step, and we test it with questions we know the knowledge base cannot answer. Every refusal is logged, which also shows where your own documentation has gaps.

How many languages can it handle?

It replies in the language the customer used, and coverage depends on the material you have for that language. We enable a language in production once speakers on your team have checked the terminology. A language with thin material falls back to a short set of approved answers and a handover.

When does a conversation go to a human?

Common triggers are questions outside the knowledge base, two failed attempts at the same question, an explicit request for a person, complaint or cancellation language, and anything that needs an authenticated account change. We set the routing with you during the pilot so your team knows where conversations land.

Bilingual AI Customer Support Bot

Bilingual AI support chat for websites and messaging channels, grounded in approved documents, with clear human handover when an answer is uncertain.

See our work:

smrtAI→SmartAIChats→Vasilkoff.info - AI Project Estimator & Chat Support Web App→

Most companies that sell in two or more languages end up with the same support problem. A visitor writes in Greek at 22:40, the office is closed, and the question waits until morning. Someone else sends a request the team already answered eleven times that week. A third person asks about delivery to Nicosia, receives a vague reply, and looks elsewhere. The website stays busy while the pipeline stays quiet.

A generic chatbot adds to that problem. When the assistant has no approved source to work from, it still produces a fluent answer about your prices, your guarantees, or who qualifies for a service, and the customer reads it as a promise from your company. We build support assistants that answer from documents you approved, say clearly when something sits outside that material, and pass the conversation to a person before a guess becomes expensive.

Where the answers come from

Everything the assistant may state comes from material you own: service pages, price lists, policy documents, product catalogues, booking rules, and internal notes your support team already keeps. We read that material, split it into passages, tag each passage with its source, and load it into a retrieval layer. When a question arrives, the system finds the passages that match, and the model writes its answer from those passages. The reply can show the source document, so your support lead can check any claim afterwards.

Our AI development practice covers the retrieval, prompting, and evaluation work behind this. The published AI assistant and workflow automation order describes the same shape of project: a chatbot trained on your business data and connected to your existing tools.

What the assistant should refuse to answer

Refusal behaviour is where most support bots fail, so we treat it as a deliverable in its own right, with written rules and a test set. The assistant carries a list of topics it must decline: legal or medical advice, financial recommendations, competitor comparisons, delivery dates it was never given, custom pricing outside your published list, anything about another customer's order, and internal staffing matters. It also declines when a question is ambiguous enough that two readings give different answers, and when the customer is angry enough that the next message needs a person.

When no approved passage supports a factual claim, the instruction is to say so plainly and offer the handover: "I do not have that on file. Would you like me to pass this to a colleague who can confirm it?" We test that path with questions we know the knowledge base cannot answer, and every refusal stays in the transcript log. That log turns into a useful list of the gaps in your own documentation, and it shows which gaps bring the most traffic.

Language handling

The assistant detects the language from the first message and replies in the same one. We enable a language in production once the material exists for it and speakers on your side have checked the terminology against how your customers actually write. Where coverage is thin, the assistant answers from a short set of approved responses and routes the rest to your team. Some content stays in one language on purpose, including legal notices and regulatory text, and the assistant tells the customer in their language that the original wording governs.

Handing uncertain conversations to people

Escalation rules are configured with you and reviewed after the pilot. The common triggers are a question outside the knowledge base, two failed attempts at the same question, an explicit request for a person, complaint or cancellation language, high commercial intent such as a multi-unit enquiry, and anything that requires an authenticated account change. Where a conversation goes depends on your setup: a shared inbox, WhatsApp, a ticketing system, or a Slack channel for urgent items. The customer receives a confirmation with an expected response time, so the handover does not feel like being dropped.

Reviewing conversations afterwards

Transcripts are stored with the customer's consent and a retention period you set. Your team gets a view of conversations by date, language, topic, and outcome, with a filter for unanswered questions and escalations. In the first weeks we review transcripts together, sample answers against the source documents, and adjust prompts, retrieval, and refusal wording. After that the review cadence drops to whatever your support lead can sustain, with a monthly summary of repeated gaps.

Who this is for

This work suits companies that sell in more than one language and answer a high volume of similar questions. Typical buyers are clinics, law firms, real estate agencies, hotels, and online stores trading across Cyprus, the United Kingdom, and the United Arab Emirates. If your team keeps a price list, a policy document, and a support inbox with a year of history, we have the raw material to build from. If the answers exist only in one person's head, the knowledge audit comes first.

What we deliver

The engagement produces a working assistant on your website and at least one messaging channel, the retrieval layer and evaluation set behind it, language handling for the languages we validate together, escalation rules with routing, a conversation review view, and written documentation of the refusal rules. Model calls run through a server-side endpoint, so keys and customer data stay off the browser, following the pattern we describe under secure AI backend and API key protection. When the assistant has to work alongside customer accounts, a membership and gated content system or a custom web application usually sits behind it.

How the engagement runs

We start with a knowledge audit: which documents exist, who owns them, and which questions they cover. That is usually one week. Build and test runs two to three weeks for a single channel and a small number of languages, and we test against real questions from your support inbox before launch. The pilot opens one channel with limited hours. After the pilot we review transcripts and tune the assistant before widening coverage. A multi-language rollout with CRM integration and several channels extends into further phases, and we scope those once the first channel is stable.

What it costs

Work is billed at our flat rate of $39 per hour, or as a fixed scope once we have seen your documents and channels. The published typical order for AI assistant and workflow automation work covers a custom chatbot trained on your data with CRM, email, and Slack connections at $1,800 to $3,900 across one to three weeks, which matches a focused single-channel build. Additional languages, extra channels, order lookups, and dashboard work add phases on top. Teams that need steady delivery over several months use a monthly capacity plan from $2,699, and the pricing page explains both models.

Proof

SmartAIChats is an AI chat platform we built for websites, covering lead capture and first-line support in one deployment. It shows that a conversational layer can carry support volume without a heavy implementation project.

Vasilkoff.info is our own estimator and support application, tuned to answer questions about our services and hand structured project details to a human. It runs on a live commercial site where the assistant has to be right about prices and scope.

smrtAI is a live chat product with multichannel delivery across email, Messenger, Instagram, WhatsApp, and Telegram. It shows how one conversation engine can serve customers on the channels they already use.

Related services

AI lead qualification automation for the version of this work that scores enquiries and routes them into your sales process
Secure AI backend and API key protection to keep model keys and customer conversations off the browser
Membership and gated content system for assistants that answer account holders about their own subscriptions
Mobile app privacy compliance for the data handling rules that apply when the same assistant reaches customers through an app
Custom web application development and AI development for the parent engineering work behind the assistant

Next step

Send us your price list, your policy documents, and twenty real questions from your support inbox. We will say which of them the assistant can answer, which it should refuse, and what the first phase would cost.

Contact us to book that review, or run your requirements through the Vasilkoff.info estimator for a first scope and budget range.