Zendesk Guide and fintech app
Publishing an article and publishing an answer are the same act here
Everything a regulated firm puts out in its own name is governed, and a help centre article is put out in the firm's name. The awkward part is that the two workflows meet nowhere. Compliance approves wording in one place and the help centre puts articles live from another, on the judgement of whoever holds the permission. The assistant sits downstream of both, and it holds whatever it last read for as long as it holds it.
Why this pairing is its own job
The Zendesk Guide install guide covers the tag, and the fintech app guide covers what the assistant has to know. What follows is the part that belongs to neither.
- Approval and publication are separate acts. Somebody with the right role can put an article live in a minute, and from that minute it is a communication in the firm's name that the assistant may quote and cite. Nothing in the publishing step asks whether the wording went through a process.
- The corpus lags in both directions. An article withdrawn this morning stays answerable until the next crawl, and a correction made this morning is not answerable until then. On an ordinary site that is staleness. Here it is a window during which the firm is still saying something it has retracted.
- A help centre is the one place where the fraud material is certainly published, certainly well written and certainly the strongest match for a frightened question. That is not the help it looks like, because somebody watching money leave an account needs a telephone number in the first line rather than a numbered procedure.
- The largest safely answerable block in this trade, the fee schedule and the limits table, is plain article text here rather than something a browser assembles after the page arrives. That is a real advantage of this platform for this product, and it is where the material budget should go first.
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 fintech app site specifically.
Decide who may publish before you decide what to index
The theme edit that puts the tag in is an administrator action and feels like the boundary. It is not. The boundary that matters is the list of people who can publish an article, because that list decides what the assistant is able to say in your name.
Write the list down and take it to whoever owns approvals. On most firms it is longer than compliance expects, because permissions accumulate with agents who joined to answer tickets rather than with anybody who thought of themselves as an author.
This is a governance conversation rather than a configuration one, and it is easier to have before the assistant exists than after somebody has read back an answer nobody signed off.
Put the crawl in the same job as the approval, not on a schedule
A monthly re-index is fine for a shop. Here the events that matter are approvals, corrections and withdrawals, and none of them fall monthly.
Tie it to the workflow instead. When an article changes for a regulatory reason, the re-index happens in the same piece of work, by the same person, before the ticket closes. Anything looser leaves a gap whose length nobody in the firm can state.
It also gives you an answer to a question somebody may eventually ask, which is how long the firm carried on saying a thing after it stopped meaning it.
Keep the fraud number out of the material and in the refusal
Material surfaces when a question matches it, and the questions that need this most are typed by somebody frightened and typing badly, which is exactly when matching is least reliable. A setting does not have that problem.
So the number belongs in the refusal wording itself, ahead of any handover form, while the fraud article stays published for people who are reading rather than panicking. A form collecting a name and an email is the right mechanism for an ordinary enquiry and the wrong one for somebody watching a payment leave.
Where the answerable material lives
| The fee schedule and the limits table, as plain articles | Every fee, every threshold, every daily and monthly limit, and the conversion rule where you handle more than one currency. These are ordinary article text on this platform, which makes them the largest block of safely answerable volume you own and the cheapest to get right. |
|---|---|
| Verification requirements, published as requirements and never as troubleshooting | Which documents are accepted and what a proof of address has to show. What must not be indexed at all is anything explaining why a particular check did not pass or what to change so it passes next time, and a help centre is under constant pressure to blur that line in the name of being helpful. |
| The protection statement in the wording that was approved | Quoted rather than summarised. The careful phrasing of a protection or safeguarding statement is the whole of its value, and a fluent summary that drops a qualification is a statement the firm never made. |
| Articles about products you have withdrawn | A help centre keeps them because customers still hold the product, which is a good reason. It also means the corpus holds descriptions of things nobody can now buy, phrased as an offer, and a prospect asking about one gets a page on your own domain saying they can have it. |
The first thing to get right
List every account that can publish an article, take that list to whoever owns approvals, and settle it before the first crawl runs.
The corpus is downstream of the loosest publishing right in the help centre, and no threshold, refusal wording or crawl scope changes that. It is also the only item here that gets harder once the assistant is live, because by then somebody has to be told their article is being quoted in answers.
The failure that belongs to this combination
The article that was withdrawn on Tuesday, still answering on Thursday
A term changes, or a wording turns out to be unclear, and the article comes down. Everybody who needed telling has been told, the help centre is correct within the hour, and the firm believes the matter is closed.
The assistant answers from what it last read. The article is out of the help centre and still in the material, so it keeps producing the retracted wording with a numbered citation attached, and that citation now points at an address that has gone or been replaced. A customer reading a sourced answer has no reason to doubt it and no way to check that the source no longer says it.
There is no setting that closes that window, only a habit. Re-index in the same job as the withdrawal, then ask the assistant the question the article used to answer. If the old wording comes back, the corpus has not been read again yet, whatever the help centre now looks like.
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 fintech app 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
- Can it answer account questions, since people reading a help centre are usually signed in?
- No, and the pull towards it is strongest here for exactly that reason. It has no view of a balance, a payment or a restriction, and nothing to look one up with. Say that plainly in the refusal rather than talking around it, then take a name and an email so somebody with access can pick it up.
- Compliance wants to review what it is allowed to say. What do we give them?
- The list of articles that will be indexed, the refusal wording, and the match threshold. Those three between them are the whole of what it can produce, because it answers from indexed material and returns your own wording below the threshold. Reviewing the article list is reviewing the assistant.
- An agent published something that was not approved. What happens?
- It gets read at the next crawl and then quoted until the crawl after that. Nothing downstream of publication filters for whether wording was approved, because nothing downstream can tell the difference. That is why the publishing list is the control on this pairing and everything else is a mitigation.
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 fintech appFees, limits and identity checks are safe ground. Balances, transactions and anything reading as a personal recommendation are not.
- A help centre on one domain and the commercial material on anotherThe help centre holds how-to articles. Plans, limits and trust pages live on your marketing site, a separate origin and a separate crawl.
- 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.
- Getting a third party script past the policy a regulated product ships withThe policy decides whether the tag runs at all. Script and frame directives both matter, and a report only header proves nothing.
- Publishing a financial promotion with a single buttonThe number sits in one element and the sentence that qualifies it in another, and publishing a financial promotion here is one button anyone with access holds.
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.