Tomorrow in New York City, developers, project managers, public policy specialists and others will come together to discuss an open standard specification for 311 services. One of the primary motivators for this discussion is the work that has been done by the District of Columbia which has deployed an open API for reporting 311 requests.
The idea behind the Open311 project is that both citizens and government are better served by having a uniform standard for 311 API’s like the District of Columbia. An open standard will better facilitate the development of applications and services that make submitting 311 requests easier and more convenient for citizens, and more cost effective for governments. From the Open311 website:
Open311 is not meant to refer to a specific app or any one incarnation of 311 services. Instead Open311 intends to be a specification of an open platform for 311 services…Once this core standard is defined, new user interfaces and custom workflows can be created by anyone and shared between cities to provide distributed innovation.
To help understand where 311 service may go because of efforts like Open311, or even more independent efforts to deploy 311 APIs, it helps to understand how 311 services operate today.
311 Today
Most municipal 311 services are centered around a call center operation. The call center is staffed with personnel that a citizen can speak with to report an issue. 311 Call center personnel are trained and typically have a predefined script that they use when interacting with a caller. This script ensures that they collect all required information from the caller and enter it into the 311 system.
Like many call centers, 311 centers may utilize some limited routing logic or an ACD to send a citizen to a specific agent or group of agents based on the issue they want to report. Also, like most call enters, the largest cost component (or certainly one of the big ones) is likely to be labor costs. There are other costs worth noting as well, some of them borne by citizens – like the cost of waiting in queue when all agents are occupied with other callers.
Interestingly, if you look at some of the details of the responses from the DC 311 API, you can see the call center roots of this service pretty clearly.
This is the response from the DC 311 API for the abandoned bicycle service type. You can see that this response shows many of the elements you would expect to see in a call center script, including prompts and the characteristics of the data entry fields the agent would use.
311 Tomorrow?
By deploying a 311 API, municipalities can encourage the development of new applications and different interfaces for submitting 311 service requests. This benefits citizens because there will potentially be more options to use when they need to contact 311. It can benefit governments because it can facilitate the submission of 311 requests without the need for one of the most cont-intensive components – 311 operators. Governments might also benefit from better information when requests are submitted – 311 applications that run on location-aware devices can easily submit geographic coordinates that may be more precise than an address spoken by a person.
A good example of the kind of innovation that can be fostered by deploying 311 APIs is the winner of the most recent round of the Apps for Democracy Contest — Social DC 311 — a combination iPhone/Facebook application.
But with all of the potential for new applications and slick new interfaces for 311 services from the advent of 311 APIs and the potential development of an Open311 standard, there is another (less obvious) platform on which innovative, cutting edge applications can be developed.
The ordinary telephone.
Why Phones Matter
Simply stated, phones matter in providing government services because almost all citizens have them (landline telephone penetration rates are somewhere close to 95 percent nationally, and cell phone penetration rates are at about 85 percent). Moreover, almost all citizens that have them understand how to use them, and have some experience navigating IVR or touch tone menu systems. There is no learning curve to ascend before a service request can be submitted.
Telephones are the most ubiquitous communications device on the planet, and they do not suffer from the uneven distribution rates of other consumer communications products. 311 service was built around the telephone, so its a natural interface for new applications.
As stated above, there are plenty of examples of 311 systems that use some automation through IVR and other technologies to route calls to agents. But, at the end of the routing process, a citizen talks to an agent and gives information about a service request to another human.
There are enormous efficiencies that could be gained by being more aggressive with IVR-based automation. Admittedly, not every call (or every caller) is right for an IVR system – that’s OK. One of the things IVR systems do is help entities more appropriately allocate scarce resources. Citizens that can serve themselves will do so using an IVR. Those that can’t (or won’t) will drop out to an agent and submit their request the old fashioned way. The finite number of agents on hand to take calls get focused on “high need” callers that require human assistance.
Back To The Future
As I stated in a previous post, there has simply never been a more varied and powerful array of tools available for developers to build phone applications than exists today. Open standards and open APIs (like those listed below) have removed the barriers between phone application development and traditional web development. What’s even more exciting is the potential introduced by the increasing ubiquity of VoIP, which is blurring the lines between traditionally telephony and other communications channels.
Governments don’t need expensive proprietary software or hardware, or a team of highly trained developers to build and deploy a high-volume IVR phone application. With choice has come ease of use and downward pressure on costs. Some of the newest and most innovative platforms around for building phone applications are listed below:
Want to build a portable phone app that conforms to open standards from the W3C? VoiceXML and CCXML are your ticket – these standards are supported on a large (and growing) number of platforms.
Want to build an open source solution that leverages your in house skills in PHP or Ruby? Stand up an Asterisk server and get cracking with PHPAGI or Adhearsion.
Need to connect to the PSTN but don’t want to invest in expensive specialized hardware? Call up a VoIP provider and deploy some SIP trunks.
The sea change in telephone application development over the last several years means more developers have the skills and tools to build sophisticated phone applications. It also means that government need not be locked into any one platform or vendor that has unique expertise in phone systems.
As the Open311 dialog moves forward, and as more and more municipalities begin deploying 311 APIs, it will be interesting to see what develops. Whatever awaits those of us that are interested in what is to come, I hope that there will be some phones involved.
Civic Innovations 
Leave a Reply