Selected work

Five service workflows, in context

Each case names its status, review period, sample, and limits. Client and staff identities are withheld. OpenRecords is a concept prototype and has not been deployed.

Pilot•March–August 2026

PermitLite

Municipality in the western United States · ~12,000 residents · names withheld

Permits
Mobile workflow
Staff review

Measurement values and sample sizes are also provided as text.

A six-step mobile workflow for selected small construction permits, with document checklists, status tracking, and a staff review queue alongside the municipality’s existing records system.

Observed results

Follow-up for missing documents: 14 of 34 applications (41%) before, 8 of 39 (21%) after.
Median time to a complete file: 3.6 to 2.4 business days.

How it was checked

Compared two eight-week periods using correspondence logs and records from the staff interface: 34 applications before the pilot and 39 after launch.

Read the full case

The challenge

Applicants worked from a seven-page PDF and emailed or delivered it in person. Staff checked documents, copied information into spreadsheets, and followed up by phone or email when files were incomplete.

Constraints

Small budget and inconsistent mobile connectivity.
The existing records system had no API and remained in place.
Legal approval of permits stayed with municipal staff.

CivicCurrent’s role

CivicCurrent handled process research, experience design, technical architecture, and prototype implementation. Three municipal staff contributed process and infrastructure input.

Delivered

Six-step mobile application with required-field checks and saved drafts.
Photo and document uploads, per-permit checklists, status tracking, and correction requests.
Staff queue with PDF/CSV export, source code, deployment notes, and staff instructions.

Limits and interpretation

The sample is small and does not establish a long-term effect.
The pilot covers selected small works and does not replace the existing records system or the official permit decision.

Pilot•April–July 2026

FieldLog

Rural municipal infrastructure team · four inspectors · names withheld

Field inspections
Offline workflow
Sync recovery

Measurement values and sample sizes are also provided as text.

An offline inspection workflow for a four-person field team, with preloaded assets, saved reports, attached photos, a visible sync queue, and office exports.

Observed results

Four inspectors created 63 reports during a five-week review; 19 began with no or unstable mobile service.
All 63 reports eventually reached the central register; 3 needed a retry.

How it was checked

Sync logs were checked and a sample of reports was reconciled with inspector records during the five-week pilot review.

Read the full case

The challenge

Inspectors used paper checklists, took photos separately, and later copied findings into a shared spreadsheet. Mobile coverage was absent at some sites, and reports and images could be difficult to match to the right asset.

Constraints

The pilot used low-cost Android phones and had to tolerate interrupted connections and repeat sends.
GIS integration was outside the pilot scope.
Infrastructure maps, exact coordinates, and private inspection photos are not public materials.

CivicCurrent’s role

CivicCurrent handled technical architecture, offline workflow design, and mobile interface implementation. Four inspectors and an operations lead took part in the pilot.

Delivered

Offline forms and preloaded asset lists with photo attachments.
A sync queue showing saved, waiting, synced, and attention-needed states, with duplicate-send protection.
Office report view, CSV/PDF export, and recovery instructions for sync issues.

Limits and interpretation

The figures confirm the offline and recovery path worked in this pilot; they do not show lower inspection costs or better defect detection.
Three reports required another synchronization attempt, so the result is eventual delivery rather than first-attempt success.

Launched service•June–October 2025

StreetSignal

Municipal public works department · ~24,000 residents · names withheld

Public works
Issue reporting
Dispatch handoff

A structured mobile route for reporting road and public infrastructure issues, with location and photo details passed into the existing dispatch process.

Observed results

Location clarification: 34% of 148 reports before launch and 14% of 161 after.
Median time to route a report: 2 business days before, 1 after.

How it was checked

Compared service logs for 12 weeks before and 12 weeks after launch: 148 reports in the earlier window and 161 in the later window.

Read the full case

The challenge

Reports arrived through calls, email, and a general contact form. Dispatchers often had to clarify locations, categorize issues, and copy details into a work table; residents had little visibility into receipt or status.

Constraints

The service needed to work on low-cost phones and allow a draft to be prepared without a connection.
An offline draft is sent only after connectivity returns; it is not registered while it remains on the device.
The tool structures information for the existing dispatch system rather than replacing it.

CivicCurrent’s role

CivicCurrent handled product design, the mobile interface, and implementation. A web developer, municipal dispatcher, and field-crew lead contributed.

Delivered

Issue category, address or map pin, photo, and contact details in a structured report.
Local draft saving, image compression, and a confirmation after registration.
Staff queue with categories, filters, statuses, and crew assignment; structured handoff to dispatch.

Limits and interpretation

The measures cover initial handling and routing only; repair time and repair outcomes were not measured.
Reports drafted offline are not submitted until the device reconnects.

Launched service•November 2025–April 2026

WaterStart

Water utility serving ~6,000 households · names withheld

Water utility
Service requests
Staff queue

A mobile-first intake and staff queue for starting or stopping water service, operating alongside the utility’s existing billing software.

Observed results

Requests needing at least one extra phone call: 48% before, 29% after.
Median administrative processing time: 2.1 to 1.5 business days.

How it was checked

Compared two ten-week periods: 62 standard requests before launch and 70 after. Evidence came from request logs, staff call records, and status histories.

Read the full case

The challenge

Residents submitted PDFs by email or in person, then often called to confirm receipt or ask about scheduling. Staff tracked requests in email and a separate spreadsheet.

Constraints

The workflow had to remain separate from the existing billing system.
Payments, identity checks, debt handling, and disconnection decisions were out of scope.
Non-standard cases requiring document review remained staff decisions.

CivicCurrent’s role

CivicCurrent led product and technical work, including process analysis, interface design, and client-side implementation. The utility’s customer-service lead and two request-processing staff contributed.

Delivered

Adaptive intake for service starts and stops, with address, preferred start date, and contact details.
Saved incomplete requests, staff queue, filters, and status history.
Export for manual import into existing systems, plus staff guidance for non-standard cases.

Limits and interpretation

The measures describe intake and administrative handling; they do not measure when water service was physically connected.
Field visit schedules and site readiness remained outside the workflow.

Concept prototype · not deployed•August–September 2026

OpenRecords

Municipal administration · ~9,000 residents · names withheld

Public records
Concept prototype
Usability

An interactive concept for submitting and tracking public-records requests, tested with modeled applicant and staff scenarios.

Observed results

In modeled tasks, 6 of 7 participants completed the primary request-and-status flow without help.
Testing surfaced unclear category labels and status wording for revision.

How it was checked

Seven participants attempted a modeled task: find a document category, draft a request, and check its status. These results describe prototype usability only.

Read the full case

The challenge

Information about public records requests was spread across web pages, PDFs, and email instructions. Residents could be unsure which materials to request and what would happen after submitting.

Constraints

Rules, response times, and retention requirements depend on the jurisdiction.
The prototype does not decide whether a record can legally be released.
It was not connected to municipal systems or used to process real requests.

CivicCurrent’s role

CivicCurrent handled scenario research, information architecture, UX/UI, and the interactive prototype. Staff work was modeled rather than connected to a live service.

Delivered

Mobile request flow with document categories, plain-language prompts, and preferred response method.
Status tracking and a modeled staff workspace with request history.
Journey map, data outline, accessibility requirements, and an initial delivery estimate.

Limits and interpretation

This is a concept prototype, not a deployed public service; it produced no service-delivery outcome.
No real citizen requests, personal data, or internal correspondence are included.

Have a similar process in mind?

Discuss your workflow Read our approach