The pothole reported three times: council requests that vanish into an inbox

A resident reports a pothole. Weeks pass, nothing happens, so they report it again, a bit more annoyed. Still nothing, so the third time they ring the councillor. From the outside it looks like the council doesn’t care. From the inside, the first report landed in a general inbox, the second went to a form nobody monitors closely, and the third finally reached someone who could act, by which point the resident has decided the whole council is hopeless. Nobody was negligent. The request just had nowhere reliable to go.

That’s the actual problem worth solving in council service requests, and it isn’t a chatbot. Council teams field everything, roads, waste, parks, animals, facilities, planning, rates, venues, complaints, a person ringing with a local question, and a lot of it lands half-finished with attachments and a history three years deep. For a mid-sized regional council that’s tens of thousands of contacts a year across phone, email, forms, the counter and social media. The job is to make sure a request routes itself to the right team the first time, that the resident can see it’s alive, and that what happened leaves a record that stands up later. Automation helps with all three, but public-sector work needs more care in the design than most vendors let on.

Triage first, and consistently

Triage is usually the place to start, because it’s where requests get lost. A system can classify what comes in, flag what’s missing, send it to the right team, and open a record. AI is good at this part, because residents describe a blocked drain or a stray dog in their own words, not in your internal categories, and reading free-text and attachments to work out what a request actually is happens to be exactly what the technology does well.

Take one real-shaped example. To the resident, “there’s a dog rushing the fence on the school route and it’s going to bite someone” is one problem. Inside the council it could be animal management, compliance, or a safety escalation, depending on the history at that address. A triage layer that reads the sentence, checks prior reports and routes the request with that history attached has done in seconds what otherwise waits for whoever clears the inbox after the morning rush. And it does it the same way at 4:45 on a Friday as it does on a quiet Tuesday, which no rushed human sorter can promise.

What it must never do is bluff through something sensitive or disputed. When it isn’t sure, or when the matter is a complaint, a legal question or a safety issue, it hands the request to a person and stops. A triage tool that guesses confidently on the wrong request does more damage than the general inbox it replaced, because now the wrong routing carries the council’s authority. Consistent, cautious classification with a human catch for anything fraught is the whole design.

Close the loop, because the silence is the complaint

The reason the pothole got reported three times is that the resident never saw the first one move. Silence reads as neglect, even when the work is quietly scheduled, so the single highest-value thing a request system does is show the person their request was received, classified, and is being handled. Half the repeat contact and a good share of the frustration comes from people who can’t tell whether they were heard.

Ask the customer service team how much of their day is people chasing requests they’ve already lodged. In most councils it’s a big slice of the phone queue, and every one of those calls is staff time spent answering a question the system should answer on its own. There’s a quieter cost too: the officer taking the third call about the same pothole usually can’t see the works schedule either, so they apologise blind, and now two people are frustrated instead of one.

This isn’t about a fancy resident portal on day one. It’s about the request having a real status that someone, staff or resident, can actually see, so “did anyone get my report?” has an answer that isn’t a phone call. Get that right and you cut the repeat requests, the councillor escalations, and the background hum of a community that thinks nobody’s listening. It changes how the fix lands, too. A pothole repaired three weeks later with a short closing note reads as slow but honest. The same repair with no word back reads as luck.

The storm weekend is the stress test

Requests don’t arrive evenly, and the design has to assume the burst, not the average. A summer storm goes through on a Saturday and by Monday morning there are a few hundred new reports: trees down, roads cut, a lifted roof at a community hall, and the same six blocked drains reported forty different ways by forty different residents. A general inbox turns that into a week of manual sorting at exactly the moment the outdoor crews need a clear, prioritised list, and two staff can lose the whole week just working out what’s already been logged.

A decent system clusters the duplicates, so forty reports of one fallen tree become a single job with forty people to notify when it’s cleared. It pulls the safety items to the top. And it answers the repeat reporters automatically with a reference and a status, which frees the phones for the calls carrying new information. Weather is the obvious burst, but rates notices going out, a contentious development application and a water outage all do the same thing to the queue. Build for the Saturday and the ordinary Tuesday looks after itself.

Answers from approved sources, with the receipt

When staff answer a request, the answer has to come from approved, current sources, policies, procedures, public pages, local laws, service standards, and a knowledge assistant can get them there faster as long as it shows where each answer came from. That source trail isn’t a nice-to-have. Staff need to know whether they’re reading a current document, an old file someone forgot to retire, or a public page that’s overdue for review, because a confident answer from a superseded policy is how a council ends up committed to something it changed two years ago.

And keep internal and public use separate. An internal assistant can dig through documents and request histories residents have no business seeing. A public one needs a much narrower source set, firm handoff rules, and clear limits, with permissions enforced in the retrieval so a member of the public can’t coax out a private record with a cleverly worded question. Start internally, prove the source quality, then look at public use for a few tightly scoped topics. We’ve gone deeper on how council assistants go wrong and how to scope them if that’s the next question on the list.

The record protects the council eighteen months on

Every service request should leave behind a record you can actually use: who lodged it, what they provided, how it was classified, who handled it, what was decided, and what evidence sat behind that decision. Automation strengthens this by making the key fields required and logging workflow events on its own, so the record doesn’t depend on someone remembering to write it down at the end of a flat-out week.

That record matters most when a decision gets questioned long after everyone’s memory of it has faded, which in local government it will be. When a resident claims the council ignored three reports about a drain before a flood damaged their shed, the difference between a week of inbox archaeology and pulling the full trail in a minute is the difference between a defensible position and an apology. The request system is quietly building the council’s evidence file every day, or it isn’t building anything.

Start with one request type, not a transformation program

Don’t begin with a platform decision or a program of work. Pick one request class with real volume and repeat handling: waste, roads, parks, facility bookings, animal management. Map how it actually works today, including the exceptions and the workarounds staff won’t volunteer in a workshop, then build the triage and routing around real examples the team already recognises. One request class done well buys the trust to do the next one; a stalled council-wide program buys a review nobody reads. And wire it into the systems the council already runs, the works orders, the asset register, the records system, because a request tool that doesn’t connect to the actual work is just a tidier version of the inbox it replaced. Most of this is automation and integration work, with AI doing the one job it’s suited to at the front door.

Faster access to their own information, requests that route themselves, and records that hold up under review: all of that is buildable now, and it’s engineering, not a weekend chatbot. If residents are reporting the same things twice, tell us which request type causes the most repeat contact and we’ll start there.