Zendesk Guide and SaaS company
A help centre on one domain and the commercial material on another
A subscription business ends up with its support content in a hosted help centre and its commercial content on the site it built itself, and those are two origins with two bodies of material maintained by two different teams. Installing the widget in the help centre theme covers the first one. It does nothing at all about the second, which is where every question about plans, limits, billing and data residency is answered.
Why this pairing is its own job
The Zendesk Guide install guide covers the tag, and the SaaS company guide covers what the assistant has to know. What follows is the part that belongs to neither.
- The theme edit puts the widget on help centre pages only. Your pricing page, your security page and your subprocessor list are on a site the help centre theme has never touched.
- Questions do not respect that split. Somebody reading an article about a feature asks what it costs on the business plan, and the answer is on the other domain.
- The buyer questions attached to the largest contracts, about where data is processed and who touches it, are almost never in the help centre. They are on a trust page nobody links to from support content.
- There is already a ticket form on the same page, which is unusual. Most installs are the only route to a person on that site. Here the assistant is competing with a working escalation path and should lose to it quickly rather than keep trying.
What changes about the install here
<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>The tag is the same one on the Zendesk Guide guide. Everything below is about where it goes on a SaaS company site specifically.
Two origins, and a decision about whether they share an assistant
The help centre answers on its hosted address and, if you mapped a host, on your own support subdomain. Your marketing site answers on the apex and the www form. Every one of those the browser might see needs to be on the allowlist, and the console names whichever one was refused.
One assistant reading both bodies of material is normally the right shape, because the questions cross the boundary constantly and a customer does not know which of your two websites they are standing on. Two assistants means two keys, two corpora and a conversation that changes what it knows when the visitor clicks a link.
The marketing site is a second install, on a different platform
Publishing the help centre theme does nothing for the site your pricing lives on. That site is built somewhere else entirely and the tag has to go in wherever that platform puts custom code.
This is the step that gets forgotten, because the help centre install feels like the whole job and the launcher visibly appears. Open your pricing page after publishing the theme and check the corner. If it is empty, half your traffic never meets the assistant.
Where the answerable material lives
| Public help centre articles, and only the public ones | The crawl reads what a signed out visitor reads. On a subscription product it is common for the interesting operational articles to be restricted to customers, which means the corpus is quietly the marketing subset of your help centre unless you upload the rest. |
|---|---|
| The pricing page and the rules underneath it, on the other domain | The grid is on the marketing site and the rules that decide what a seat is and what happens at a limit are usually nowhere at all. Whatever exists has to be crawled from that origin, not this one, and whatever does not exist has to be written before it can be answered from. |
| Trust material, which is on the marketing domain and unlinked from support | Security page, subprocessor list, data location statement, and how a report is requested. These arrive through the help centre widget from buyers who never open your product, and they are on a domain your help centre crawl never reaches unless you point it there. |
| The billing policy that exists as an internal document | Refund windows, retry behaviour on a failed card, purchase order handling. On most subscription businesses this is written down somewhere that is not a web page on either domain, which makes it the one thing here worth uploading rather than crawling. |
The first thing to get right
Crawl the marketing site as well as the help centre, then stand on a help centre article and ask a plan boundary question.
That single test tells you whether the corpus matches where the questions are typed. It is the most common miss on this pairing and it is invisible from the install side, because everything about the help centre install looks correct while the assistant declines the most valuable question on the site.
The failure that belongs to this combination
An assistant that is confidently unaware of half your own website
Indexed to the help centre alone, it answers how-to questions well and refuses everything commercial. The owner reads a page of refusals about pricing and concludes the assistant is weak, when in fact it is behaving exactly as configured and the configuration named one of two domains.
The mirrored version of this is worse. Some help centres carry an old pricing article written when the tiers were different, so the corpus does contain an answer, it is simply the answer from two repricings ago, complete with a citation to an article that is still published and still wrong.
Both are the same problem seen from opposite sides: two sources of truth on two domains, and only one of them maintained. Before indexing, search your help centre for pricing articles and either delete them or update them, then crawl both origins together.
Before you go live
- The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
- Open the site as a visitor would, on the pages a SaaS company visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.
Questions
- Should the assistant answer at all when there is a ticket form right there?
- Yes, for anything documented, and it should hand over fast for anything else. The value on a help centre is not deflecting tickets in general, it is answering the reader who has already failed at your search box. A customer who has typed a question twice will use the form anyway, and by then they are annoyed as well as unanswered.
- Our best articles are restricted to signed in customers. What do we do?
- Either publish them, or export them and upload them as documents. What you must not do is assume the crawl saw them, because it reads as an anonymous visitor and gets exactly what an anonymous visitor gets. The tell is an assistant that knows your marketing content thoroughly and your operational content not at all.
- Can it see somebody's tickets or their subscription?
- No, neither. It has no view of a ticket queue and no view of billing state, and on a help centre the pull towards implying otherwise is strong because the person asking is usually signed in and reasonably assumes they are known. Word the refusal so it says plainly that it cannot see this account, then take a name and an email.
Keep reading
- Installing on Zendesk GuideEdit the help centre theme, add the tag to the footer template, publish the theme, and check what a signed out visitor can actually read.
- Everything for a SaaS companyOne widget serves prospects, trialists and paying customers. What it can answer about plans and limits, and what has to reach a person.
- Where the message goes once somebody has described their symptomsA help centre is where somebody describes their symptoms to explain a problem, and the handover emails that description to whichever inbox you nominated.
- A help centre anybody can read and a request form only account holders can useShoppers can read the delivery article and cannot open a ticket without an account. That makes the handover email the only route to a person.
- One origin, two build systems, and a tag from eachDocs proxied under a path on the marketing domain can end up carrying two tags, and the loader installs once, so one team's key quietly loses.
- Keeping the widget on the marketing routes and out of the productThe root layout is the documented place for the tag, and on a subscription product it is also the signed in dashboard. Move it down a level.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.