Most city halls now call themselves digital. Few are. The difference shows up in a handful of tests a resident can run in an afternoon: can a permit start and finish online, can a records request be filed and tracked, and does the website work on a phone. This checklist turns those tests into a sequence you can run, service by service, with notes on what each result actually means.
The method matters more than the score. A glossy homepage can sit on top of a process that still ends in a paper form and a trip to the counter. The reverse is also true: a plain site with a working payment flow delivers more than a redesign with no back-office change. What follows measures the second thing, not the first.
One caution before the list. Jurisdictions differ in what state law lets them put online, so a missing feature is not always a failure. Some records, for instance, are exempt from disclosure in ways that shape what a portal can show. Where the law constrains the service, the checklist says so.
What should you test first?
Start with the service residents use most: permits and licenses. Pick one common transaction, such as a building permit or a business license, and walk it end to end as an applicant would. The question is not whether the city has an online portal but whether the transaction can complete without paper, an in-person visit, or a payment method the portal does not accept.
Note three things as you go. First, whether the application can be submitted in full online. Second, whether status updates are visible to the applicant, or whether the process goes silent after submission. Third, whether the fee schedule is published before you pay. A portal that hides its own fees until checkout is a design choice worth flagging in a public comment or a council meeting.
Can you file and track a records request?
Public records laws generally entitle residents to request government documents, and many jurisdictions now accept those requests through online portals. The test here has two parts. Can you file the request without knowing the name of the right department? And once filed, can you see where it stands?
The second part is where most systems falter. A portal that accepts requests but offers no status view leaves the resident guessing about deadlines and completeness. Our analysis of how these systems behave suggests the tracking view is the honest indicator: if the city can see the request's age and the resident cannot, the asymmetry tells you something about priorities. For a deeper look at the failure points, see FOIA Portals: Where Requests Actually Stall.
Does the site survive a phone?
Open the site on a mobile phone, not a desktop browser. A large share of residents reach government services this way, and a site built desktop-first tends to fail in predictable ways: tables that require horizontal scrolling, PDFs that will not render, forms whose calendar pickers do not respond to touch.
Run two specific checks. Load the payment page for a utility bill or permit fee and confirm it completes on the phone. Then open any document the site requires, such as a code or an application form, and confirm it is readable without downloading a special viewer. If a step forces a desktop, that step is the bottleneck, and it is worth naming in a service complaint.
Website quality is not cosmetic. Poor structure, broken search, and content that reads like internal jargon are recurring reasons residents give up before finishing a transaction, a pattern examined in Digital Services: Why Government Websites Fail and What Actually Fixes Them.
What does the login ask of you?
Identity is the quiet gatekeeper of digital services. Check what account a resident needs to transact business: a site-specific username, a third-party commercial login, or a shared government identity service. Each choice has consequences for who can actually use the service and how much data is collected to prove who you are.
The direction of travel in government is toward shared identity systems, so that one verified account works across agencies instead of each office issuing its own. The trade-offs, and the slow pace of adoption, are covered in Login.gov: One Government Login, Slowly Multiplying. On your checklist, note whether the city forces a new account for every department. Redundant registration is a sign of systems procured separately and never joined.
Can you see whether the city fixed the problem?
Service-request reporting is the most visible slice of civic tech. Many cities accept reports of potholes, missed collections, and broken streetlights through a phone app or a web form built on open 311 standards. The checklist question is not whether the app exists but whether outcomes are visible: does the resident learn the request was closed, and can the public see aggregate data on response times?
Open request data turns an individual complaint into a public record of performance. Where a city publishes it, residents and council members alike can compare neighborhoods and spot backlogs. The mechanics are explained in Open 311: How Cities Track Whether the Pothole Ever Got Fixed.
Practical steps: running the audit
Work the list in order and record what you find. The sequence matters because early items establish context for later ones.
- Choose one high-volume transaction, such as a permit or license, and attempt it fully online. Record where the process breaks.
- File a routine records request through the portal. Note whether a status view exists and what it shows.
- Complete a payment on a phone. Note any step that requires a desktop, a printer, or a mailed check.
- Create the required account. Note whether one login works across departments or each office issues its own.
- Check whether service-request outcomes and response data are published, not just accepted.
Then take the findings somewhere they can act on them. A written comment to the council committee that oversees technology, or a question during a public meeting, puts the specific failure on the record. Public-meeting access rules now shape how and where that input happens, as covered in Public Meetings Online: What Open-Meeting Laws Now Require. Broader arguments for modernization, and the reform framing behind them, sit in the publication's reform coverage.
What a checklist can and cannot tell you
The audit establishes what a resident experiences. It does not establish why. A failed payment flow might reflect a stalled procurement, a vendor contract with weak service terms, or a statute that requires an in-person step. Those causes live in budget documents, contract records, and council minutes, which in most jurisdictions are public.
That is the useful limit of the exercise. The checklist gives you the specific, dated observation; the public record gives you the mechanism behind it. Pair the two, and a complaint stops being anecdote and becomes a documented case a council member can act on. What remains unknown after any single audit is trend: whether the service is improving or sliding. Repeating the same tests once or twice a year, with the same transactions, is the only way to see direction rather than a snapshot.
