Adding live chat to a website takes one script tag and a few minutes. The slow part is everything around it: who answers, what happens after hours, whether a bot speaks first, and where the chat goes when the tab closes. This guide covers the install every vendor shares, the decisions to settle first, and how chats land in the inbox that already holds the client's email.
Paste the vendor's script tag before the closing body tag on every page, add your domain to the allowed list, and send a test message. Before that, decide who answers, what the widget says outside hours, and whether a bot or a person replies first. Then route every chat into the inbox that holds email, so one person owns the customer on both. See live chat in Sektra.
What a live chat widget is
A live chat widget is a small script that loads on your pages and draws a button, usually in a bottom corner. A visitor clicks it, a panel opens, and they type. The message reaches an agent in real time, and the reply shows in the same panel while the visitor is still on the page.
That is what separates chat on a website from a contact form. A form sends one message, and the answer arrives by email later, if it arrives. Chat starts on the page and can continue after the visitor leaves.
How the one-script install works on every vendor
Intercom, Help Scout, Front, Crisp and Tidio all install the same way. You create a chat channel or inbox in the vendor's dashboard. It gives you a script tag that carries a widget id, and you paste it before the closing body tag of every page template. An allowed-domains list names the sites that may load that id, so a copied script on someone else's page posts nowhere.
- Create the chat inbox or channel in the dashboard and copy the script. The widget id inside it is what ties the page to your inbox.
- Paste the script before the closing body tag in the layout every page shares: the root layout in Next.js, the theme footer in WordPress, theme.liquid in Shopify. A tag manager works too, as long as it fires on every page.
- Add every domain the widget should load on to the allowed list, including the staging site.
- Load a page, open the widget, send a test message and confirm it arrives in the inbox. Then reply from the inbox and watch it appear in the panel.
- Check the widget on a phone, where it often covers a footer link or a cookie banner.
Decide these things before you install
Pasting the script is the last step. The settings below decide whether the widget becomes a channel the team answers or a button that fills a queue nobody owns. Settle them in one short meeting.
| Decision | Options | What it changes |
|---|---|---|
| Who answers | One named person per shift, a round robin, or whoever is free | Whether a chat has an owner within a minute or sits unread |
| Hours | Business hours, a rotation, or always on | What a visitor is promised at 9 pm, and whether the promise is kept |
| When nobody is online | Take a message with an email address, show a help center search, or hide the widget | Whether after-hours visitors leave something the team can act on |
| Ask for an email | Required before the first message, asked at handoff to a person, or never | How many visitors start a chat, and how many you can follow up with |
| Files | Allowed with a size cap, or text only | Whether a visitor can send the screenshot or document the question is about |
| Bot first or person first | A bot answers from the help center and hands off, or a person answers everything | Reply time on routine questions, and how many chats reach the team |
| Where the chat lives | The vendor's own chat tool, or the inbox that holds email and WhatsApp | Whether one person can see everything a customer has said |
Who answers, and what happens after hours
Pick one person to own each chat for its whole life, the same rule as a shared email inbox. If two people watch the widget, decide who takes the next one, or let the inbox assign it. Then set hours with an expected reply time, so the widget can tell a visitor what to expect instead of showing a spinner.
Outside hours the widget should still take the message. Ask for an email address at that point, show the help center so the visitor can look the answer up themselves, and queue the chat for the morning. A widget that hides after hours loses the question entirely.
Email capture, files and the bot
Requiring an email before the first message filters out casual questions and gives you a way to reply later. Asking only when the chat is handed to a person keeps the first message easy and still captures the address when it matters. Turning it off suits a signed-in product where you already know who is typing.
Allow file attachments with a cap, because the screenshot is often the question. Start the bot on help center content only, read its first week of transcripts, and widen it from there. A person takes over the moment it cannot find an answer.
Route chats into the same inbox as email
A separate chat tool creates a second queue, a second history and a second place to look. The person who answered a client's email on Monday does not see the chat on Wednesday, and the client repeats themselves. The fix is to treat chat as one more inbox in the tool that already holds email, so the same person owns the customer on both.
That means the chat gets the same tools as an email thread: an owner, tags, internal notes, saved replies, and rules that assign or tag on arrival. It also means one contact record. Search a client's name and the email thread, the chat and the WhatsApp messages appear in one list.
What happens when the visitor leaves
Visitors close tabs. A chat that ends when the tab closes forces the team to start over by email, with no record of what was said. The better pattern keeps the conversation open in the inbox. When an agent replies after the visitor has gone, the reply goes to the email address or WhatsApp number they gave. Their answer lands back in the same conversation.
Ask the vendor two questions. Does the conversation keep one timeline across chat and the follow-up channel, with a line that marks the switch? And does the visitor's reply land in that conversation rather than in a new email thread for someone else to find?
Returning visitors and signed-in users
A visitor who comes back next week should find their earlier chats in the panel. In the same browser the widget can do that with a local identifier. For a product with accounts, the right pattern is a signed token. Your server signs the user's id with a secret shared with the chat vendor. The widget sends that signature with every request, and the vendor checks it before showing any history.
Without the signature, anyone who copies a user id could read that user's chats. With it, a visitor sees only their own, on any device they sign in from. A vendor that offers identity verification for its widget is describing this pattern.
How to tell whether live chat is working
Measure the same three things you measure on email. First response time, as a median and as the slowest tenth, since the median hides the chats that waited twenty minutes. Reply coverage, the share of chats that got an answer at all, including after hours. And the rating visitors leave at the end, read next to the transcript.
Add two chat-specific numbers. The share of chats the bot closed without handoff, checked against transcripts. And the page each chat started on, which shows which part of the site raises questions.
Where Sektra fits
We build Sektra, an AI shared inbox for client-facing teams, so read this section with that in mind. Sektra has a Chat inbox type. You create one, paste a single script tag with the inbox's widget id, and add the domains it may load on. Widget options cover brand color, logo, greeting, position, and business hours with an expected reply time.
Visitors can attach files up to 20 MB, use emoji, see typing dots, rate the chat at the end, and search the help center from a tab. Lead capture has three modes: email required, asked at handoff to a person, or off. Returning visitors see Your conversations in the same browser, or on any device when your site signs them in with a signed token.
When a visitor leaves, the conversation stays in the Chat inbox. The next reply an agent sends goes to the email or WhatsApp number they gave, and the timeline logs the switch. Their reply comes back into the same conversation. Agents get assignment, tags, notes, templates and rules on a chat, the same as on an email thread. The assistant drafts replies and summarizes long chats, and a person sends.
The assistant can also answer first, from your help center and knowledge library, under the name LensGPT in the widget. It hands the chat to a person when it cannot help. Every contact keeps one history across chat, email and WhatsApp. Setup is on the chat integration page, and the full feature list is on /product.
Paste the script last. Settle who answers, what the widget does after hours, and where the conversation lives. Then install, test on a phone, and read the first week of transcripts before you widen the bot.
