What Goes in a Knowledge Base: The Practical Setup Guide

When a managed enquiry workflow responds to a new prospect, it is drawing on a knowledge base: a structured document that contains everything the workflow needs to know to represent the business accurately. The knowledge base is not software. It is not a database. It is a curated set of approved information that has been built, reviewed, and signed off by the business owner.

The quality of a managed workflow is directly tied to the quality of its knowledge base. A well-built knowledge base produces responses that sound exactly like the business. A thin or inaccurate one produces answers that hedge, go off-script, or — worse — give prospects incorrect information with confidence.

This article is a practical guide to what a knowledge base contains, how it is organised, and how to keep it accurate over time.

In short: A knowledge base has six core sections: what you do, where you do it, how pricing works, what the next step is, what you cannot help with, and how edge cases should be handled. Building it right once produces a workflow that runs accurately for months with minimal intervention.

Section 1: Services and what they cover

The starting point is a clear, complete description of what the business offers. Not the marketing version — the operational version. What does each service actually include? What are the constraints? What is out of scope?

For an estate agent: what types of property do you list? Do you cover lettings as well as sales? What areas do you cover, and are there any postcode ranges you decline? Do you offer valuations to landlords or vendors separately?

For a mortgage broker: do you cover residential and buy-to-let? Do you work with first-time buyers? Do you handle cases with credit issues, or refer those out? What lenders do you have on your panel?

For a clinic: which treatments do you offer? Which conditions do you treat? Which categories (cosmetic surgery, prescription-only, paediatric) are specifically out of scope?

The workflow cannot answer a question the knowledge base does not cover. If the service description is vague, the response to a specific question will be vague. The setup process is the moment to get specific, even on details that feel obvious from the inside.

Section 2: Areas and locations served

For most service businesses, geography matters. The knowledge base needs to contain clear, specific information about where the business operates.

This sounds simple, but it often requires more precision than expected. "We cover East London" is not sufficient if the business does not cover every part of East London. Specific postcodes, boroughs, or named areas produce accurate responses; general descriptions produce responses that sometimes turn out to be wrong when an enquirer follows up to confirm.

For businesses that travel to clients (trades, home services, some clinic services), the operational radius and any minimum call-out requirements belong here. For businesses with a physical location, travel time and access information may matter to some enquirers.

Section 3: Pricing approach

Pricing is the question most businesses are tempted to be vague about, and the wrong approach here costs the most. The options are:

Published pricing: state it explicitly in the knowledge base. The workflow can quote it accurately and enquirers know where they stand.

Range pricing: state the range with the factors that determine where within the range a specific case falls. "Lettings management fees run between 8% and 12% of monthly rent, depending on the service level and the property." This is honest and useful without committing to a specific number before a full picture is available.

Consultation-only pricing: acknowledge it explicitly. "Pricing depends on your individual situation — [name] will give you a clear figure during your free consultation." This is a legitimate and common approach for professional services. What it cannot be is evasive silence — "I'll have to get back to you on that" is not a response, it is a reason for the enquirer to go elsewhere.

The worst position is no guidance at all. An enquirer who cannot get any pricing indication has to commit to a meeting on pure trust. Many will not.

Section 4: The next step

The most practically important section of the knowledge base is often the most overlooked: what should happen when a new enquiry arrives?

For a valuation request: is the right response to book a slot, take contact details, or direct them to a specific link?

For a mortgage enquiry: is the first step a discovery call, a fact-find form, or a direct meeting booking?

For a new patient at a clinic: do they book a consultation via a specific booking system, or do they fill in an enquiry form first?

The knowledge base should contain the specific action, the link or contact method, and any qualifying questions the workflow should ask before sending the enquirer on to the next step. A workflow that cannot tell an enquirer how to proceed has failed its primary purpose.

Section 5: What the business cannot help with

Equally important is an explicit list of categories that should always go to a human. A good knowledge base does not just define what the workflow handles — it defines what it does not handle.

Common examples: any complaint or expression of dissatisfaction (never handled by the workflow — always flagged for the business owner); any query that touches regulated advice (legal, financial, medical, tax — in the UK, specific regulatory boundaries apply); any request that requires a contractual decision; any situation the workflow encounters that does not match the defined categories.

When an enquiry hits one of these triggers, the response is not to attempt an answer — it is to acknowledge receipt and confirm that a person will follow up directly. This is not a failure mode. It is designed behaviour.

Section 6: Tone and voice

The final component of a knowledge base is style guidance: how the business communicates. Is the tone formal or informal? Does the business use first names or defer to "Mr/Ms [surname]"? Does it prefer concise answers or fuller explanations?

This section tends to be short — a paragraph at most — but it matters. A workflow that responds in a chatty, casual tone to enquiries that the business handles formally creates a mismatch between the first interaction and every subsequent one.

Keeping it accurate

A knowledge base requires maintenance when the business changes. New services added. Areas expanded. Pricing revised. A team member who used to handle specific enquiries now doing something different. The workflow does not know about any of these changes unless the knowledge base is updated.

The right approach is to treat the knowledge base like a document that lives alongside the business: updated when things change, reviewed quarterly if nothing has changed, and tested after any significant revision. A managed workflow provider makes this update process part of the service — but the trigger for an update usually comes from the business owner, because they know when something has changed.

Frequently asked questions

How long does it take to build a knowledge base?

The initial build typically takes a 45-minute intake session plus one round of review — usually two or three days from intake to a signed-off knowledge base. Most of the time is in the review and refinement, not the initial build. The more prepared the business owner is with specific answers, the faster it goes.

Can we start with a partial knowledge base and add to it?

Yes — the approach is to build a complete enough knowledge base to go live confidently, even if it does not cover every possible edge case. The first few weeks of live operation surface the questions the initial build did not anticipate, and those gaps are filled in during the calibration phase.

Who writes the knowledge base — us or the provider?

The provider structures and writes it based on the intake session. You review, correct, and sign it off. You do not write it from scratch — that would require knowing the format and structure that makes it work, which is the provider's expertise. Your role is the content: the accurate, specific information that only you know about your own business.

What happens when the workflow encounters a question the knowledge base doesn't cover?

A well-designed workflow is built to recognise when a question falls outside its knowledge base. In that case, it acknowledges the enquiry, takes contact details, and flags it for human follow-up. It does not attempt to answer with incomplete information. This is the correct behaviour — the alternative (guessing) is worse than admitting a gap. For what the first month looks like once a knowledge base is live, what happens in the first 30 days of a managed enquiry workflow walks through the calibration and review process in sequence.