[flickr]photo:7769645342[/flickr]
Jesse Bounds talks about the “311 volley” at the last OpenGov Meetup.
Update September 14: One month later and the Service Tracker is now live. Input your SR number and watch its status (hopefully) change.
At the August OpenGov Meetup, Jesse Bounds, developer with Code for America, demonstrated some of the tools to interface with “Open 311” that are available now for many cities around the country to improve city services data collection and presentation. John Tolva, Chicago’s Chief Technology Officer working with Bounds and other Code for America fellows, said that a read and write programming interface for developers will be available “in weeks, not months”.
You can view two of the tools now, but neither show information from Chicago until the launch. They’re part of “311 Labs”: The Daily Brief, and Open 311 Status – both of these are designed for non-developers. Bounds also showed off the “311 Service Request Tracker”, which was designed after shipping company package tracking websites. It shows step-by-step the process for a citizen’s request for service.
Each call to 311 in Chicago is categorized by a type code. For the launch of Open 311, only 14 type codes will be available. “Pothole” and “Street Cut Complaints” will be included. One of the tools Bounds demonstrated is what he calls the “tennis volley”. It shows a call for service coming in, and how it might bounce around to different city departments. The example case was a pothole or sewer cave-in that bounced between the Transportation department and the Water Management department.
I made a call to 311 a couple of days after the meeting, informing the city that all southbound lanes of Milwaukee Avenue south of Ogden Avenue had the pavement cut out, and there was no warning to the harsh bumps on either side and the rough, grooved surface. The grooves can catch bike tires and cause the less experienced to fall. (There’s a lawsuit against the city right now from a crash like that in 2009 on Wrightwood Avenue.) The process for service request #12-01416500 went like this:
- Accepted on August 7, 2012, at 9:59 PM
- Coded as Street Cut Complaints.
- Given to Chicago Department of Transportation, Division of Infrastructure Management, Public Way Management, with the comment, “Traffic Lane – there aren’t any signs”.
- Work was assigned at 4:53 PM the next day.
- The request was closed at the same time work was assigned.
I haven’t returned to the scene in question since then to know if anything has changed (I reported the address as 740 N Milwaukee). All of this information, about all 311 type codes (14 at launch), will be available to the public on a website. The programming interface for developers will give them the ability to create alternative websites and their own apps that read the same information and present it differently, collect stats on speed of service, or build for mobile devices that allow Chicagoans to bypass making a tedious phone call and input the information directly.
do I have this correct, they closed the request when the work was assigned, not when it was completed? If so, I shouldn’t be surprised that the city has no concept of how a customer interaction system should work.
That’s what it appears like, but I can’t say for certain how it appears is an accurate representation of the work actually being done.
This tool will expose many ways on how to improved the processes.
You can already enter and track 311 requests on the City’s website (and a wider variety of requests than the “Open 311” is initially rolling out), here:
http://www.cityofchicago.org/city/en/depts/311.html
However, the City does not currently have a mobile 311 app. That would be a useful addition.
What often happens, particularly during what the article refers to as the “tennis volley,” is that a service request is closed out, and a new service request of a different type is opened. In that case, there would be a new service request number. For example, if someone complains that their sewer drains too slowly, they will open a request for “Sewer Cleaning Inspection.” If the sewer inspector verifies that cleaning is needed, that request will be closed out, and a the inspector will open a new request for “Sewer Cleaining Needed” (or, less commonly, “Sewer Repairs Needed.” I expect that something similar happened with Steven’s request on Milwaukee Ave.
So, the ability to track requests by service numbers is of limited utility. It would be more useful to track by address, so that you could see all successive requests that evolved out of the original one. The system available to 311 operatiors and aldermanic offices offers that capability. However, the system in aldermanic offices only gives the ability to track within their own wards (that is a problem for two reasons: first, issues often cross ward boundaries. Second, the City is in the process of transitioning to a new ward map, but the service tracking system is still based on the old map). The online service request tracking on the City’s website does offer the ability to search by address, but it only shows the most recent request at that address. So, when I entered 740 N. Milwaukee, rather than showing Steven’s sign request, it showed a graffiti report (although it might be useful if some public-spirited tagger put up graffiti warning of rough road ahead, LOL).
One thing that would be very useful in a mobile app would be the ability to point one’s camera at the site of an issue and have the GPS asign an address to the issue. I don’t know how accurate they could make that feature, though. Even Google StreetView has a disclaimer about addresses being approximate. Constituents calling in complaints often guess at addresses, or draw inferences based on their own address (“I’m 4812, and that’s two doors over, so it must be 4816.”) and they are often wrong. This wouldn’t be much of an issue in Steven’s example, where the issue is obvious to anyone going down the street, but there are many cases where precise addresses matter.
Is the new service request linked to the one it “replaces”?
A lot of work is actually being done to ensure that the full “tennis volley” of requests that follow on from the original is shown both on the new website and in the developer interface. In addition, both of them also show a service request as “open” until all the following requests have been completed.
Basically, citizens and developers shouldn’t even need to know about that problem with the new system—it combines them all into one request that covers the whole reported issue.