How to Build a Knowledge Base That Cuts Repeat Questions

Can a knowledge base really reduce repeat support questions?

Yes, for questions that have one clear answer and keep coming back. How to get a copy of an invoice, how to reset a password and which documents a return needs can all be handled by an article, provided the customer can find it and it is correct.

It will not help much with account-specific cases, disputes or problems caused by a broken process. If customers keep asking why deliveries arrive late, the fix sits in dispatch, and an article can only explain the delay. Zendesk's guidance makes a similar point about articles with negative votes: when the problem is the product, pass the feedback to the team responsible.

A knowledge base also helps your own staff. Agents get one approved answer to send, so two people stop giving the same customer two different answers, and a new hire can look something up without interrupting a colleague.

Which articles should you write first?

Write first for the questions that reach your team most often and take the most time to answer. Zendesk's guide to starting a knowledge base lists four kinds of issue to look for: common issues, FAQs, known issues that affect many customers and issues that take a long time to solve.

You do not need special software for this step. A shared spreadsheet with the question, how often it appears, how long it takes to answer and who will write it is enough. Fill it from these places:

Ticket categories. If your tickets have no issue field, add one and ask agents to fill it in. Zendesk suggests collecting about 500 tickets before drawing conclusions and giving categories with fewer than 30 more time. A smaller business will take longer to reach that number, so treat an earlier result as a first draft.
The tickets themselves. Read a sample from your biggest categories, because Zendesk notes that subject lines alone are usually not enough to show the specific problem.
Canned replies. The replies agents send most often point straight at the questions customers keep asking.
One-touch tickets. Tickets solved with a single agent reply are often simple enough for an article to handle.
WhatsApp and phone. If much of your contact never becomes a ticket, ask agents to keep a simple tally of questions for two weeks.
Your agents. Ask what they are tired of answering, and collect any personal cheat sheets they keep.

How should you structure a knowledge base and each article?

Use a shallow structure that customers recognize, then give each article one problem and one fixed format. Group articles by what the customer is trying to do, such as orders, payments, returns and account access. A customer does not know which of your departments owns a refund, so a menu built around departments makes them guess.

Keep public help and internal notes apart. Customers need the steps. Agents may also need escalation rules, exceptions and who to call, and those belong in an internal handbook. Before you publish, check screenshots for customer names, phone numbers and prices.

KCS (Knowledge-Centered Service), a support method published by the Consortium for Service Innovation, advises starting with one simple template and adding others only when experience shows a need. Its fields adapt well to a help center:

Issue: the situation in the customer's own words, such as "my invoice did not arrive". KCS says these words and phrases make the article easier for the next person to find.
Environment: what the answer applies to, such as the product, the app or the type of account. Precise statements help readers tell apart similar symptoms that need different fixes.
Resolution: the answer or the steps. Zendesk recommends numbered steps when order matters and bullets when it does not.
Cause: why it happened. KCS treats this as optional and mainly useful for complex problems.
Article details: audience, owner and change history, kept for your team to manage the article.

What makes a help article easy to find and read?

A clear title and a short body do most of the work. Zendesk recommends action-based titles and warns that vague ones hide what an article covers, so "Request a copy of your invoice" will serve a customer better than "Invoices". A community contributor quoted in the same guide suggests a short solution to one core issue per article, and Zendesk advises splitting long content into shorter topics with clear headings.

Readers will skim whatever you write. In a 1997 Nielsen Norman Group study, 79 percent of test users always scanned a new page and only 16 percent read word by word. The group's guidance on help content asks for concrete steps tied to the user's task, kept brief and easy to scan. Put the answer in the first line, explain any term a customer may not know, and link related articles at the end.

How do you write help articles in Arabic and English?

Write each version from the meaning, so that it reads as if it started in that language. Microsoft's style guide for Saudi Arabic warns that word-for-word translation makes the tone stiff and unnatural, and it allows translators to split or simplify sentences. Start in whichever language most of your tickets arrive in, which may differ from the language your managers write in.

Agree a one-page style sheet before the second article, and have it settle these points:

Register: Modern Standard Arabic that a customer in Riyadh, Amman or Baghdad can follow, with one form of address used in every article.
Terms: one Arabic word for each concept, and button names spelled exactly as the interface shows them. Microsoft's guide notes that product names are rarely translated.
Digits: W3C's Arabic layout notes list Arabic-Indic digits (٠١٢) for Saudi Arabia and Iraq, while Microsoft's Saudi guide tells translators to use 1, 2, 3 as a general rule. Pick one and apply it everywhere. Microsoft also writes one and two as words, because Arabic has a dual form.
Screenshots: capture them from the interface in the same language as the article.

How do you make Arabic articles searchable and display correctly?

