Knowledge Base, Satisfaction & Calls

The Knowledge Base

The knowledge base holds categorised articles users can read for themselves — how to do something, what a term means, what to do when something goes wrong.

Where to find it

Architect Panel → Help & Support:

• Knowledge Base — categories and their articles
• Manage Articles — the in-application help content

What it is for

Deflecting questions that have a settled answer. Anything asked more than about five times is a candidate: it is a question with a stable answer, and answering it individually each time is work nobody needs to do.

Categories

Organise around what a user is trying to do, not around your internal structure. People search for "change my direct debit", not for "Payments Team procedures". A category tree mirroring your org chart is a category tree nobody navigates.

Writing articles that work

• Title it as the question somebody would ask.
• Answer in the first sentence. Background afterwards, if at all.
• One article, one question. A long article covering six things is found for none of them.
• Say what to do if it does not work — that is usually why they are reading.

Keep it current

A knowledge base decays. An article describing a screen that changed eighteen months ago actively damages trust: the reader concludes the whole thing is unreliable and stops using it, which costs you more than never having written it.

Review on a schedule, and delete rather than leave stale. A smaller accurate knowledge base beats a large decaying one.

Use the questions you actually get

The best source of articles is your own support queue. Where a request could have been answered by an article, write the article and link it in the reply — which both answers this person and prevents the next one.

Worked example

A service desk finds a third of its tickets are three questions: resetting a password, changing bank details, and where to find a statement. Three articles, linked from the portal home page, removed most of that volume within a month — and the team now writes an article whenever a question arrives for the third time.

Recommendations

• Write from real questions, not from what you assume people need.
• Title as the question asked.
• Set a review date on every article and honour it.
• Delete stale content rather than leaving it to mislead.

Satisfaction Responses and Call Logging

Two Activity screens that record what happened around a case rather than to it.

Where to find it

Architect Panel → Activity:

• Satisfaction — satisfaction responses
• Calls — call records and what they were matched to
• Correspondence — the written half of the same picture

Satisfaction

Satisfaction responses are captured against the work they concern, so a score is attached to a case rather than floating in a survey tool.

That connection is what makes the data useful. A satisfaction score alone tells you a number. A score joined to the case tells you which service, which team, how long the case took and whether it breached — which is the difference between knowing satisfaction fell and knowing why.

Ask at the right moment

Ask when the outcome is known and recent — at closure, not monthly in a batch. A request arriving weeks later gets a response about the person's general feeling towards you rather than about the work.

Keep it short. One question and an optional comment will be answered; ten questions will not.

Read the comments

The score tells you the temperature. The free text tells you what to change, and it is usually specific and actionable in a way the number never is. If nobody reads the comments, you have built a metric rather than a feedback loop.

Call logging

Calls records the call itself: direction, the numbers involved, when it started, when it was answered, how long it lasted, the agent, and the outcome — matched to the record it relates to.

The match is the valuable part. A call log on its own is telephony data. A call log attached to a case means the case history shows the phone conversation alongside the emails and letters, and a colleague picking it up sees the whole interaction.

Matching, and when it fails

Calls match to records by number, so the same normalisation that matters for inbound messaging matters here. Where a call cannot be matched it is still recorded — decide who reviews unmatched calls, because they are often the ones from a number you do not yet hold.

Using both together

Satisfaction joined to call and correspondence history answers questions neither can alone: whether cases resolved on a first call score better, whether cases with more than three contacts score worse, whether a particular route produces unhappy outcomes. Those are service design questions, and this is the data that answers them.

Worked example

A repairs service asks one question at job completion. Joining responses to call records shows jobs needing more than two calls score markedly worse regardless of how quickly they were completed — so the improvement was not speed but keeping the resident informed without them having to chase.

Recommendations

• Ask at closure, and ask one question.
• Read the comments, and route them to whoever can act.
• Own the unmatched call queue.
• Join satisfaction to case data before drawing conclusions from the score.