Architecting Non-Emergency City Services
Streamlining Processes and Communications for Citizens
A non-emergency city service is any service provided to a city’s residents or businesses that doesn’t require an immediate response from police, fire departments or paramedics. These types of services can vary widely from city to city and are essential for providing access to local government agencies and supporting the well-being of a city’s residents, visitors and businesses.
Many cities have traditionally relied on manual processes to provide non-emergency services, but the need for automations is increasing rapidly. Services won’t scale without a streamlined set of underlying processes. Residents will quickly become dissatisfied with their elected officials if their requests aren’t resolved in a timely manner. Upset citizens may opt to relocate, which will reduce tax revenues and make it more difficult for cities to maintain their existing infrastructure.
Most cities are also subject to legal regulations that require them to report on how certain types of services are being utilized, which can be difficult to do if response processes are manual. Efficient request intake and workforce management processes along with useful analytics will improve experiences and increase satisfaction with local government agencies.
Capabilities and Processes
The diagram below outlines the business capabilities associated with non-emergency service request processing.
Let’s take a deeper look at the business drivers that are outlined in this capability map:
Collect Service Requests
Request intake processes for non-emergency services are more complicated than they may seem. Depending on a city’s size and the services it offers, a “non-emergency service request” can potentially mean hundreds of different things, ranging from a stray dog sighting to a broken water main. Intake processes need to be able to quickly sort and filter requests by type. Additionally, for services to be effective, residents need to be able to request them from anywhere within the city’s borders and through a variety of different channels.
Major cities with large populations may receive tens of thousands of requests per day. Response times will be delayed if requests have to be processed manually. One of the quickest ways to improve response times is to utilize knowledge articles and AI capabilities like chatbots to provide automated responses to informational requests that don’t require human interaction, allowing call center agents and service teams to focus more of their time on complex issues.
Route Requests Efficiently
It’s not uncommon for cities to have dozens or even hundreds of departments that are responsible for responding to service requests. A comprehensive mapping between request types and city departments is essential to ensure that requests are routed correctly the first time. In the event that a request is routed incorrectly or requires more than one type of service to resolve, departments also need to be able to transfer requests to each other.
Resolve Service Requests
Prioritization and scheduling processes may vary from department to department. Each department is responsible for ensuring that its processes are efficient and can meet agreed upon SLAs. Departments are also responsible for sharing status updates with the call centers and other departments as well.
Optimize Experiences
Residents who request services want to know that their requests are being worked on in a timely manner. Near real-time access to the latest status updates through online portals and mobile applications, along with publicly accessible reports will provide optimal experiences.
Analyze Performance
Call center leads need information about the current number of of open requests, average wait times, and the average number of calls it takes to close a request to help with staffing decisions. Department leads need to keep track of the number of open requests, request locations and SLAs to ensure that crews are dispatched efficiently.
City officials need to understand how departments are using their budgets and the average cost of responding to a request. Department leads need to know the return on investment associated new tools and processes that allow crews to respond to requests more effectively.
Citizens, media and other government agencies need access to long and short term trends related to the types of services the city is providing and how effective its departments are at responding to citizens.
All of the metrics described above can all be made available through reports and dashboards, but a key consideration is that the the underlying data may reside in more than one system. A thorough understanding of underlying data stores and structures is key to effective reporting. We’ll cover this in the next few sections.
Solution Architecture
The diagram below outlines the solution architecture associated with request intake and assignment, along with the associated workforce management and analytics processes.
Service Requests (which can be stored as Cases in Salesforce) can be submitted by people or automated systems through a variety of different methods:
Online Portal
Citizens access an Experience Cloud site that contains an intake form they can use to select a request type and fill in the appropriate fields. See Well-Architected — Forms to read best practice guidance for streamlining intake forms.
Ideally, the site will also utilize AI (chatbots) and display related knowledge articles that can potentially respond to informational queries without having to create a request. Well-designed chatbot prompts and properly categorized knowledge articles are essential for call deflection to work properly. See Well-Architected — Artificial Intelligence for best practice guidance on conversation design.
Telephony
Citizens contact a city’s call center via a published non-emergency number (or an N11 code of 311 in most large US cities). This process should utilize an Interactive Voice Response system (IVR), which walks callers through a series of prompts to gather as much information as possible upfront. The telephony system then sends the information collected to Salesforce via Computer Telephony Integration (CTI). This process reduces the amount of time call center agents spend on the phone with citizens.
Mobile Applications
Citizens submit requests through a form in a mobile application. Apps that provide direct access to device hardware can provide enhanced functionality, such as allowing users to take a picture of the issue they’re reporting and attach it to a request.
IoT
As more cities begin to roll out Smart Cities Initiatives, service requests are increasingly being generated automatically from devices equipped with IoT sensors. Typical examples include smart lighting and air pollution sensors.
Sensors are deployed alongside a service that pings them periodically and interprets their return codes. Success codes that indicate proper operation are logged for reporting purposes. Failure codes that indicate issues are mapped to request types and sent to Salesforce via an API call. This process allows crews to proactively respond to issues before they affect citizens.
Duplicate Management
Large cities can receive tens of thousands of requests per day and may have to handle a large volume od duplicate requests that can be difficult to identify. Consider a scenario where two different citizens who live across the street from each other contact the city about a pothole in front of their house. In this case, their names and addresses will be different, so some of the standard matching rules won’t be applicable, but more than likely they’re reporting the same pothole. Duplicate requests like this can wreak havoc on workforce scheduling processes and send crews on wild goose chases to fix issues that were already resolved by other crews.
To address these types of scenarios, consider a deduplication process that identifies the latitude and longitude associated with a request and searches for similar requests within a given radius. When the system identifies duplicate requests, it should merge them and retain all of the associated contacts on the merged record. This will ensure that everyone who submitted a related request can receive status updates.
Request Assignments and Workforce Management
After requests are created, they’re sent to the appropriate city department where they’ll be triaged and assigned to the appropriate crews. Each department will likely have its own process for responding to service requests. Depending on their size and budget, some departments may even have their own workforce management systems. This means that solutions will likely have to support multiple automations and integrations to backend systems that are triggered based on the request type:
- Requests being routed to departments that utilize the city’s internal IT systems can be assigned directly and a tool like Field Service Lighting can be used for workforce scheduling.
- Requests being routed to departments that have their own IT systems will require integrations. Depending on what the target systems support, you can utilize standard API calls or event driven architecture patterns like Publish / Subscribe to publish events from Salesforce when cases are created. The system that receives the request should use a similar method to send status updates back to the Salesforce platform.
Data Management and Analytics
The volume of records created in large cities each day can impact system performance, which means that an effective archiving strategy is required for successful operations. Cases should remain in Salesforce while they’re open and for a reasonable amount of time after they’re closed. Cases that have been closed longer will likely still be needed for reporting and you’ll also need to consider applicable regulations, such as the United States Freedom of Information Act, which requires cities to save records of service requests for 30 years.
The best way to approach this is to move cases to a data lake or similar type of storage location via a periodic batch job and purge any cases that are no longer relevant from the CRM system. Then you can design an analytics strategy that takes data storage locations into consideration:
- Reports that show current statistics (open case counts, cases by status, etc…) can be developed and run directly in Salesforce.
- Reports that show long term information like trends over a period of time should be developed and run from an analytics system connected to the city’s long term data storage location.
Data Model
Going a level deeper, we can also take a look at the data model. Salesforce Public Sector Solutions has a Public Complaint data model, which centers around the Case object and also contains a set of objects and relationships that will eliminate the need to create customizations to support related information like inspections and assessments.
Note that not every service request is a complaint. Some are simply inquiries or requests for standard services. This data model will support those types of requests as well. You can download a copy of it from the template gallery on the Salesforce Architects Website.
In some cases, crews may have to issue fines to citizens or business owners depending on the type and outcome of a service request. We won’t go into those processes here, but you can find the objects that are related to them in the Regulatory Area, Fees and Enforcement data model that’s available in the template gallery on the Salesforce Architects Website as well.
