The public-sector brief is genuinely different
Almost everything written about live chat assumes a commercial motive. Reduce cost per contact, lift conversion, catch the visitor before they bounce. Take that advice into a public service and most of it is either irrelevant or quietly wrong.
A public service does not choose its users. It cannot decide that the visitor who is confused, in a hurry, on an old phone or not confident in the language is somebody else's problem, because that visitor is precisely who the service exists for. It also cannot use the escape hatch every commercial team relies on, which is that a frustrated visitor can go elsewhere. There is nowhere else to go.
That changes the design brief in a specific way: the measure of success is not how efficiently you handled the average contact, but whether the hardest contact got what it needed. Everything below follows from that.
Accessibility is a duty, not an improvement
In most sectors accessibility is a quality goal that competes with other quality goals. In the public sector it is usually a legal obligation with a published standard attached, and a chat widget is part of the service it sits on.
Treat it as procurement criteria rather than a launch-day polish item. Ask for the vendor's accessibility documentation before you choose, and test the widget yourself with a keyboard only and with a screen reader — not because vendors lie, but because a widget behaves differently once it is embedded in your page, with your CSS and your other scripts around it.
- Reachable and operable by keyboard alone, including opening the widget, sending a message and closing it.
- Announced sensibly by a screen reader, particularly the arrival of a new message, which is easy to get wrong and easy to test.
- Legible at increased text size and at high zoom, which is where most embedded widgets fall apart first.
- Not dependent on colour alone to convey state such as online, offline or waiting.
- Not a pop-up that steals focus, which is both an accessibility failure and an ordinary usability one.
Our guide on live chat accessibility covers the testing in more depth. Run it before launch, and again after any redesign of the host page.
Plain language does more work here than anywhere else
Public services carry a vocabulary problem that commercial sites do not: the official name of a thing is often not the name the public uses for it, and the official name is usually the one written into every form and letter.
Chat is unusually good at bridging that gap, because a person can ask in their own words and be answered in yours. Getting the benefit requires the agent to do the translation deliberately — use the citizen's word, then introduce the official term once, and say plainly that the two are the same thing. Answering entirely in official vocabulary is technically correct and practically useless.
Two habits carry most of this. Give the answer before the explanation, because a reader who only takes in the first sentence should still be able to act. And state the next physical step: what to bring, where to go, what the deadline is. A correct answer that leaves someone unsure what to do next has not finished the job.
Where the same question arrives repeatedly, the durable fix is published content rather than a better canned reply — a well-maintained knowledge base answers it at three in the morning too.
Records come first, and they are not an afterthought
In most organisations a chat transcript is an operational artefact. In the public sector it is frequently a record, subject to retention schedules and potentially disclosable under access-to-information law. Deciding that after launch is how services end up with either too little or far too much.
Settle four things in writing before you turn chat on: how long transcripts are kept, who can read them, what happens when someone asks for a copy of their own, and what happens when the retention period ends. The answers are yours to make, but they should exist as a document rather than as a habit. Our guide on writing a transcript retention policy is a reasonable starting template.
The related discipline is not collecting what you do not need. A pre-chat form that asks for a reference number because it might be handy has created a records obligation to save an agent ten seconds. Ask for what the conversation requires, and no more.
This is the single most important boundary, and it is worth stating in exactly these terms to everyone who will staff the service: a chat widget on a public web page does not prove who anyone is.
Anybody can type a name, a date of birth, a reference number or a national identifier into it. Knowing those things is not the same as being that person, and treating it as proof is how a service ends up disclosing someone's details to whoever asked confidently. The volume of information a determined person can assemble about someone else makes knowledge-based checks weaker every year, not stronger.
So draw the line by consequence. General information, process explanations, deadlines, what a letter means, where to go — all fine in an unauthenticated channel. Anything account-specific, anything that discloses personal data, and anything that changes a record belongs behind a channel that actually authenticates: the signed-in portal, a verified phone process, or in person.
Say the boundary out loud when you reach it, and say it helpfully. I cannot see your case details here because this chat is not a signed-in service, but I can tell you exactly how the process works and where to check your own record is a refusal that still leaves the person better off.
The deadline calendar is your volume calendar
Public-service demand is rarely smooth and it is rarely a surprise. Filing deadlines, enrolment windows, renewal dates, benefit changes, results days, severe weather: the peaks are on a calendar somebody in the organisation already has.
Get that calendar and staff against it, rather than against last month's average. The week before a deadline can carry several times the ordinary volume, and it arrives with a harder mix — more anxiety, more edge cases, more people who have left it late and cannot afford a wrong answer.
Two preparations pay for themselves. Publish the deadline answers before the peak, so the routine version of the question is already handled in writing, and pre-write the responses for the situations you know are coming, including the one for people who have genuinely missed the date. That answer will be needed, it is emotionally difficult, and nobody should be composing it live.
Measure resolution, because there is no conversion
Commercial chat has a convenient scoreboard: something was sold or it was not. Public services have no equivalent, and in its absence teams reach for the metrics that are easy to collect — chats handled, average handling time — which reward speed rather than outcome and will, given time, actively make the service worse.
The honest question is whether the person could act afterwards. That is harder to measure and worth the effort: sampled review of transcripts against whether the answer was correct and complete, repeat-contact rate on the same issue, and the share of conversations that ended with a clear next step rather than an apology.
Handling time still belongs in the report, but as a capacity number, not a quality one. A service where the vulnerable contact takes twenty minutes and gets it right is performing well, and any measurement framework that says otherwise is measuring the wrong service.
What to measure
- Repeat contacts on the same issue, the closest available proxy for whether the first answer actually worked.
- Conversations ending with a clear next step, sampled and read by a person. This is the quality measure; the rest are diagnostics.
- Accessibility regressions, re-tested after every change to the host page rather than only at launch.
- Answered share during peak weeks, compared with ordinary weeks, which is where a staffing plan is proved or disproved.
- Boundary refusals — how often agents have to decline an account-specific request. A high number means your signed-in service is not where people expect it to be.
- Transcripts past their retention date, which should be zero and is the cheapest compliance check you will ever run.