Setting Up Web Chat: Domain List, Persona and the First Test
    Omnichannel

    Setting Up Web Chat: Domain List, Persona and the First Test

    Installing web chat is a ten-minute job, but three misconfigured settings mean the widget either never opens or never uses your agent at all. The three critical points.

    Web chat is a channel that uses the same knowledge base as your voice agent but runs at a different rhythm. A customer who must wait on the phone can leave a chat tab open and get on with something else. That difference shapes the setup too.

    Setting one: which domains it opens on

    For the widget to run, your site's domain must be on an allowed list. This is a security control preventing malicious sites from running your chat on their pages.

    The most common outcome here: the list is left empty and the widget opens nowhere. The code is on the site, no error appears, the button is clicked and nothing happens.

    Checklist:

    • The root domain (site.com) and the www variant must both be listed.
    • Add your staging environment if you have one.
    • Remember to update the list when a domain changes.

    Setting two: which model the chat uses

    A chat widget can take answers from two places: the agent you configured, or another service connected from outside. If the second is defined, the chat never uses your agent, never sees your knowledge base and does not carry your persona.

    The symptom is clear: if the voice agent answers correctly while web chat gives generic answers, the chat is probably wired somewhere else.

    Setting three: persona and first message

    The web chat persona should differ from the phone persona. The reason is simple: in writing, longer sentences are tolerated; in speech they are not. Answers that must be kept short on a call can be delivered as bullet points in chat.

    The greeting differs too. On the phone the agent starts the conversation; in chat, a message appears when the widget opens, and that message usually has one job: showing the visitor what they can ask.

    Instead of "Hello, how can I help you?", an opening that suggests the three things most often asked on your site measurably raises the rate at which chats start.

    Which pages it should appear on

    You do not have to show the widget everywhere. Both approaches are defensible:

    • Every page. Visitors can ask wherever they are.
    • Intent pages only. Pricing, product detail and contact pages. Off on blog and careers pages.

    The second raises the quality of incoming chats and lowers your team's load.

    What to check in the first test

    Three tests are enough after installation:

    1. Open it in a private window. Your own session does not show what a real visitor sees.
    2. Open it on a phone. If the widget covers most of a mobile screen it may be hiding your buy button.
    3. Ask a question from your knowledge base. If the answer is right, the chat is wired to your agent; if it is generic, go back to setting two.

    Moving from chat to phone

    For topics chat cannot resolve, asking "shall we call you?" performs better than moving the matter to email. When the visitor leaves a number, a record opens and enters the call queue — the same flow as yesterday's form article.

    Tomorrow we look at social channels: turning Instagram and Messenger messages into sales.

    — End of entry