How a Website Chat Widget Is Built: The Moving Parts, Explained for Non-Engineers

From the outside, an AI chat widget looks simple: a small bubble appears in the corner, you type a question and an answer streams back. Behind that bubble sits a chain of separate parts, each with a job, each able to fail or slow down, and each affecting speed, accuracy, cost and security. You do not need to be an engineer to benefit from understanding them. Knowing the parts helps you ask better questions when comparing products, diagnose problems ('the answers are slow' or 'it ignored my document'), decide where your data goes and judge claims made in marketing pages. This guide walks through the journey of one visitor's question from the click on your website to the answer on the screen, describing each component in plain language: the embed script, the widget, the chat server, retrieval from your documents, the AI provider, streaming, storage and the dashboard. It describes how Crescelo is put together where that is useful, and it flags where things commonly go wrong.

The journey in one picture

1 and 2: the embed script and the widget

You paste one line of code into your website. It loads a script from the platform, which fetches the assistant's settings, such as name, colours, welcome message and starter questions, and draws the chat bubble. Two design choices matter here. First, the widget should not damage your site: Crescelo's widget draws itself inside a Shadow DOM, which keeps its styles separate from your page's, so your site's CSS cannot break the widget and the widget cannot restyle your site; see why chat widgets use Shadow DOM. Second, it should be light, so it does not slow your page; see performance of embedded chat widgets.

3 and 4: the request and the checks

When the visitor sends a message, the widget sends it over the internet to the platform's chat server. Before doing any work, a careful server checks the request:

• Is it for a real assistant that is switched on?
• Is the sender within rate limits, so one visitor or script cannot flood the service?
• Is the plan's monthly session allowance still available?
• Does the request look like abuse, such as a huge message or a bot?
• Which workspace owns this assistant, so data is kept apart from other customers?

These checks protect both you and the platform. They are also where much of the security work lives; see keeping one customer's data away from another.

5: retrieval, finding the right passages

This is where a grounded assistant differs from a general chatbot. Rather than answering from memory, the server searches your documents first. Your content was split into passages and indexed earlier, both by meaning (vector search) and by keywords. The question is used to find the most relevant passages, which are merged and reranked. See reciprocal rank fusion. Recent messages are considered too, so a follow-up such as 'and on Saturdays?' is understood; see multi-turn query condensation.

6: generation, the AI model writes the reply

The server sends the question, the recent conversation, the retrieved passages and your instructions to a language model at an AI provider such as OpenAI, Anthropic, Google, Groq or DeepSeek. With bring-your-own-key, the request uses your account and your key, which the platform stores encrypted; see bring your own AI key explained. The model writes the reply from the passages, following your rules about tone and topics. This step is the slowest and the main source of cost. It also has limits: a provider may be busy or rate limited, so a good platform can fall back to another model, and it should detect a reply that stops mid-sentence and ask the model to continue.

7: streaming the answer back

Instead of waiting for the whole reply, the server sends it to the browser as it is generated, so words appear almost immediately. This uses a one-way connection called Server-Sent Events; see streaming replies: SSE versus WebSockets. It makes a multi-second answer feel quick.

8: storage and actions

• Conversation: each message is saved so you can read the transcript and the visitor can continue where they left off.
• Leads: if the visitor gives contact details, the lead is saved and sent to your email, Slack, Google Sheets or a webhook.
• Bokningar: if they book, the slot is locked, saved and confirmed by email.
• Unanswered questions: questions the assistant could not answer are logged so you can fill the gaps.
• Usage: sessions and AI usage are counted for your plan.

The parts you manage

Where things go wrong

Questions to ask any vendor

• Where does my data live, and how is it separated from other customers?
• Which AI providers can I use, and can I bring my own key?
• How do you make sure answers come from my content?
• What happens when the AI provider is down?
• How are keys and secrets protected?
• Can I export my data and leave?

Frequently asked questions

See the website widget feature, try the whole chain in the playground and read pricing.

Further reading

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al.): The original research paper behind retrieval-augmented generation.
• Google Search Central: creating helpful, people-first content: What Google looks for in useful pages.