Public sector forms citizens can actually finish

Most residents only interact with local government when something is broken, missing or overdue — a pothole, a bin, a permit. The form is often their entire experience of the council. If it asks for a reference number they don't have, or times out after fifteen minutes of typing, the call centre gets the complaint instead.

Public sector forms carry a duty the private sector doesn't: they have to work for someone on an old phone, a shared library computer, or a screen reader, and they have to produce a record that survives a freedom of information request. Start with the process the form feeds, not the form itself — where does this data land, who owns follow-up, and what does the resident see while they wait.

Design for the follow-up, not just the submission

A request form that vanishes into an inbox is worse than no form at all, because it creates the impression something is being done. Before building any of the forms below, settle three things:

• A reference number on every submission, shown on screen and emailed, so a resident can quote it when they call. - A realistic timeframe, stated plainly ("most requests are actioned within 10 working days") rather than a vague "we'll be in touch". - A routing rule that sends the request to the team that owns it, not a shared mailbox that depends on someone forwarding it correctly.

The core forms most public bodies need

1. Citizen service request

The catch-all for potholes, missed bins, streetlights and fly-tipping. Ask for the issue type from a fixed list, a location (map picker if you can, free-text address if not), and a photo upload — a photo of a pothole does more than three paragraphs of description. Avoid asking for a case category that only staff would understand; use plain language a resident would choose.

2. Permit application

Whether it's a street works permit, a market stall licence or a skip permit, the common failure is asking for supporting documents before explaining what's required. List the documents needed at the top of the form, before the first field, so someone without their insurance certificate to hand can go and find it rather than abandoning halfway through. Fees, where they apply, should be shown as an amount before payment, not as a surprise on a later invoice.

3. Public records request

Needs to work for someone who has never heard the phrase "freedom of information". Ask what they're looking for in their own words, a date range if known, and a preferred format for the response. Set clear expectations on statutory response times and what happens if the request needs clarifying — routing an incomplete request back to the requester automatically saves a phone call.

4. Community incident report

Distinct from a general service request because it may involve personal safety, antisocial behaviour or a hazard needing urgent attention. Include an urgency flag that changes the routing — an "immediate danger" answer should surface guidance to call emergency services rather than wait for a form to be reviewed. Allow anonymous submission where your policy permits it; some incidents are only reported when the reporter isn't named.

5. Public consultation survey

The form that shapes a policy decision needs to be genuinely accessible: plain language, no double-barrelled questions, and an option to respond by theme rather than forcing a single overall rating. State clearly how responses will be used and when a summary will be published — residents are more likely to respond to a consultation that visibly closed the loop last time.

6. Quick council report

A stripped-down version of the service request for the most common single issue your council handles — often a pothole or missed collection. One screen, one photo, one location, submit. Speed here matters more than completeness; it exists to catch the resident who would otherwise give up and phone.

Accessibility and record-keeping aren't optional extras

Public sector forms are usually held to a formal accessibility standard, and meeting it well takes more than adding alt text after the fact: clear labels, logical tab order, sufficient contrast, and forms that work without a mouse. Keep every submission logged with a timestamp and reference number, and be explicit in a privacy notice about how long personal data from a request is retained — residents reporting antisocial behaviour or making a records request are entitled to know.

A quick checklist before you publish

• Does every submission generate a reference number the resident sees and keeps? - Is the expected response time stated in plain language? - Does the form route automatically to the team that owns the issue? - Can someone complete it without a mouse, using only a keyboard or screen reader? - Are supporting document requirements listed before the upload field? - Is there a clear path for urgent or safety-related reports?

Get those right and the form becomes the thing that actually reduces inbound calls, rather than another channel feeding the same queue.