Add live chat to a website: installation and launch checks

Set staff hours, an offline path and a data boundary before launch. Keep a copy of the prior setup so you can remove the new code cleanly. If you have not chosen a service, start with the live chat comparison.

Add live chat to a website: choose the service and reply process

First decide what users should ask. A delivery question, a quote inquiry and a private account problem may need distinct routes. Chat can help the first two, while the last may belong in a secure account system.

Write a clear promise for the page. “Ask our team about this service” tells the user more than “We're always here” if the team only works office hours. The words should match the response your business can sustain.

Name a queue owner inside the business. Decide who covers a break and who handles a question that needs more work. A user should not have to repeat the same details because nobody knows who owns the conversation.

Compare the service's current plans against that process. Check human access, message units and the offline route. If you add automation, inspect its own knowledge source and limits. Do not treat a trial of an AI feature as part of ongoing free human chat.

Identify the website platform

Use the route for the real website, not just the brand name in a tutorial. Hosted and self-hosted WordPress have distinct constraints. A custom storefront can differ from a standard Shopify theme. Ask the platform's current help where the required code is permitted.

For platform-specific paths, see WordPress chat plugins, Shopify installation and Squarespace chat setup. They address the page and account controls that a general snippet cannot settle.

Keep a safe starting point

Before editing, record where the existing contact route and scripts are configured. Save a copy of the template or settings you will change. Use the platform's supported backup or version route. Keep the old contact entrance available during setup.

Identify any chat service already installed. Look at apps, plugins, theme code and site-wide code areas. A visible widget may come from one of several places. Do not add another copy to solve a problem whose source you have not found.

Use a preview or limited page when possible. If the widget must be site-wide, plan the change for a period when you can inspect the live result. Avoid making the edit and leaving before you know what users see.

Write down the rollback step before the change. That might be turning off an app embed, disabling a plugin or restoring a known snippet. It should find the exact connection rather than suggest removing all scripts from a shared theme.

Get the provider's current installation code

Use the service's own account and help centre to get the code for your site. Check the property or site identifier. Copying another site's snippet can connect your users to someone else's account.

Tidio help and LiveChat help describe their supported routes. Follow the guide for the product you chose. A script from a blog comment is not a substitute for current vendor instructions.

Keep credentials out of page code. A public site identifier and a secret API key have distinct roles. If a setup asks you to paste a private key into the user's page, stop and inspect the official instructions before proceeding.

Do not alter the snippet just to make it look shorter. Changing loading order or removing part of the code can break the vendor's supported behavior. If your platform transforms scripts, use the documented plugin or connection instead of guessing.

Install once through the supported route

For an official app or plugin, verify the publisher and requested access before enabling it. The plugin's installation cost and the external service's plan are separate questions. Confirm the ongoing service plan you intend to use.

For a code route, place the current snippet where both the vendor and platform allow it. A page block and site-wide injection can affect distinct parts of the site. Choose the location that matches the feature's planned reach.

Save and publish through the normal platform controls. Record the location of the change. A future theme update should not leave the business unable to find the chat installation.

Check for a second installation after the change. Two launchers, duplicate messages or repeated network loads can suggest overlapping code. Remove the known duplicate through its own supported route rather than adding a third version.

Set the greeting and available hours

Use a greeting that names the business task. A short service prompt can help users ask the right question. Do not claim an agent is present just because a chat window can open.

Set working hours to match the people assigned to the queue. Include holidays and timezones where they matter. If a user arrives outside those hours, show an honest message and a route for a later reply.

Decide what information is needed before a conversation starts. A name may help, but a long intake form can defeat the job of chat. Ask for a reply address only when it serves the task and explain how it will be used.

Keep sensitive tasks out of the general chat. Do not ask for passwords, full card numbers or private account documents. Route those requests through the business's supported secure system.

Trace one message through the whole route

Use a fictional question that a real member of staff could answer from a public page. Start on the signed-out site, open chat and send the question. Note the account and queue where it arrives. The goal is to prove the route, not to fill the inbox with test traffic.

Have the planned staff role read and reply. Then read that reply on the user side. If the test works only for an administrator, check whether routine staff have the access they need. Do not share the administrator login to make the test pass.

Next leave the page and inspect the supported follow-up state. The user may need a reply address for a later message. The business should know what happens when that detail is missing. An open chat window is not a permanent contact route.

Now ask a question that needs another person. The first member of staff should know where to send it and what to tell the user. If the task becomes a later reply, say that plainly. Avoid leaving a silent live panel while the work moves elsewhere.

Repeat only the part that failed after a change. If the message reached staff but the page hid the reply, inspect the page. If no task arrived, inspect the account and receiving route. A precise observation is more useful than replacing the entire script.

