Creating an Open Source Resident Reporting Platform — Part 1
Note:An earlier version posted on elgl.org
In this post I’ll discuss one of the longer term projects we’ll be starting to work on — creating an open source resident reporting platform. It’s not yet a technical post, but more of an intro. More technical stuff to follow, soon.
What is 3–1–1?
At the heart of it, 3–1–1 is a type of residents’ hotline for non-emergency matters (for emergencies, residents are supposed to call 9–1–1). Residents report issues like missed garbage pickups, defaced signs, water breaks and clogged catch basins (better known as sewer grates). For more details about what 311s are, many documents exist. Essentially, it is a centralized interface to report all kinds of issues that the local government might want to fix or at least acknowledge.
In addition, with more and more residents getting online, there are more and more ways available to report issues to the city, from web forms on the website, to apps, to text messages and even instant messaging chats, and of course the traditional way of just calling a hotline.
The benefits of having a centralized platform for reporting and handling issues are plentiful: happier residents who have easier access and better tracking of their requests and hopefully shorter response times, a better way to allocate resources to burning issues and anticipate requests, simpler processes for employees (hopefully), and a lot more transparency and accountability for everyone.
So why doesn’t every jurisdiction have a central way to report issues?
In short, current implementations consist of a lengthy project to map most processes of how current issues are being handled, implementing a CRM (customer relationship management platform such as Salesforce, Dynamics365 or GovQA) and managing change both internally (having a centralized system changes how most departments work, and creates more accountability which can be intimidating when not enough resources exist) and externally, to residents, who either “know someone at City Hall” or just don’t know who to contact.
In addition, this is usually a lengthy process (18–24 months) which requires a lot of buy-in, a lot of planning and a decent amount of money, and mostly — a lot of change management, since implementing requires examining almost every resident originating workflow, and many internal workflows. This means that most jurisdictions will need lots of conviction to embark on this process, and even when they do, it sometimes doesn’t succeed.
How can we democratize 3–1–1?
I’ve been thinking about this question for a long time, and I pledge to write more about this soon, but I think providing access to a modular, extensible, open source access to a resident reporting platform is a good way to do just that. Over the next few weeks to months, my team and I will be releasing a series of open source modules that will eventually form a basic resident request reporting and handing platform, that any local government could extend to make their own. We will build on existing standards including the open311.org schema and popular open source libraries.
We are hoping that the fact that the platform will be easily deployable, and contain an extensible schema for everything from user details to workflow management and task handling, will enable many more jurisdictions to contemplate implementing such a platform, and add on top of the existing modules, other ones that that they deem worthy adding based on their local needs (e.g. want to plug in a Facebook Messenger app to support reporting via chat? you’ll be able to hire someone to do so!).
So, what do we hope to be building?
A picture is worth a 1,000 words, but we hope to build a basic version which includes:
- A basic input mechanism (e.g. a web form)
- A simple schema based workflow management module (assigning different tasks to different people/departments) which supports both requests and questions
- An intake model (an employee queue of unresolved requests)
- Simple statistics (e.g. how many requests were issues, how many were resolved and how quickly)
- A way for a residents to track their requests
and all of these would be governed by a schema that can be extensible. At least, these are our current thoughts.
Why are we doing this? and why go open source?
We love local government; and at the core of what Zencity does lies the hope that when local government listens to public feedback when making day-to-day decisions and policy, public trust increases which leads to a positive cycle of feedback and improvement of quality of life. We think a “3–1–1” or a good resident request platform, is essential for residents as an equitable way to ask questions, request service and improve the quality of their life in their city or county, and for a local government to assess the quality of service its providing.
By making the “internals” of 311(e.g. the schema that codifies every workflow, interaction and department, and any integration and service which connects as an input or output) modular and based on a simple format (like JSON or YAML), we hope to ease implementation and allow, for example, a single department to adopt the platform and then add additional departments when they see value.
Lastly, we think this is quite a big challenge — there can be many inputs, many interesting problems (e.g. translating locations between Google and ESRI, de-duplicating similar requests, providing feedback to the resident if input is flawed, to name a few) so building it in the open will enable everyone to provide feedback, or even better, contribute code, to the effort.
Exciting stuff!
Interested in helping out?
We’re just taking our first baby steps, so if you’re interested in helping, have feedback or want to be a beta tester, drop us a line here:
Or send me an e-mail here: 311project@zencity.io.
