Short answer: use Script Manager. In your BigCommerce control panel, open the storefront settings and find Script Manager, create a new script, paste the widget's script tag, set location to footer and pages to all, and save. It applies store-wide without you touching a single theme file.
Why is Script Manager the right tool here?
BigCommerce built Script Manager precisely so store owners could add third-party tags without editing Stencil theme files. That distinction matters more than it sounds.
Theme edits are fragile. Update your theme, or switch to a new one during a redesign, and anything you hand-added disappears. Script Manager entries live at the store level, so they survive theme changes entirely. When you eventually redesign your storefront, your chat widget just keeps working.
It also gives you controls you would otherwise have to code yourself: which pages the script appears on, and whether it loads in the head or the footer.
What do you need before you start?
Five minutes of preparation saves the classic hour of confusion:
- Control panel access with permission to edit scripts. Store owner or an admin role that includes Script Manager. Limited staff accounts often cannot see it at all, which is the real explanation behind most "the menu is not there" messages.
- Your widget's script tag, copied in full, including the opening and closing brackets. Copy it from the source, not from a screenshot or a formatted document, because smart quotes will silently break it.
- Your live storefront URL, not the preview link.
- A note of which storefront you are working on if you run more than one channel. Script Manager entries belong to a storefront, so a script added to one is not automatically on another.
The install, step by step
In your BigCommerce control panel, go to the storefront area and open Script Manager. Create a new script.
Give it a name you will recognise later. "Clerkzo chat widget" is better than "script 3", because in a year you will be looking at this list wondering what everything does. Use the description field too.
Set the location to footer. Chat widgets belong at the end of the body so they never delay your product images and copy from rendering.
Set the pages to all pages, unless you have a specific reason not to. Store-wide is the default you want, because a visitor on a category page is as likely to have a question as one on a product page.
If your store shows a category or consent field alongside the script settings, pick the one matching how you treat chat under your cookie policy. Your consent banner reads that field when deciding whether to load the script, which is why a widget can appear for you and not for a visitor who declined some categories.
Choose the script type that lets you paste a script tag directly, then paste the whole tag including its opening and closing brackets. Save.
Head or footer, and does it matter?
Footer, in almost every case.
A script in the head is fetched and evaluated before the browser gets to your product photos and copy. Even an asynchronous script in the head competes for the same early moments. In the footer, the page paints first and the chat bubble appears a moment later, which is exactly the order your customers care about.
The only reason to use the head is a tool that must observe the page from the very first paint, such as some analytics and consent tools. A chat widget is not one of those.
A note on the checkout page
BigCommerce treats checkout as its own protected surface. Depending on your plan and permissions, scripts targeted at checkout are restricted, and for good reason: nobody wants third-party code running where card details are entered.
This is fine. You almost certainly do not want a chat widget on checkout anyway. Once someone is entering payment details, the job is to remove distractions, not add a floating bubble. Leave checkout alone and let the widget do its work on the pages where people are still deciding.
The theme-file alternative, and when it makes sense
You can edit your Stencil theme instead, dropping the script into the base template before the closing body tag. Two situations justify it: you need very specific placement logic that Script Manager cannot express, or you are already maintaining a custom theme in a proper development workflow.
For everyone else, it is strictly worse. It requires theme file access, it breaks on theme updates, and it makes the widget invisible to whoever inherits the store after you. Use Script Manager. If you do go the theme route, edit a copy rather than the live theme and note the file you changed.
Verifying it went live
Open your storefront on the live domain, not the preview link, in a private browser window. The bubble should appear in the corner shortly after the page loads.
Then check a product page, a category page and your homepage. Script Manager's page targeting means it is genuinely possible for the script to be on one and not another, especially if you narrowed the scope while experimenting.
If the bubble is missing, view page source and search for your script tag. In the source but not rendering means an error, so open the browser console. Not in the source means the Script Manager entry is not applying to that page type, or it saved as inactive.
Finish the check on a phone. Load the live storefront on your own mobile data rather than the shop wifi, tap the bubble, send one real question, and confirm the answer arrives and the keyboard does not cover the input box. A widget that works on a 27-inch monitor and not on a phone is a widget that does not work.
Common gotchas
Preview versus live storefront. BigCommerce theme previews do not always execute store-level scripts. Judge from the real storefront.
Store-level caching and CDN. Your storefront is served through a CDN. A change can take a short while to propagate. Wait a couple of minutes and use a private window before concluding it failed.
AMP pages. If you serve AMP versions of any pages, custom JavaScript will not run there. AMP forbids arbitrary scripts by design. Your chat widget will be absent from AMP pages and there is no workaround, only the choice to stop serving AMP for those pages.
Duplicate scripts. If you previously tried an app that injected the same widget, you can end up with two bubbles. Check Script Manager and your installed apps before adding another entry.
Content security policy. If you have added a restrictive CSP to your storefront, you must allow the widget's domain or the browser blocks it silently. The console will tell you.
Multiple storefronts. If you run more than one channel, confirm the script is attached to the storefront you are actually looking at. Testing storefront B while the script sits on storefront A is a surprisingly common half hour.
A cookie banner that blocks it. If your consent tool holds back non-essential scripts until a visitor accepts, the widget will be absent for anyone who has not. That may be exactly what you want, but you should know it is happening rather than discover it from a customer.
How do you remove or pause it?
Removing is as reversible as installing, which is worth knowing before you commit.
Open Script Manager, find the entry by the name you gave it, and either set it to inactive or delete it. Inactive is the better first move: it takes the widget off the storefront immediately while keeping the tag if you want it back. Then purge or wait out the CDN cache, and confirm from a private window on the live domain that the bubble has gone.
If you also added the script to a theme file at some point, Script Manager will not remove that copy. Search your base template for the tag too, otherwise you delete the entry, see the bubble persist, and conclude something is haunted.
Do the removal before you cancel the subscription, not after, so the tag is never on the page with nothing behind it.
Making it useful for an actual store
An ecommerce store has a different job to a service business. Most of your chat volume will be shipping times, returns policy, sizing, stock and order status. Those are exactly the questions that eat your inbox.
Train the widget by pointing it at your store so it crawls product and policy pages (how it works covers the sequence), then upload a knowledge file for anything not published, like your internal returns rules or a size guide that only exists as a PDF. Set guardrails so it stays on topic and hands off to a human rather than improvising on refunds. And when a pre-sales question turns into a real opportunity, capture the details rather than letting the conversation end in the browser.
Here is what that looks like in practice on a product page at eleven at night:
Visitor: Is this the same fabric as the older version? I bought one in 2023. Widget: The current version uses the same 320gsm brushed cotton, though the cut was updated last year and runs slightly slimmer. The size guide has the exact measurements. If you would like, I can pass your question to the team so they can confirm against your previous order. Visitor: Yes please. Widget: Of course. What is your name and the email you ordered under?
You wake up to a named customer, a specific question, and the email you need to look up the order. That is a very different artefact from an abandoned session.
That last part is the money bit, and it is covered in how to capture more leads from your website and on the lead capture chatbot page.
Frequently asked questions
Does this need an app from the BigCommerce marketplace?
No. A script tag through Script Manager is enough. That also means nothing extra to update or uninstall later.
Will it slow down my store?
Loaded in the footer and asynchronously, it does not block your page rendering. Your product pages paint first.
Can I show it only on product pages?
Yes. Script Manager's page targeting supports narrowing scope, though store-wide is usually the better choice.
Can it answer questions about specific products?
It answers from what it has learned by crawling your site, so published product information is fair game. Live stock levels and order status are a different problem and generally belong with a human handoff.
What does it cost per conversation?
Nothing. Clerkzo is flat monthly pricing, which matters for a store where traffic spikes are normal.
I added it and nothing happened. What is the first thing to check?
Private window, live domain, then view source. Those three steps identify whether the problem is caching, targeting or the script itself, and they take under a minute.
How do I keep the answers current when products change?
Re-crawl after significant updates to your policy or product pages, and use the corrections loop for anything it phrases badly. Publishing the answer on your site helps twice, since human shoppers read the same page.