Short answer: the cleanest no-deploy method is a custom block containing your script tag, placed in a footer region and configured to show on all pages. The catch specific to Drupal is text formats: most of them strip script tags on save, so you must use a format that permits raw HTML. Then rebuild the cache.
Drupal has three legitimate routes, and they suit different people
Unlike hosted builders, Drupal does not have one obvious "paste your code here" box. It has several, which is on brand.
A custom block in a footer region is admin-only, needs no deploy, and can be removed by anyone with the right permission. Best for site owners without a development workflow.
A theme template edit puts the script in your theme's HTML template. It is version-controlled and deploys with your codebase. Best for teams already shipping Drupal through git.
An asset injector style module gives you an admin UI for adding JavaScript and CSS snippets, with conditions for which pages they load on. Best if you are managing several third-party tags and want them all in one place.
Route one: the footer block
Create a new custom block of the basic HTML type. In the body field, paste your script tag.
Now the important part. Below the body field is a text format selector. Most Drupal text formats filter HTML for safety and will silently remove your script tag when you save. You need a format that allows full, unfiltered HTML. On a standard install that is typically the format restricted to trusted roles, and if it is not available to you, an administrator has to grant it or create one.
This filtering is a feature, not an obstacle. It is what stops a content editor from pasting arbitrary JavaScript into a page. Treat the ability to bypass it as a privileged permission and keep it that way.
Save the block, then place it in a footer region through the block layout screen. In the visibility settings, leave the page conditions empty so it shows everywhere, or use them to restrict it.
One cosmetic detail: a block containing only a script tag can still render an empty wrapper with a title. Suppress the block title so you do not get a stray heading in your footer.
Route two: the theme template
Copy your theme's HTML template into your custom theme if you have not already, and add the script tag before the closing body tag. Commit it, deploy it, rebuild caches.
This is the right answer for an agency or an in-house team with a proper pipeline, because the change is reviewable and reproducible across environments. It is the wrong answer if changing your site requires a developer and a release window, since a script tag should not need either.
Never edit a contributed or core theme directly. Use a subtheme.
Route three: an asset injector module
Contributed modules exist specifically to add JavaScript and CSS through the admin interface, with per-page conditions and the ability to enable or disable a snippet without touching code.
The tradeoff is a new module to keep compatible across Drupal minor and major upgrades, for a job a block can already do. Worth it if you have several snippets to manage, overkill for one.
Rebuild the cache
Drupal caches rendered output. After adding your block or template change, clear all caches from the performance settings screen or with a drush cache rebuild if you have command line access.
If your site sits behind a reverse proxy or CDN, purge that layer too. And check whether you have a page cache for anonymous users active, because that is the one that will keep serving logged-out visitors the old markup while you, as an admin, see the new one and conclude everything is fine.
That specific mismatch causes enormous confusion. Always verify as an anonymous visitor.
How to verify
Log out, or open a private browser window, and load your live site. The bubble should appear shortly after the page loads.
Check an article page, a landing page and the front page. Drupal regions render per theme, and if you have different themes for different sections, a block placed in one theme's footer region will not appear in the other.
View the page source and search for the script tag. Missing means the text format stripped it, the block is not placed in an active region, or cache. Present but not rendering means a JavaScript error, so check the console.
Common gotchas
The text format stripped your code. The single most Drupal-specific failure. Re-open the block and check whether the script tag is still there. If it vanished, that is your answer.
Admin theme versus front-end theme. Blocks are placed per theme. Placing it in the admin theme does nothing for visitors.
Anonymous page cache. Verify logged out. Always.
Multiple themes or subsites. In a multisite or multi-theme setup, repeat the placement per theme.
Content security policy modules. If you run a CSP module, add the widget's domain to the allowed script sources or the browser blocks it.
AMP. If you use an AMP module, custom JavaScript does not run on AMP pages. That is an AMP restriction and there is no way around it.
Getting value out of it
Drupal sites are often information-dense: universities, councils, healthcare, membership organisations, complex service businesses. The common thread is that the answer is on the site somewhere and the visitor cannot find it.
Crawling your site is the fastest way to get the widget useful, then upload documents for anything not published as a web page. Set guardrails so it stays on topic and escalates rather than improvising, which matters more on a site where a wrong answer has consequences. And use the corrections loop: when it answers something badly, flag it, type the correct answer, and it holds permanently.
If the site's job is generating enquiries, wire up lead capture with the fields your team actually needs, and route new leads to email, a webhook into your existing system, or Telegram. The lead capture chatbot page covers that setup, and flat pricing from $19 a month means an enquiry-heavy month costs the same as a quiet one.
Frequently asked questions
Do I need a contributed module?
No. A custom block with an unfiltered text format is enough on a standard Drupal install.
Which Drupal versions does this apply to?
The block-in-a-region pattern has been stable across modern Drupal. Menu labels shift between versions, so if the wording differs, look for block layout and text formats in the administration area.
Will it conflict with my theme's CSS?
No. Clerkzo renders inside a Shadow DOM, so its styles are isolated from your theme and your theme's styles cannot affect it.
Can I restrict it to certain pages?
Yes, through the block visibility conditions, which support paths, content types and roles.
How long does this take?
Ten minutes if you already have the right permissions. Longer if you have to get a text format created first. See how it works.