An AI assistant in customer service answers from the knowledge you connect to it, so its answers are decided in the knowledge base before launch. Preparation comes down to four decisions: which sources go in, who owns each article, which fields every article carries, and how the first week of unanswered questions turns into new articles.
This guide is for the IT manager, informatiemanager or head of customer service at a Dutch or Flemish organisation of 250 to 5,000 people with a ticketing system and an ICT partner. Crux Digits builds the AI layer next to that partner; the checklist is the part you own, and it makes your human team faster too.
Which sources should a customer service AI answer from?
Answer from published sources with a named owner: the help centre, current product sheets, customer-facing policies and a cleaned FAQ. Old tickets and raw macros stay out as answer sources and become input instead.
Help centre articles go in first: they are written for customers, so the work is adding fields, not rewriting. The FAQ follows after a comparison with the help centre, because FAQ pages often carry a short answer that drifted from the original.
Product sheets go in as current versions only, one file per product version. Freshdesk's guidance for its AI agent says to avoid using files for content that changes frequently, so prefer an article there.
Policies go in as the customer-facing text (returns, warranty, delivery terms, general terms), each with a valid-from date. Goodwill limits and approval thresholds belong in the internal set.
Macros need a rewrite. A macro is written for an agent, with placeholders and steps like "check the order in the ERP first". Lift the reusable answer into an article and leave the macro for your agents.
Old tickets stay out as an answer source. A resolved ticket records what one agent told one customer on one date, exceptions and personal data included. The Autoriteit Persoonsgegevens summarises two GDPR principles that apply here: process no more data than the purpose needs, and remove personal data once it is no longer necessary. Use an export of subjects and first messages, stripped of names and order numbers, to learn which questions customers ask and in which words.
A simple decision rule covers every edge case: a source goes in when it has a named owner, a date, and would be acceptable if the assistant quoted it word for word to a customer.
Who should own each knowledge article?
Each article needs one named person who answers for its accuracy and approves changes. A role or a shared team inbox does not work as an owner.
The owner is whoever owns the fact in the business: the returns article belongs to the head of after-sales, the product sheet to the product manager, invoicing to finance. Customer service writes; the owner confirms.
Tooling already supports this. In Zendesk, article verification sends owners of unverified articles reminder emails on Mondays and Wednesdays; when the owner is a group, every member gets them, which argues for naming a person. Verification needs Zendesk's Enterprise or Enterprise Plus plan, or Knowledge Enterprise.
Ownership also routes corrections. The Knowledge-Centered Service method of the Consortium for Service Innovation describes Flag It or Fix It: whoever spots an error fixes it if they are confident and have the rights to edit, and flags it otherwise, and a flag must trigger a workflow that reaches a subject matter expert. Without an owner field, that flag has nowhere to go.
Which fields should every knowledge article carry?
At minimum seven: owner, valid from, review by, product, language, audience and status. Add version, superseded by and source reference for articles that change often.
Owner: a named person, with a deputy for holidays.
Valid from: the date the content became true, not the date it was typed. It tells an agent or the assistant which rule applies to an order placed before a change.
Review by: the date on which the owner must confirm or change the article. Dynamics 365 Customer Service has this built in: when you publish an article you can set an Expiration Date and an Expiration Status, and expired articles are no longer available in searches.
Product: the product or product line, plus the version or model year where answers differ. Dynamics 365 lets you relate an article to a product on the same publish screen, and Freshdesk lets you scope a knowledge source with rules on properties such as requester language and product.
Language: one article per language, linked as translations. If you serve both the Netherlands and Flanders, keep separate Dutch versions where terms, rules or contact details differ.
Audience: public, logged-in customer, partner or dealer, or internal only. This field decides which assistant may use the article.
Status: draft, published, under review or retired.
Version and superseded by: a version number, and on a retired article a link to the one that replaced it.
Source reference: the policy document, contract clause or product release the article summarises, so the owner can check it against the original.
Most platforms have fields or labels for half of these; the rest become custom fields. The rule that matters: no owner and no review date means no publication.
How often should customer service articles be reviewed?
Review each article as often as its fact changes: prices and policies on every change, product articles per release, how-to articles every six months.
Event-driven review comes first: the owner updates the article on the day a change takes effect. Schedule it: Zendesk can publish or unpublish an article automatically at a set day and time on its Enterprise plans, and Dynamics 365 has a Publish On field for the same purpose.
Calendar-driven review catches the rest. Zendesk verification rules run weekly and flag articles not verified within a frequency you choose, such as two weeks, six months or one year. Elsewhere, a saved view on the review-by field does the same.
Our suggested starting point, not a published standard: policies on every change plus a quarterly check; prices and delivery times on every change plus a monthly check; product sheets per release; how-to articles every six months. Start each review with the articles used most, because they do the most harm when wrong.
How do you stop the assistant quoting an old version?
Keep one published version per article, archive the rest, and check after each change that the old text has left the assistant's sources too.
Dynamics 365 enforces the first part: only one version of an article can be published at a time, and you create major or minor versions without touching the live one.
Retire articles instead of deleting them, so you can show what you told customers on a given day when a dispute arrives months later.
Not every assistant reads your help centre live. Zendesk's documentation for its earlier AI agents Advanced add-on describes imports that run daily, weekly, monthly or once. A corrected article can live on in the assistant's copy until the next import, so after a policy change, ask the assistant the changed question yourself.
For changes with a transition period, write two articles with their own valid-from and review-by dates, and let the assistant ask for the order or contract date before it answers.
What should happen when two sources give different answers?
Resolve conflicts before go-live with a fixed order of precedence: signed policy first, then product sheet, help centre, FAQ and macro.
Find them deliberately: look up your most frequent questions across every source you plan to connect, and list each disagreement with both texts side by side.
The owner of the higher-ranked source decides, and the losing text is changed or retired. An assistant that finds two answers uses one of them, and you do not control which.
Then hold the line with one question, one article. Freshdesk advises solution articles that focus on a single topic, task, or issue, with links to related articles rather than secondary workflows inside them. The day shift, the evening shift and the assistant then give the same answer, because they read the same text.
What should stay internal, and what may the assistant tell customers?
An article is public only if you would publish it on your website. Everything else carries an internal or logged-in audience and stays with agents or with an assistant that knows who is asking.
Internal content means escalation paths, goodwill limits, supplier contacts and unapproved workarounds. Write these as separate articles linked to the public one, with the same owner.
Check how your platform treats restricted content before you connect anything. Freshdesk's AI agent learns only from publicly visible solution articles; private or restricted articles are excluded. TOPdesk uses an availability option that decides which knowledge items a customer group or an operator group can see. Zendesk's earlier import documentation offers a switch to import private articles with an API token and warns that wrong credentials produce no error message, so test what the assistant can see.
Logged-in content, such as contract terms or order details, belongs to an assistant that has verified who is asking. Your agents gain from the same split: the internal article in their workspace, the public one on the website, both saying the same thing.
How do you use the first week of conversations to fill the gaps?
Review every conversation the assistant could not answer or handed over, daily for five working days, and give each gap an owner.
Pull three kinds of conversation: handovers to a person, replies where the assistant said it did not know, and conversations where the customer repeated the question. Then sort each one into one of five buckets.
No article exists: the owner writes one. Article exists but was not found: rewrite the title and first sentence in the words the customer used. Article was outdated or conflicting: the owner corrects it and the version changes. No policy exists: the question goes to the business owner for a decision, not to the writer. Should always reach a person (complaints, legal questions, personal data requests): add a handover rule, not an article.
Keep the list plain: question, bucket, owner, date fixed. A daily half hour with the customer service lead and the knowledge editor is enough. After week one, go weekly.
Zendesk's AI agents can show customers a Sources link with the articles used for an answer, on by default, so each transcript shows which article produced which reply. Keep transcripts under the same retention rules as tickets. For what to measure once the gaps close, see our piece on the number to check first in an AI service desk.
Every fix improves your agents' answers as much as the assistant's.
Where do SimplyBoost and Crux Digits fit?
There are two routes, and this checklist applies to both: an off-the-shelf assistant, or a custom build on your own systems.
SimplyBoost is our own product: an AI support agent that answers from your website, PDFs, FAQ and catalogue on website chat, WhatsApp, Instagram and Facebook Messenger. An account runs three AI agents, so a public assistant and a portal assistant can each draw on the audience they are meant for. The portal agent works on logged-in pages and recognises users by verified email. It replies in Dutch, French, German, Spanish and English, and it hands over to a person or to Zendesk, Freshdesk, Gorgias or Slack with the conversation attached.
The custom route is Crux Digits, for an assistant that must read your ERP, ticketing data or several sources under one precedence rule. An AI audit costs €2,500, a Production-ready MVP €20,000, and production starts from €50,000, all excluding VAT, and you receive the code. We build alongside your ICT partner. Your ticketing system, its hosting and its support stay where they are.
More on the custom route: AI customer support agent.
Last updated: 28 October 2026.
SimplyBoost, our own product, answers from your documents on website chat and WhatsApp. When the answer has to come from your own systems, we build that part.
AI customer service agent →
