Why your team gives three different answers to one question
Ask three people in your company what your return policy is and you will often get three answers. One says seven days, one says fourteen, one says "depends on the product". The customer who gets the wrong answer tells a friend. The one who gets the right answer tells nobody.
Most Hong Kong SMEs do not have a knowledge problem. They have a retrieval problem. The correct answer exists somewhere — in a WhatsApp thread, in the owner's head, in a PDF from 2021 — but nobody can find it in under thirty seconds, so they improvise.
This guide is about fixing that with a small, boring, deliberately unglamorous internal knowledge base. Not a wiki project that takes six months. A working reference your team actually opens.
Step 1: Pick the twenty questions that actually get asked
Do not start by documenting everything. Start by counting.
Pull the last month of customer enquiries from WhatsApp, email and your website contact form. Tally the recurring ones. In most SMEs, twenty questions cover the large majority of what customers ask. Typical examples:
- Do you deliver to Macau, and how long does it take?
- Can I get an invoice with my company name?
- What is the lead time on a custom order?
- Do you accept returns on sale items?
- Who do I contact if the product arrives damaged?
Write the questions in the customer's words, not yours. "Can I pay by FPS" is a better entry title than "Payment Methods Policy".
Step 2: One answer, one owner, one date
For each question, record four fields. Nothing more:
- The approved answer — two to four sentences, written the way you would say it out loud.
- The owner — one named person responsible for keeping it correct. Not "the team".
- The last reviewed date — a plain date.
- The source — where the authority comes from (the signed supplier agreement, the owner's decision, the courier's published schedule).
The owner field is the part most SMEs skip, and it is the reason most internal knowledge bases rot. If nobody owns an answer, it becomes wrong quietly and stays wrong.
Step 3: Choose a tool you will actually maintain
You do not need enterprise software. Three workable options, in ascending order of effort:
| Option | Good for | Watch out for |
|---|---|---|
| A shared document with a table of contents | Teams under five people | No search, no version history |
| A free wiki or Notion-style workspace | Teams of five to thirty | Permission sprawl; people edit the wrong page |
| A helpdesk with built-in articles | Teams handling high enquiry volume | Monthly cost; migration later |
Whichever you choose, make sure it is searchable from a phone. Your staff answer customers on their phones, often while standing. If the answer is three taps away on desktop only, they will guess instead.
Step 4: Separate what staff may say from what only you may say
Consistency is not only about the wording of answers. It is about who is allowed to commit the company.
Mark each entry with a simple tag:
- Say freely — delivery times, opening hours, standard pricing.
- Say with care — discount eligibility, warranty interpretation.
- Escalate — refunds above a threshold, complaints, anything involving legal or personal data.
This tagging does more for consistency than any script. It stops a junior staff member from inventing a refund policy at 9pm because they wanted to be helpful.
Step 5: Put the knowledge base inside the workflow, not beside it
A knowledge base nobody opens is a document, not a tool. Two habits make the difference:
Link it from the places questions arrive
Put the link in your WhatsApp quick replies, your email signature template for staff, and the top of your shared inbox. If your team already routes enquiries through a structured intake process — the kind we describe in our work on enquiry handling — attach the knowledge base to that same screen.
Review on a fixed rhythm
Once a month, fifteen minutes. Sort entries by last reviewed date and look at the oldest ten. Ask the owner: still true? If yes, update the date. If no, fix it or delete it. Deleting a stale entry is better than leaving a wrong one.
Step 6: Feed the gaps back in
Every time a staff member cannot find an answer, they should log the question — even a one-line note in a shared chat. Once a week, the owner reviews the list and either writes the entry or assigns it.
This is the loop that keeps the system alive. Without it, the knowledge base covers the questions you had last year and misses the ones customers are asking now.
What this looks like after ninety days
A team of eight, twenty-five entries, one owner per entry, one monthly review. New staff onboard in an afternoon instead of a fortnight of shadowing. Customers stop getting contradictory answers. You stop being the single point of failure for every policy question.
None of that requires AI. If you later want an AI assistant to draft replies from the same entries, the knowledge base becomes the source of truth it draws from — which is a far safer starting point than pointing a chatbot at your entire inbox. If that is the direction you are heading, it is worth understanding what a structured build costs before you commit.
Summary
Consistent customer answers come from a small, owned, searchable reference — not from training people harder. List the twenty questions customers actually ask, give each one a single approved answer with a named owner and a review date, tag entries by who may say them, and put the link where enquiries land. Review monthly, log the gaps, and let the system grow from real questions rather than from a planning meeting.