Plan for the different ways people type a word, because search is where Arabic help content most often fails. Customers write in dialect and spell the same word in different ways: فاتورة may be typed as فاتوره, and some customers will type the English word invoice. Keep the article itself in standard Arabic, then add the variants your tickets show as search labels or in the body text. Zendesk suggests labels for alternate terms and misspellings. Test your help center search with those variants before launch, because tools differ in how they treat Arabic spelling.

If you build or customize the site, ask your developer to set the text direction in the markup. W3C advises adding dir="rtl" to the html tag of an Arabic page, avoiding CSS for base direction, and using dir on a single block only when that block changes direction, such as an English quotation. Its layout notes explain that numbers run left to right even inside Arabic text and that Latin text keeps its own direction, so check phone numbers, order codes and mixed sentences on a real phone.

How do you keep articles current?

Give every article a named owner and tie updates to events in your business. A new price list, a changed return policy, an app release or a new tax rule should each trigger a check of the articles they touch. A review date on the calendar helps too, but it is usually a change in the business that makes an article wrong.

Version history makes this work safer. You can see what changed and when, and restore an earlier version if an edit turns out to be wrong. A few habits keep the work from landing on one person:

Flag it or fix it. Under KCS, anyone who spots a problem fixes it if they are confident and allowed to edit. Otherwise they flag it, and the flag should reach someone who knows the subject.
Check while you use. KCS calls this "reuse is review": each time an agent sends an article is a chance to confirm it is still right.
Keep languages in step. Zendesk handles translations as separate versions that can be flagged as needing an update. Whatever tool you use, change Arabic and English in the same task, or mark the other language as out of date until it catches up.
Archive with care. Zendesk suggests checking whether an article is still searched for and used, and updating links to it first, because those links stop working once it is archived.
Get sensitive wording checked. If an article touches VAT, e-invoicing, refund terms or personal data, ask your accountant or legal adviser to confirm it, and check again when the rules change.

How do you know the knowledge base is working?

It is working when the questions you wrote about arrive less often relative to your customer numbers, and when people who search find something. No single number proves this. KCS describes self-service measures as imprecise, advises combining data, user feedback and observation, and says the trend matters more than the absolute value.

Record ticket counts for your top categories before you publish, then compare month by month. A busy season or a new customer group can move those counts, so read them alongside your total number of customers. Then look at these signals:

Searches with no results: Zendesk says these suggest missing content, although some are just nonsense strings. KCS adds that a customer's search terms can become the problem statement of a new article.
Searches with no clicks: these may show a content gap, or titles that do not match what people typed.
Tickets created after a search: either the answer was missing or the article did not say enough. The number will not tell you which, so read some of those tickets.
Article votes and comments: many negative votes suggest an article needs updating, and comments can show where it is confusing or incomplete.
Self-service score: Zendesk's formula divides help center sessions by the users who raised tickets in the same period, so 4:1 means four self-service users for each customer who submits a ticket. A rising ratio is the good sign.

How does Repzo handle this?

Content Hub in Repzo Workstation is where you write and publish help content. You create a collection for each type of content, arrange articles in a hierarchy and write in a rich editor with structured publishing controls. Customer-facing help centers and internal handbooks are published from one workspace, and a public reader lets you share articles outside the company.

For upkeep, Content Hub includes version history with rollback and scheduled publishing, so an article about a new policy can go live on the day the policy starts.

Content Hub works alongside tickets and the inbox, giving agents guidance and supporting ticket deflection with searchable content. The help desk has canned replies, knowledge-base articles, ticket categories and tags, which are the raw material for the ticket review described above. Analytics and reporting includes ticket reporting and trend analysis, which you can use to compare volumes over time.

The workspace works in Arabic and English, with right-to-left support. If your process depends on how language versions of one article are linked, or on reports for failed searches and article votes, ask our sales team to show you, because the feature pages do not detail them.

Frequently asked questions

How many articles do we need before launching?

Enough to cover your most common questions. Zendesk's guide sets no number. In our judgment, ten to twenty articles is a workable first batch for a small or mid-sized team, and failed searches and new tickets will show you what to add next.

Who should write the articles?

Agents should supply the first draft, because they know the customer's wording and the real answer. One person should then edit for consistency and own the list of what still needs writing, so the work does not depend on whoever has spare time.

Should we publish both languages from day one?

Publish both for your top questions if your customers use both. If you cannot, launch in the language most tickets arrive in, add the second in batches, and make sure customers reading in that language can still reach an agent easily.

Should we hide the contact option so customers read the articles first?

No. Keep a clear route to a person. KCS warns against self-service dead ends and asks that a customer's search effort stay visible to the agent who picks up the case, so the customer does not have to start again.

What is a good self-service score?

Zendesk's guide gives no target value, so compare against your own earlier months. Businesses differ too much in product and customer base for another company's ratio to tell you much, and KCS also advises watching the trend.

Can agents send help articles on WhatsApp?

Yes. A public article has a link, so an agent can paste it into a reply and add a line about the customer's specific case. If several people answer from one number, see our guide to a shared WhatsApp inbox.