Opening: support answers the same 30 questions every day
One SaaS client's support team handled about 1,200 tickets a month, nearly 40% of them the same 30 questions over and over. Agents burned out, answer quality varied, and the owner saw only 'we're understaffed, hire more'. The real fix is usually not more headcount but a knowledge base that lets customers find answers themselves — intercepting that 40% of repeat tickets at the source.
When it fits vs when to wait
| A KB fits | Hold off on a KB |
|---|---|
| Lots of repeat questions, high ticket volume | Product changes wildly, docs go stale on write |
| Product has real complexity, needs teaching | Issues are highly case-specific, can't standardise |
| You want to cut support cost, raise self-serve | Very few customers, verbal support suffices |
| You want SEO / AI-citation long-tail traffic | Content is highly confidential, unfit to publish |
| Someone can maintain content continuously | Nobody owns updates (the most common failure) |
Alternatives matrix
| Option | Pros | Cons | Cost tier |
|---|---|---|---|
| SaaS support KB (Zendesk Guide, Intercom) | Fast start, bundled ticketing | Per-seat fees climb, limited customisation, data locked in | Mid-high: monthly + per seat |
| Open-source doc framework (Docusaurus, GitBook) | Free/low cost, dev-friendly | Skews technical, you build marketing/search UX | Low-mid: mostly build hours |
| Custom KB (Laravel + Meilisearch/Algolia) | Full control, deep site/ticket integration, best SEO/GEO | Higher upfront build | Mid: one-off build + small retainer |
| Bolt onto existing CMS (WordPress plugin) | Cheapest, reuse the site | Weak search/structure, hard to scale | Low: plugin + config |
Full process breakdown (time, deliverables, tools)
We split a KB build into five stages, typically delivered in 6-9 weeks:
- Stage 1 | Content audit and architecture (1 week): collate existing tickets and FAQs, find high-frequency questions, produce a category tree and article list. Deliverable: a content map (Notion/Miro).
- Stage 2 | Information architecture and design (1-2 weeks): design category navigation, article templates, search placement. Deliverable: Figma wireframes and visuals.
- Stage 3 | Build and search integration (2-3 weeks): build on Laravel, wire up Algolia or self-hosted Meilisearch for instant search. Deliverable: a working KB prototype.
- Stage 4 | Content migration and SEO/GEO (1-2 weeks): move articles in, embed FAQPage/Article structured data, set 301s and a sitemap. Deliverable: launch-ready site.
- Stage 5 | Launch and optimise (1 week+): go live, connect Google Analytics and search-term analytics, link the support ticket entry. Deliverable: launch + a data dashboard.
Real cost breakdown
- Build fee: a custom KB typically lands at NT$80,000–180,000 (depending on article volume and search complexity).
- Search service: Algolia has a free tier and meters beyond it; self-hosted Meilisearch is server cost (a small VPS from ~NT$300–800/month gets you started).
- Hidden costs: SSL (usually free via Cloudflare), CDN traffic, content writing/rewriting hours, and post-launch content maintenance (the most underestimated line).
- Maintenance: a small retainer of NT$5,000–15,000/month is advisable, covering content-update help, search tuning and performance monitoring.
Implementation reality vs client imagination
| Clients assume | What actually happens |
|---|---|
| Just paste the FAQ up | Without categories and search, 50+ articles become unfindable |
| Tickets drop the moment it's live | You must drive traffic and guide it in the ticket flow first |
| Write once, done forever | Product changes make content stale; you need a maintenance rhythm |
| Search is a secondary feature | Search is the core; if it's poor, the whole KB fails |
Common pitfalls and how to avoid them
- Pitfall: nobody maintains it -> assign a clear content owner and schedule monthly updates.
- Pitfall: categories use internal jargon -> name categories with the words customers actually search, not company slang.
- Pitfall: poor search UX -> use a proper search service (Algolia/Meilisearch) with typo tolerance and instant results.
- Pitfall: no measurement -> connect search-term analytics, watch 'searched but no result' terms, and back into the articles you need.
- Pitfall: disconnected from ticketing -> put a visible 'contact support' entry where answers aren't found, to avoid churn.
- Pitfall: ignoring structured data -> embed FAQPage/Article JSON-LD so content is cited correctly by search engines and AI.
Success metrics + 90-day roadmap
- Day 30: GA and search-term tracking live; baseline set (ticket volume, self-serve rate, zero-result search terms).
- Day 60: add 10-20 articles from zero-result terms; improve readability and structured data on the top 20 traffic pages.
- Day 90: review the drop in repeat tickets (target 20-35% down), self-serve resolution rate, AI-citation coverage of key questions, and set the next content priorities.
Decision checklist
- ☐ Does support get lots of repeat questions monthly?
- ☐ Can most of those be standardised into docs?
- ☐ Do I have someone to maintain content continuously?
- ☐ Do I want SEO / AI-citation traffic too?
- ☐ Are my product docs scattered across places?
- ☐ Do customers often complain they can't find info?
- ☐ Am I willing to fund a one-off build + small maintenance?
- ☐ Can I provide existing FAQs/tickets as content material?
- ☐ Do I need on-site search (more than 30 articles expected)?
- ☐ Do I want the KB linked to support ticketing?
Frequently Asked Questions (FAQ)
How is a knowledge base different from a blog or FAQ page?
A blog is chronological and marketing-led; an FAQ page is usually a single stack of Q&As. A knowledge base is a categorised, hierarchical, searchable self-service system whose goal is letting customers find answers without opening a ticket. A good one visibly cuts support volume — something a blog cannot do.
Do I really need on-site search? Isn't Ctrl+F enough?
Once you pass 30-50 articles, category browsing breaks down and users who can't find something just open a ticket or leave. On-site search (Algolia, Meilisearch) is the core of a knowledge base, not a bonus. A KB without search is a library with no catalogue.
Can it be cited by ChatGPT or AI Overviews afterwards?
Yes — a KB is among the most-cited content types because it is well structured, with specific questions and clear answers. The precondition is embedding correct structured data (FAQPage and Article JSON-LD) and leading with the conclusion. That's the dual value: it serves customers and GEO at once.
Do we write the content or do you?
We recommend a split: you know the product and process best, so you supply the raw material; we handle information architecture, rewriting into readable Q&A structure, embedding structured data and wiring up search. Full ghost-writing is possible but costly and prone to drift; the best model is 'you provide the material, we shape it'.
Call to action
ScriptWalker offers a Knowledge Base / Help Center build, with custom plans from NT$80,000 (including information architecture, search integration and structured data). Want to know how many of your support tickets a KB could intercept? Book a free 30-minute consultation:
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p