How to evaluate 311 and service request software

What the software does

311 and service request software takes in residents' non-emergency requests, such as a pothole, a missed collection or a broken streetlight, gets them to the department that does the work, and tells the resident what happened. The hard parts are rarely the intake form. They are location, duplicates, the hand-off to departments' own work systems and closing the loop with the resident. This guide sets out what to ask and test, and names no vendors.

A service request system, often called a 311 CRM, usually covers:

• Intake from several channels: phone calls taken by agents, a web portal, a mobile app, email, and sometimes text or social media messages to official accounts.
• A service catalog of request types, each with its questions, owning department and target response.
• Location: placing each request on the map and validating it against the jurisdiction's address and boundary data.
• Duplicate handling, so ten reports of one pothole become one piece of work.
• Routing to a department or crew, either as work in the 311 system or as a work order in the department's own system.
• Status updates to the resident, and a record of each request's history.
• Knowledge base and reporting for agents, supervisors, performance staff and elected officials.

Who should be on the evaluation team

• The 311 or customer service manager, and agents who take calls every day.
• Dispatchers and supervisors from the departments that receive the most requests, such as public works, sanitation, transportation and code enforcement.
• A field crew member, to test closing requests on a phone.
• GIS staff, who maintain the address and boundary data the system depends on.
• IT, for telephony, work order and identity integrations.
• Performance or budget staff, who report on the data.
• A council office, if council staff submit and follow requests for constituents.
• The ADA coordinator or accessibility lead, and whoever owns language access.
• Records management, for retention and public records requests.

Questions to ask and things to test

• Duplicates across channels. Report the same pothole by phone, web and app. Does the system suggest a match, and who decides whether to link them?
• Hand-off to departments. Route a request to a department that uses its own work order system and follow it there and back. How do status changes return to the 311 record, and how quickly?
• Closing the loop. Close a request as a crew member on a phone. What does the resident receive, and in which channels?
• Location. Test difficult addresses from your own GIS: new subdivisions, intersections, parks, unincorporated pockets and points near the jurisdiction's boundary.
• Districts. Ask a council aide to find open requests in their district without help.
• Privacy. Check which roles can see a resident's name and contact details, whether residents can report anonymously, and what appears on any public map or open data feed.
• Accessibility. Ask for an accessibility conformance report for the resident-facing web and mobile app, and test them with a screen reader and keyboard only.
• Languages. Ask which languages forms and messages can be offered in, and who provides the translations.
• Open interfaces. Ask whether the system offers an Open311 GeoReport v2 interface or another documented API, and what it exposes.

Limits to probe

• Not 911. A 311 system is not an emergency dispatch system. Check that every channel tells residents to call 911 in an emergency.
• Telephony. Many 311 products do not include the phone system; calls run through your contact center platform, integrated with it. Confirm what is included.
• Status depends on departments. Residents only get accurate updates if departments record progress. Where departments use their own systems, updates arrive only as those systems report them.
• Social media. Monitoring usually covers messages to your official accounts, not general public conversation.
• GIS quality. Location validation is only as good as your address and boundary data.
• Text messages. Texting usually requires residents to opt in, and a messaging provider under someone's contract.
• Translation. Some products provide the means to show other languages but not the translations themselves.

Regulations and standards to understand

• The 311 number. In 1997 the Federal Communications Commission assigned 311 as a national code for access to non-emergency police and other government services.
• Open311. GeoReport v2 is an open specification for service request APIs. It defines methods to list services and their definitions, submit a request and get the status of one or many requests, so that third-party apps and open data portals can work with your system.
• Web and mobile accessibility. The Department of Justice's ADA Title II rule (28 CFR Part 35, Subpart H) sets WCAG 2.1 Level AA as the technical standard for state and local governments' web content and mobile apps. An interim final rule published in April 2026 extended the compliance dates to April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special district governments. Check ada.gov for the current dates.
• Language access. Title VI of the Civil Rights Act of 1964 prohibits national origin discrimination in programs that receive federal financial assistance. Federal language-access policy changed in 2025, when Executive Order 14224 revoked Executive Order 13166, and many states and cities have their own language-access laws. Confirm what applies to you with counsel.
• Text messages. Automated texts can be subject to the Telephone Consumer Protection Act (47 U.S.C. 227). Ask your counsel how it applies to your updates.
• Records. Service requests are public records under most state laws and are covered by your retention schedules. Check how the system handles retention, exports and redaction of personal information.

Implementation risks

• The service catalog. Agreeing request types, questions, owners and response targets with every department takes longer than configuring them. Start with the highest-volume types.
• Department integrations. Each work order system is its own project. Decide which departments work in the 311 system and which are integrated, and in what order.
• GIS data. Clean up address points and boundaries before go-live, and agree how GIS changes reach the 311 system.
• Historical data. Decide whether open and closed requests from the old system are migrated, archived or both, and how this affects performance reporting.
• Public expectations. A new app or portal raises residents' expectations of updates. If departments do not close requests promptly, satisfaction can fall.
• Agent training. Agents need the knowledge base and the catalog in place on day one, and a way to report gaps.

Related reading on this site

Requirement pages: ADA Title II, WCAG 2.1, TCPA, State public records laws.

This guide describes the category, not any one product. It is general information, not legal advice: for what a rule requires of your organization, read the rule itself or ask your counsel.