How a local council answers every call with a voice agent

The enquiry backlog every council knows

Local government runs on enquiries before anything else. A mid-size council fields tens of thousands of phone calls a year, and the mix barely changes. When is my bin collected. When are my rates due. How do I lodge a development application. Who do I call about a fallen tree. The questions repeat, the answers already exist, and the cost sits entirely in the asking.

The volume is not steady. It spikes the week a rates notice lands, the morning after a storm, and the day a collection run changes. Those are the moments the contact centre can least afford the load, so hold times stretch, voicemail fills, and residents give up and email the same question instead. Staff spend the day on calls a good FAQ could answer and have less time for the work that needs judgement, such as a hardship arrangement or a complex permit.

Most councils have tried a chatbot and most have switched it off. The old menu-driven systems could not understand a question asked in a resident’s own words, could not tell two collection zones apart on the same street, and gave wrong answers the moment the underlying information changed. A public-sector assistant has a high bar to clear. It has to be accurate, it has to know when it does not know, and it has to handle personal information under the Privacy Act 1988 and the relevant state privacy and records legislation.

A voice agent, grounded in the council’s own information

The version that works is a voice agent on the phone line, answering in natural speech, backed by retrieval-augmented generation (RAG) so every answer comes from the council’s own approved content rather than a model’s guess. The resident speaks normally. The agent understands the request, retrieves the right passage from the council’s published material, and reads back a plain-language answer. Anything outside its scope goes to a person.

RAG is the part that earns the trust, so it headlines the build. Rather than train a model on council data, which drifts out of date the moment a fee or a collection day changes, the agent retrieves from a live index of approved sources. Update the source and the answer updates with it. The supporting pieces sit around that core. A speech layer handles speech-to-text and text-to-speech on the call. A language model turns the retrieved passage into a spoken answer within tight instructions on scope and tone. The whole service runs on Microsoft Azure in an Australian region, so resident data stays onshore and the agent receives only the context needed for the call in front of it.

The scope is deliberately narrow. The agent answers information requests and triages everything else. A payment dispute, a decision, a hardship case or a complaint is routed to a person, with the call summarised and the resident’s verified property details attached so nobody has to start again.

Building it, and where it got hard

The model was rarely the hard part. The friction lived at the edges, and two examples stand in for the rest.

The first was the address itself. Spoken street names are hard. Callers run words together, accents vary, and a quiet line turns one street name into three different guesses. An agent that mishears the address retrieves the wrong information with total confidence, which is the worst way to be wrong. The fix was to make the agent confirm before it answered. It reads the address back, waits for a yes, and on a second failed attempt hands the call to a person rather than press on. Confirmation cost a few seconds and removed a whole class of confident errors.

The second was grounding. Early in testing the agent answered bin-day questions correctly for most addresses but got them wrong for a cluster on a boundary street, where two sides of the road sat in different zones and a few new subdivisions were not in the waste system yet. The answer was better data and a humbler fallback, not a cleverer prompt. We resolved each caller’s address against the authoritative property dataset, used that to pick the correct zone, and set the agent to admit when a match was missing or stale and offer the right team instead. We handled the daylight-saving and public-holiday shifts that move collection days too, because those are exactly the days people ring about.

Two constraints shaped the rest. The records system enforced strict rate limits, so lookups were cached and batched instead of called on every turn. And because every call is a potential public record, personal details are stripped before any transcript is stored, which kept the deployment aligned with the council’s privacy and records obligations and with frameworks such as the NSW AI Assurance Framework.

What changed

In a representative deployment the voice agent handled close to two thirds of inbound calls end to end, covering bin days, rates dates, form lookups and the who-do-I-call questions without a person touching them. Roughly one call in four came in outside business hours, which the council had previously met with a voicemail box. When the agent did escalate, it passed a written summary and the verified property details, which cut the repeat-question loop and brought down handling time on transferred calls.

These figures are illustrative. They describe the pattern we see rather than a published result for a named council. The shape is the point. The routine, after-hours and boundary-case load comes off the contact centre, the team gets its day back for the work that needs a person, and residents get a straight answer when they ask for it, in their own words, from the council’s own information.

Where this fits

A citizen-services voice agent is one application of our AI Agents service, built on a retrieval-augmented core, for the realities of Australian local government. It is a contained, high-volume, low-risk problem that a voice agent is genuinely suited to, and a sensible first step before anything more ambitious. If your phone line is wearing the enquiry load, the place to start is to map your highest-volume calls and decide where a person must stay in the loop.