Finish by deleting or marking the fictional test record through the service's supported controls where needed. Keep real user work distinct from setup checks. Record the working installation and its removal step so the next editor can maintain it.

Check the close action as part of setup

Do not stop the page check after the panel opens. Close it with the supported control and confirm that the user returns to the task they left. The main page should not jump to an unrelated place or leave focus in a hidden panel.

Then check a longer reply. The text field, reply and close control all need room on a phone. A short test message can hide a layout problem that a real question reveals. Keep this check tied to the pages where chat will actually appear.

Plan escalation and bot handoff

A person answering chat needs a path for work they cannot finish. Define who handles billing, technical issues or a complaint. The user should know if the question becomes a later follow-up rather than a live exchange.

If a bot handles the first reply, define its allowed source. Use current service facts and exclude material it should not use. A bot should not fill a gap by making a promise that the business has not approved.

Check a question that lies outside that source. A useful result is a clear limit followed by a human or contact route. A confident wrong answer is not a successful handoff.

Use the chatbot versus live chat guide to decide whether automation belongs in this setup. A human-only launch can be a sensible first stage if the team is still learning the common questions.

Match privacy and consent to what loads

Read the vendor's current privacy and data-processing terms. Identify what the widget receives, such as message content, page context or account details you connect. Keep the website's explanation exact to the real installation.

Review who can read stored conversations and who can export them. Use supported access roles. A single shared staff account can make it harder to remove one person's access or find who handled a request.

Check your site's consent system with the installed widget. Do not assume every third-party script belongs in the same category. The correct treatment depends on real behavior and the rules that apply to your site.

If a user declines an optional service, preserve key contact details. A blocked widget should not prevent the user from reading delivery terms or finding a normal email or contact page. Make the page useful without the external feature.

Check live chat on the website as a visitor

Open a private or signed-out browser window. Verify the correct business account and greeting. An administrator's preview can hide a permission or publication issue that affects everyone else.

Start a fictional test conversation using the vendor's supported process. Confirm it appears in the staff inbox you expect. Reply and check the user can read it. Then close the panel and ensure the page remains usable.

Inspect the result on a phone. The launcher must not cover a purchase control or consent choice. Long messages and error text should remain readable. If the panel fills the screen, its close control still needs to be easy to find.

Use the keyboard from the page into the chat and back. Watch focus as the panel opens and closes. A user should not be trapped in a hidden control or returned to the top of the page without a reason.

Check offline and failure states

Turn to the configured offline state in a safe test context. Confirm that it does not promise an immediate response. If the user leaves a message, check where staff see it and how they will respond later.

Check a disconnected or blocked widget without disrupting a working user account. In a safe preview, block the external request or use the vendor's supported failure check. The page should retain a contact alternative and its main content.

If the widget does not appear, find the likely layer. Confirm that the platform saved the code and published the page. Check that the current plan permits the script. Then inspect consent rules and blocking browser extensions.

Change one known cause at a time. Repeatedly replacing the snippet can leave duplicates and make the original fault harder to find. Keep the observed error and the exact installation route in the support request.

Keep a small launch record

Record the vendor, account owner, installation location and chosen plan. Add the staff hours and offline route. Note which source controls bot answers if automation is enabled.

Keep a short check list for later changes. A theme replacement, app update or new consent tool can affect chat. Recheck the listed user path after those changes rather than relying on the launch day's result.

Review usage against the correct unit. A new quota warning may reflect human conversations, automation or another product. Read the vendor's definition before changing the public promise or buying a larger allowance.

Do not infer business results from a visible launcher or a successful test message. New conversations, useful answers and completed purchases are separate outcomes. Measure only what you can actually observe.

Remove or replace chat safely

Disable the known app embed, plugin or snippet. Open the live site again and check that the launcher is gone. If it remains, inspect the recorded installation locations for an overlapping route.

Handle the vendor account separately. Removing a website script does not necessarily delete stored conversations, cancel a plan or remove staff access. Use the service's supported controls for those actions and preserve needed records first.

When moving to another vendor, keep the old contact route until the new one works. Reconcile any open follow-up tasks. Do not leave users waiting in an inbox the team has stopped monitoring.

Keep a useful support note

If setup fails, send the vendor the page URL and the exact installation route. Include the visible error and the browser used. Remove private messages and secret keys from the note. A precise report lets support inspect the broken step without asking you to replace a working part of the site.

Separate duplicate installation from duplicate sessions

Two launchers usually call for an installation inventory: an app, a theme snippet and a tag manager may each add code. Record those locations before removing one. Two conversations inside a single inbox may instead reflect separate visitor sessions; deleting website code will not merge those records.

Continue with the right task

• website widgets