Build a small-business knowledge base

A small-business knowledge base is a service system, not a folder of polished FAQs. Its job is to let a customer complete a task without waiting for an agent, while keeping the human route obvious when the answer depends on an account, order or judgement. The useful starting point is the support queue: what are people repeatedly asking, and which of those questions can be answered safely in public?

This workflow is for a team that has little dedicated content capacity. It deliberately starts with a narrow release and a maintenance agreement. If you are still choosing software, read our knowledge-base software comparison alongside this process; the platform will not replace the editorial work.

1. Choose a small, evidence-led launch set

Export or review the last two to three months of tickets. Group them by the customer's underlying task, not by the team's internal department. “Where is my order?”, “Can I change the delivery address?” and “My parcel says delivered but is missing” require different answers even though all involve delivery. Record contact volume, effort per case, consequence of a wrong answer and whether the customer can complete the task without private information.

Prioritise topics that are both common and answerable. Account-specific refunds, safety issues and disputes may need an explanatory article, but not a public promise that the reader can self-authorise an outcome. Include a few critical low-volume topics too: a clear data-export or cancellation guide may matter disproportionately to trust. Do not bulk-publish every old macro; a reply written for an agent often assumes hidden context.

Create an initial list of ten to twenty topics, one intent per article. For a simple online retailer, that might include order tracking, delivery zones, changing an address before dispatch, returns eligibility, damaged items, account access and payment failures. For SaaS, replace the commerce tasks with setup, permissions, billing, imports and common error recovery. This is a launch backlog, not a requirement to write thin pages to meet a quota.

2. Decide where the content lives

Pick a structure readers can predict. Three to six top-level groups are usually easier to scan than a page of product-team names. Inside each group, cluster related tasks; avoid nesting every article several layers deep. Our structure guide shows how to test labels with customers and handle articles that cross two topics. Search should work even when a visitor never browses a category.

Choose whether a public help centre is enough or whether customers also need a signed-in portal for ticket status and account-specific actions. Those are different needs. Keep sensitive internal procedures separate from public guidance and verify visibility on a non-admin account. Freshdesk's documentation describes category, folder and article visibility; Zendesk supports user segments for more granular access. The capability matters only if the team can administer it consistently.

Check URL permanence, redirects, export, authoring permissions, search feedback, article versioning and how an article is suggested while someone submits a ticket. A cheap publishing tier can be expensive if the team must maintain answers in a second disconnected system. Equally, an elaborate service suite may be unnecessary for fifteen simple pages. Model the publishing workflow, not just the editor screen.

3. Write answers that finish a task

Use the customer's language in the title: “Change a delivery address before dispatch” is clearer than “Fulfilment amendments”. Open with the answer or the condition that decides it. State who the steps apply to, what the reader needs, the steps in order, the expected result and what to do if the result differs. Put exceptions near the step they affect instead of hiding them in a final paragraph.

Screenshots help when a control is hard to identify, but they age quickly. Pair them with text that names the control and explains the outcome. Avoid images as the only carrier of an instruction. For changing flows, write a review trigger such as “billing screen changes” instead of relying on an optimistic annual reminder. Our help-centre article guide includes a reusable drafting and test process.

Before publishing, ask someone who did not write the page to complete the task using only that article. Observe where they pause, search for another term or contact support. If the test cannot be completed safely without a real account, use a representative non-sensitive example and mark the boundary clearly. A published page should not be mistaken for authority to bypass account verification.

4. Assign ownership before launch

Record a subject owner, editor, last substantive review month, risk level and trigger for each page. The owner checks factual steps; the editor checks that the answer is findable and understandable. In a two-person company those may be the same person, but the responsibility must still exist. Put product releases, pricing changes, policy changes and repeated negative feedback into the review queue.

Build an agent feedback loop. When an agent sends an article and the customer still replies, capture why: missing step, wrong eligibility, misleading title or an exception not covered. A simple tagged ticket view can be more useful than an impressive analytics dashboard that nobody reads. Zendesk's self-service guidance describes article and search metrics, but measurement should follow the team's actual workflow.

Set a safe retirement process. If an article is obsolete because the product changed, update or redirect it rather than leaving conflicting instructions live. If a service no longer exists, explain the current route and remove links that falsely promise it. The content audit guide covers a monthly risk-based sweep.

5. Launch, place and measure

Put the help-centre link where a customer needs it: navigation, account area, contact form and relevant product or checkout pages. Suggest articles beside a contact option, not as a barrier that prevents someone from reaching a person. Test searches using real wording, misspellings and old feature names. Test on a phone and with keyboard navigation as well as a desktop browser.

For the first month, review zero-result searches, article feedback, repeat tickets and cases created after an article view. Watch the covered-topic contact rate, but interpret it alongside total demand and seasonality. A drop in tickets may reflect lower sales or a hidden contact route, not better self-service. Ask a small group of customers whether they could finish the task, and keep an obvious escalation link where the answer stops.

The first release is successful if the pages remain accurate, customers can reach a result and agents know how to improve a weak answer. Expand only after that loop works. Google's people-first guidance favours substantial useful content over pages created merely to target queries; the same principle makes a support knowledge base worth maintaining.

Sources

• Freshdesk guide to knowledge-base categories, folders and articles
• Zendesk guide to tracking self-service metrics
• Google Search Central on helpful, people-first content

Provider capabilities come from their documentation. The launch sequence and product-fit advice are Support Sorted's editorial judgement.