Meet GovFlow: an open, digital-first ticketing platform for local governments
Image: a historic rope making machine, or a workflow from 1911, image credit below
What I’m Reading: Shoe Dog by Phil Knight, a memoir about a 24-year old boy from Oregon that built the Nike empire
What I’m Listening to: pocket animals (Hebrew), a podcast about economics and everyday life
What I’m Watching: Ozark (S2), a TV masterpiece in my very humble opinion
A while back, I wrote that we’re embarking on a journey to democratize 3-1-1, or resident requests. Since then, we have been building GovFlow, an open source, digital first ticketing platform tailored to fit local government workflows. In the last few months, building, talking to local government servants, and learning along the way, most profoundly from our first city partner, the City of Williamsburg, its CIO, Mark Barham and his team.
As with most early products, what we set out to build changed quickly in the face of user feedback. What have we found out? Consider the following (anonymous but very real) quotes from conversations with a few jurisdictions:
“For each public work request that comes through our 3-1-1 system, a public works employee then copies and pastes the request details to our internal public works work order system”
“Every non-emergency request that is logged in our police dispatch, we send it in email form to the Police Chief, the Chief’s assistant, and the officer on call, and we ‘sort of’ do an informal triage to see who is going to respond and how”
“The Parks Department has two team members: one of us receives and responds to requests and questions through department’s Messenger, and both of us answer email requests, but we’re not tracking what’s been answered, and sometimes things get lost”
What happened? essentially, we initially set out to build a product that focused on the best resident request experience, but discovered that there are numerous challenges in the internal workflows for handling a ticket once a ticket (a request or an inquiry) is submitted by the resident and as it’s handled by different people and in departments until it’s resolved. The quotes above are mere examples, but we found out this is where the main complication lies, and therefore where the main benefits of making internal workflows manageable from one place, save time for local government staff, and allow management to have a unified view of what’s going on. We even named the product we’re developing GovFlow, to emphasize how important it is for us to get this right.
So, while we continue add ways for residents to create tickets in more and more ways, through web and mobile-friendly forms, chatbots (through an integration with citibot.io) and even emails, with more methods coming soon, we’ll be emphasizing the creation, customization, management and tracking (both to residents and government employees) of ticket workflows, and making local government more responsive, and therefore more trustworthy, to residents. For example:
- GovFlow staff users will create workflows, or different “journeys” for a ticket between departments (e.g. a request for a code enforcement issue may drive and inspection by one department and an issue of notice by another), which can be visualized and tracked
- Residents will be able to track where their request is at, and if shared by the jurisdiction, get an estimation of how long it usually takes for a request to be resolved
- Local government management will be able to view where requests get “stuck” and tweak resources – or the process – to make processes more efficient.
We’re still only getting started and are working with our first cohort of 3 cities and counties, and are looking for more forward thinking jurisdictions to work on GovFlow with us. Want to learn more? We’re looking for collaborators and design partners here: https://govflow.org/contact/