Local government and community organizations

How work moves in local government and community organizations

The work starts with someone asking. A resident reports a pothole or a broken streetlight. A builder applies for a permit. A business applies for a license. A group asks to use the park or the hall. A neighbor asks when the next council meeting is and what is on the agenda. The request arrives at a counter, by phone, by email, through a web form or in person.

Behind the counter, the request moves between departments: the clerk, public works, planning and building, finance, parks, and often an elected board that has to approve something. Some steps need a review, an inspection, a payment or a public notice. Each has its own deadline set by local code or state law. When it is done, the record is kept for as long as the retention schedule says.

Community organizations run the same shape with volunteers: events to schedule, members to keep informed, a calendar shared by several groups, and a board that approves spending. Small staffs and volunteers carry a large share of the knowledge in their heads.

Where it usually breaks

Requests arrive everywhere and are retyped

A phone call becomes a sticky note becomes an email to public works becomes a line in a spreadsheet. Each copy loses something, and nobody can find the original. That is the re-entry trap.

The public cannot see where a request stands

Once a request is in, the person who asked hears nothing until it is done, so they call. Staff spend their day answering status questions instead of moving requests. That is the invisible queue. See customers hear nothing after the visit.

Approvals wait on meetings and signatures

A permit waits on a reviewer. A purchase waits on a signature. An item waits for the next board meeting, and the packet is assembled by hand. That is approval drag. See email is the approval system.

One person holds the process

The clerk who has been there for years knows how every request type really works. When they are out, the counter stalls. That is the handoff gap, between the person who knows and everyone else. See the business stops when one person is out.

Working inside the rules

Before we arrive on site, we learn the rules the organization's work runs under, and the build is designed inside them. For a public body that usually means the state's public records law and the records retention schedule that applies to it, its procurement rules, open meeting requirements for anything that touches board business, accessibility requirements for anything the public uses, and the organization's own code and policies. A community organization brings its bylaws and its own policies.

That shapes the design before anything is built. Records stay in systems the organization controls, where its retention applies to them. Anything the public uses is designed to be accessible from the start. Every design choice that touches a public record goes to the clerk or attorney who owns those decisions.

Work we have built here

We built Around Here Today, a community board for one small town, Genesee, Idaho: a shared calendar of events, markets and council meetings, a bulletin board for lost and found, garage sales and free items, and directories of local businesses and makers. Only residents with a verified address in town can post, anyone can read, and volunteer moderators run it with every decision logged.

The first workflow we usually look at

Usually the path from a request from the public to a resolved request the person can see was resolved. It happens every day, it crosses the counter and the departments, and its gaps show up as repeat calls, lost requests and staff time spent on status. If permits, board packets or a community calendar cost the organization more, the Spec says so and focuses there.

We sit at the counter and on the phones, follow a set of recent requests through every department they touched, and interview the staff and volunteers who move them.

The systems in the picture

A local government or community organization usually runs some mix of these:

• A finance and utility billing system
• Permitting or code enforcement software, where it exists
• A website with web forms, and email inboxes shared by departments
• Agenda and meeting management, sometimes a shared drive of documents
• Paper forms at the counter and a records room
• Spreadsheets for requests, events, facility bookings and volunteers

What a Workflow Spec looks like here

A Workflow Spec for a local government or community organization is priced by deployment, and takes up to five business days on site. We sit at the counter, ride along with public works, sit with the clerk through a board packet, and interview the staff and volunteers who move a request from the public to resolution. You get the workflow map, the business case, an adoption design built for the staff and volunteers who would use the tool, and a fixed proposal for the build. The answer can be not to build. Details are on how we work.