Public & local communities

Everything in this sector starts from an obligation to the people of a defined area. A council has to tell residents when it meets, what it decided and how to take part; a community office has to say what is on and when the door is open; a neighbourhood group exists so that the people of a few streets can hear each other; a housing or estates team has to take the request about the broken light and say what happened to it; a destination body has to tell visitors what is open this afternoon. None of these organisations can pick their users, so the systems they run have to work for everyone: the councillor on a tablet, the clerk on a desktop, the resident with one bar of signal and the visitor who has never been before. Plain language and accessibility are therefore design constraints from the first screen, not a review item at the end.

The second shared fact is that these organisations publish on a cycle and must be able to show what they published and when. Agendas go out before meetings, minutes after approval, consultations open and close on dates, notices expire, service pages change their opening hours, and place listings go stale. The systems we build give every published thing a record: a publication date, a version, who changed it and whether it has been verified or made accessible. Statutory publication duties, freedom of information requests and accessibility regulations are met by the organisation and its advisers; the system gives them the record to meet them from and a design that targets WCAG 2.2 AA, without claiming the duty itself is discharged.

Third, the work arrives as requests from residents and has to be routed. A hall hire, an advice appointment, a report of fly-tipping, a question about a planning notice, a correction to a listing: each needs to be categorised, placed on a map or against a building, sent to the person or team that owns it and tracked to a status the resident can see. Duplicate reports, visits that have to be arranged, contractors who work in their own systems and residents who want to be told what happened are the everyday shape of that work, and the organisation's own service standards are the targets the system reports against.

Finally, the sector lives on volunteers, small teams and partners. Clerks, coordinators, moderators, verifiers and committee members hold roles with narrow permissions and change often, so every system needs roles that match the real jobs, a log of who did what, and data that can be exported when the person or the provider changes. Money moves in small amounts for hire, rents, listings and charges through a payment adapter and is reconciled in whatever accounting package the organisation already uses. Each topic in the sector then adds its own shape: the council's meeting cycle and facility hire, the community office's timetable and volunteer shifts, the neighbourhood portal's verified residents and moderation queue, the request system's routing and target reports, and the city guide's editorial review and open-now map.