Functional_Requirements.xlsx
XLSX spreadsheet 39 KB Posted
- Solicitation number
- 2026-RFI-089
- Issued by
- Allegheny County, Philadelphia City, Pennsylvania
About this file
This Functional Requirements document outlines the specifications for the City of Pittsburgh's 311 Customer Relationship Management (CRM) system solicitation. The City is seeking a Software-as-a-Service (SaaS) solution that will consolidate citizen service requests across multiple channels including phone, email, social media, chat, text messaging, and in-person submissions. The system must support constituent management with robust tracking of service request lifecycle from initial submission through resolution, encompassing accountability, trend analysis, resource allocation, and service delivery monitoring. Core functional requirements include constituent information management (name, address, contact details, social media handles), request status visibility, multi-channel submission capabilities, real-time analytics and reporting, artificial intelligence features for image recognition and chatbot functionality, ADA Section 508 compliance, and seamless integration with existing City systems including Cartegraph and Computronix. The solution must accommodate at least 230 named users across multiple departments (15 call center operators/supervisors, 200 full entry department users, and 5 IT administrative users) with unlimited mobile worker licenses, and be scalable to support future growth with minimal service interruption.
The vendor must provide comprehensive implementation services including data migration of a minimum 130 gigabytes of existing open records, four system environments (development, test, training, and production), instructor-led training with knowledge transfer to internal City trainers, and detailed technical and user documentation. The respondent's support team and developers must be US-based and available during standard business hours (8am to 5pm EST). Additional requirements include geospatial capabilities leveraging the City's GIS data and existing ESRI geocoder, advanced deduplication and clustering functionality to consolidate duplicate service requests, role-based reporting with customizable dashboards, and integration with multiple City systems and external platforms including social media channels, 911 CAD systems, and municipal authorities. The vendor must provide a project roadmap with milestones and projected completion dates, a testing strategy with scripts, configuration documentation prior to system finalization, and service level agreements for restoration following unplanned outages.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Technical_Requirements.xlsx | XLSX spreadsheet |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Functional Requirements
| Requirement ID | Functional Requirements | |
| (All of the items apply to any subcontractors that work on the solution. ) | System Capability | |
| (select from dropdown) | Comments: |
R= Required Functionality
| W = Wish List | System Capability |
| (select from dropdown - vendor to complete) | Comments: |
(vendor to complete)
| Functional Requirements: | ||
| 1.1 | The solution will foster accountability and allow managers to spot trends, establish customer service goals, and analyze the work of their departments to facilitate informed decision-making regarding the allocation of resources and improvements in operations, thereby improving the provision of City services to residents. | R |
| 1.2 | The system shall collect and maintain constituent information including name, address, phone number, email addresses, social media handles, geographic location, and all submitted service requests with their current status. | R |
| 1.21 | The system shall display the constituent’s identifiable information (such as address and contact details) when creating a new service request to ensure accurate record association and reduce duplicate entries. | R |
| 1.3 | System will provide local elected officials the ability to monitor the delivery of services to their residents. | R |
| 1.4 | Improving service request related measurement tools and tracking of end-to-end call flows (from point of entry to distribution point where ticket is assigned to a team as work, to the team member taking action and then return info flow back to originator) | R |
| 1.5 | Reporting and Analytics API to interface with data from CRM, drive collaboration between residents and departments, foster data driven decision making and process improvements in City departments. | R |
| 1.6 | The solution must be easily adaptable to include the City of Pittsburgh logo and should be customizable to ensure consistency with current city branding and public awareness campaigns. | W |
| 1.7 | The City seeks vendor to provide their licensing structure and bundle with the description and capability of each license level. |
At minimum, the levels of licensing should allow for:
311 Call Center Operators and Supervisors - 15 Named Users / 15 Concurrent Users Full Entry Dept Users - 200 Named Users / 100 Concurrent Users IT/System Administrative Users - 5 Named Users / 5 Concurrent users
If the Respondent would like to offer an alternative licensing model that they believe is financially beneficial to the City, they are welcome to submit that model in addition to the user licensing model requested above.
The City is also interested in licenses for mobile workers, preferably an unlimited number of licenses.
| R | |||
| 1.8 | While the City is requesting a specific number of licenses, it is imperative that this solution is scalable in nature, allowing the system to expand in both 311 users, storage, and public users. | ||
| There is a likelihood of growth in the City 311 division and the solution must be capable of growing and adapting to those needs with minimal service interruption. | R | ||
| 1.9 | The City is exclusively interested in implementing a SaaS solution. Maintenance and support shall be provided through the Subscribed Service Agreement between the Selected Respondent and the City. The maintenance agreement will not commence until the application has been placed in production and accepted by the City in writing. The maintenance agreement must provide ongoing system support and maintenance, including upgrades, bug fixes, and patches, and other technical support necessary for City staff to operate the solution, including help desk support on general system use, configuration settings, reporting, etc. | R | |
| 1.10 | Robust knowledge base that can be easily updated and have external and internal capabilities. | W | |
| 1.11 | Rival real-time or near real-time interactivity, integration with social media and mobility, and an intuitive, easy to navigate user interface for residents and City employees | R | |
| 1.12 | Proposal must include a project roadmap with milestones and projected completion dates. | R | |
| Constituent Capabiliites: | |||
| 2.1 | view the status of their request | R | |
| 2.2 | Submit request through multiple channels: email, voice mail, social media, chat, and text messaging, etc. with support for submitted photographs | R | |
| 2.3 | choose from a preselected group of options to make requests | R | |
| 2.4 | Submit requests without a user name, address or other public facing indentifying data | R | |
| 2.5 | rate the provided service and agent | W | |
| 2.6 | Allow users to keep a contact list of previous Agents/Depts they have communicated with, resident would need to retain ticket number for future reference | R | |
| 2.7 | self password reset | R | |
| 2.8 | scheduling per agent, consitutent would have visibility like scheduling a meeting to see availability and get on calendar for their issue | W | |
| Agent Capabilities: | |||
| 3.1 | Mass message distribution through email (mailchimp/constant contact) and text messaging | R | |
| 3.2 | The system shall provide comprehensive request‑management tools that allow users to view, sort, and filter service requests using department‑specific metrics—such as requester, request type, time period, status, assigned agent, location (including intersections, cross streets, districts, and neighborhoods), and reporting channel (e.g., social media, phone, 311 app). In addition, the system shall include robust keyword search capabilities that can identify city‑specific markers such as intersections, park names, trail names, and other geographically or contextually relevant terms. | R | |
| 3.3 | escalate critical tasks or route tasks to other agencies if necessary. This includes automatic escalation for projects that are past due or highly critical. | R | |
| 3.4 | manually change status information for pending requests. | R | |
| 3.5 | Flag repeat callers | W | |
| Admin Capabilities: | |||
| 4.1 | Admin features: |
Add, Modify Remove (by bulk with low or no code if needed) Agents Depts Request Types and Subcategories Ticket Status and Assignment values
| And ticket routing workflows as needed | R | ||
| 4.2 | perform basic functions such as full backup, customization and real time update processing should be available without advanced programming knowledge | R | |
| 4.3 | access all dashboards, reports and workflows for create/modify/delete | R | |
| 4.4 | Promoting Packages from staging, test to production and refreshing lower environment from Production | R | |
| 4.5 | The system must provide a “Read Only” Admin user profile. |
Users with this profile must be able to view all tickets in all queues across the system.
Users with this profile must be able to create, view, and run reports and dashboards.
Users with this profile must not be able to edit, update, assign, comment on, or otherwise modify any ticket.
The user interface must hide or disable all ticket‑editing actions for users with this role.
| This role is intended for groups such as the Mayor’s Office, who monitor request activity (e.g., during weather events) but do not work or manage tickets. | R | ||
| Solution Capabilities: | |||
| 5.1 | language translation | R | |
| 5.11 | Artificial Intelligence capabilities. Such as, recognition from images/photos and capability to create a Service Request. |
tc={5239660B-E4CD-4EE5-AEB6-8CD089211C78}: [Threaded comment]
Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924
Comment:
| Optional but interested in seeing what's possible | W | ||
| 5.12 | Capability to generate certified letters from Service Requests and ability to add additonal fields if needed. | R | |
| 5.13 | Auto generate emails for non-city services (like the water authority) that are integrated into the 311 system | W | |
| 5.14 | All submitted text fields will have the entirety of the entered text displayed/visible in all instances. | R | |
| 5.15 | The system shall allow users to reopen tickets that have been previously closed within a certain period of time (e.g. within two business days after being closed, the ticket can be reopened). | R | |
| 5.16 | The system shall allow users to enter a location using an intersection format in which the main street and cross street are captured as two separate input fields. For example, users must enter “Penn Avenue” in the Main Street field and “16th Street” in the Cross Street field, rather than providing a combined string such as “Penn Avenue & 16th Street.” | R | |
| 5.17 | A single, standard format for all street addresses entered as location in tickets. (eg, House Number, Street Name. 123 Main Street) | R | |
| 5.18 | The system, including all components of the 311 platform, shall comply with Section 508 of the Americans with Disabilities Act and all other applicable accessibility legislation or regulations. |
| The system shall also adhere to the latest version of the Web Content Accessibility Guidelines (WCAG) to ensure full accessibility for all users. | R | ||
| 5.19 | Provide chatbot that has a machine learning capability to optimize the user experience and guide requestor to best answer. Vendor must provide the cost associated for the chatbot as well. | W | |
| 5.2 | provide a service request UI that is compatible with multiple channels, including but is not limiting to, in person, over the phone, email, text message/SMS, smartphone applications and through the 311 website | R | |
| 5.21 | be compatible with current versions of Industry standard browsers including but not limited to Internet Explorer, Chrome, Firefox and Safari. It should also be mobile and tablet compatible (apple, google, windows, blackberry, etc). | R | |
| 5.22 | be capable of withstanding high load emergency situations | R | |
| 5.23 | have the ability to update service requests and manage assignments from field operations. | R | |
| 5.24 | operate in an offline mode | R | |
| 5.3 | high accuracy of duplication detection and creating relationships among service requests is critical functionality for the City. Different service types have different duplication variables. The Selected Respondent will need to work with City subject matter experts to define the most appropriate duplication detection algorithms for high volume request types. |
| Summarize and remove redundant requests. | R | |
| 5.26 | be a single source of centralized location of constituent contact information and all records related to that person or location (SSOT Source of Truth for constituent records) |
| R | |||
| 5.27 | Must also include ability to similarly track meetings, correspondance and interactions with non-residents, for example contractors, vendors and outside suppliers that work with Mayor's office and other depts. | W | |
| 5.28 | allow submitter to always have access to their ticket where they can go in and edit | ||
| (Example: A ticket is submitted and you realized you left out a picture or important detail; cannot go back in to make changes. This typically causes another ticket to be submitted) | R | ||
| 5.29 | query system by alowing smart searches (tags, keywords, etc) and not only 6 digit ticket number | R | |
| 5.3 | address/location is a required field when necessary, to be populated from a drop down box of Street Names + drop down box of Address Ranges, or a map where the user places a pin marker. |
EMS would add Time and Location fields as required, often they are missing this information
| system displays a map to Agent or User to verify Street name suffix matches their incident location | R | ||
| 5.31 | The system shall support hierarchical ticket management by allowing cases to include subtickets or tasks that provide visibility to other departments as needed. The system shall allow users to duplicate a case, create tasks within a case, and configure task visibility for other departments. Completion of a task shall automatically activate the next sequential task and grant visibility to the responsible department, while the owner of each task shall retain the option to make their task viewable to additional departments.” | W | |
| 5.32 | Graphical representation (color flags, icons, etc) to display tickets by status, by Dept so that Tasks and Tickets status and location is easily displayed | R | |
| 5.33 | When a ticket is reassigned to another Dept, reset flag to "new" so the newly assigned Dept doesn't confuse it as already viewed. | R | |
| 5.34 | Online tickets submitted during non business hours need validation for proper categorization of Risk / Priority and automated escalation where defined by business need. |
Tickets created by or affecting vital services (EMS, PPB, etc) or created by/affecting high profile events, organizations, customers
| Example: Tree down may be an emergency situation requiring immediate action, a full recycle bin would not be escalated | R | ||
| 5.35 | Geofencing or some other method to push alerts/notifications to residents in a specific area, zone, neighborhood, legislative district or custom area defined on a map. | R | |
| 5.36 | Ability to pause a ticket until prerequisite work is completed, for example funding, policy or program takes effect or expires, then ticket wakes up into an active status again. When tickets are put into Hold or Delayed status, notifies constituent of reason for hold. | R | |
| 5.37 | Able to send messages/requests to external users, example other govt entities, jurisdictions, depts, programs, City Contractors, etc |
| forward tickets to outside entities and then close ticket on our side, and notify the customer of the action taken and who new ticket owner is (PWSA, PennDOT, etc) | R | ||
| 5.38 | build multiple processes, flows and forms for multiple depts | R | |
| 5.39 | Notes fields should have a checkbox to allow visibility by other teams or not, in order to maintain privacy of internal dept communications. |
| Prefer that default is visible but can be modified as needed | W | ||
| 5.4 | Any multi-authentication needed through the app should be possible through already commonly existing channels to users (text message, email, or phone call) and not through an authentication app that would require users to download an additional application. | R | |
| 5.41 | map system that can easily incorporates multiple map layers (wards, divisions, zones, etc...) | R | |
| 5.42 | A portal for constituents to log in and view the life cycle of their 311 submissions. Ideally, this is not limited in scale of customer use. | ||
| R | |||
| 5.43 | Ability to create an internal facing portal for City employees to submit a service request for City-related facilities, maintenance needs, and construction/repair needs. | W | |
| 5.44 | Ability to digitize a contact list within the CRM for employees of the departments who are doing the work in the field and their assigned areas. | ||
| E.g. could be a file/module/page in CRM with Foremen names and assigned areas | W | ||
| 5.45 | more granularity for sorting and categorizing tickets: |
example: subcategories for "litter cans" (damaged, need emptied, relocated, etc.)
example: EMS would like check boxes for separating Police Complaint, EMS Complaint, Fire Complaint)
| example: Trash cans, check box for Recycleables, Hazardous, Trash, Green waste (yard clippings), etc | W | ||
| 5.46 | Threshold notifications of aging tickets, notify the Dept that created ticket that X number of hours have passed without activity. | R | |
| 5.47 | Constituent Feedback: | ||
| Gratitude to the City workers (for constituents who want to say "thank you" ) and a space to capture their feedback (such as a survey that asks for their level of satisfaction and a place to include notes) | R | ||
| 5.48 | The solution must be able to use the City’s existing GIS data for all geospatial functions. |
The solution must allow easy import and export of geospatial data.
Users must be able to provide feedback on map quality within the system.
The solution must be able to generate or incorporate GIS maps and services and plot the location on a service request.
The system must incorporate the City’s GIS datasets, including but not limited to:
Street addressing Zoning Council districts Additional City‑defined spatial layers
The system must be able to distinguish between City and non‑City locations using GIS boundaries (Geofencing).
The system must alert the user if the address entered is not recognized as a Pittsburgh address.
The system must detect when a service request is outside City jurisdiction and must:
Automatically close the City ticket, Route and forward the request via email to the appropriate non‑City agency.
The system must support the ability to import a .csv or other common file format to populate dropdown selection sets.
Compatibility with City generated Geocoder using ESRI solution for Geo location and reverse Geo locating.
| Prefer individual GIS services for individual layers rather than one map document managing all layers under one published service. | R | |
| 5.49 | The system must provide the ability to plot service requests on an interactive map as individual points and as a heat map. |
Users must be able to filter the mapped requests by, at minimum:
Request type Department Date or date range Status
Location criteria, including:
Specific address Address range Street name Intersection Street segment
Geolocation attributes, including:
Neighborhood Police zone Council district DPW division Other City-defined spatial boundaries
| The map and/or heat map must be exportable in common formats such as PDF, JPEG, and similar image or document types. | R | |
| 5.5 | Include APIs to directly connect to multiple systems. It must be able to integrate with City systems, including but not limited to: |
*Cartegraph - Required system integrations necessary to support the City’s 311 operational flow as part of the initial implementation.
*Computronix - Required system integrations necessary to support the City’s 311 operational flow as part of the initial implementation
Microsoft365 JD Edwards = new system TBD Eproval EngagePGH RecDesk UCaaS/Cisco Granicus CSS/Impact RouteSmart Samsara Monday.com
911 CAD
RMS - Axon OneStopPgh Insights Edocs/OnBase Atlantis Petlogix Dimonoff Dayforce
Include integration w/ City's Authority Systems ex. WorkDay will build integrations for:
Facebook Twitter Blue Sky
The API for these social media items will be provided by the City. This solution should also contain the capability to integrate new social media platforms as they emerge tc={419479BF-9B0A-4732-A9B8-2D215B662E4C}: [Threaded comment]
Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924
Comment:
| Cherin to update in the actual functional requirements | R | |
| 5.51 | UCAAS/WebEx to include: |
Advanced automation (e.g., workflow triggers, case creation, routing logic) Omnichannel features (chat, email, SMS tied into Salesforce workflows) Reporting/analytics integration between systems Data synchronization beyond basic screen pop Custom UI or embedded experiences tailored to our processes
| Full end-to-end ownership | R | ||
| 5.52 | The system shall integrate with the City of Pittsburgh server that will house constituent contact information hosted & maintained by the City of Pittsburgh - This data will be used to accurately identify constituents and support the merging of related case files. | R | |
| 5.53 | When an Agent queries an address/location the system also displays what Permits and work have been done in the past in this area | R | |
| 5.54 | When an Agent queries an address the system displays any violation notices / court dispositions past and present. | R | |
| 5.55 | Preconfigured automated answers and responses, for example weekends, holidays, emergencies, and outages | R | |
| 5.56 | The solution must allow users to create editable profiles with passwords. | ||
| These profiles would require email validation. These profiles would be accessible online and on mobile. The solution would also have the ability to generate contact logs based on these profiles and would also allow users to either check the status of their request or be notified by email or SMS if the status has been changed. | R | ||
| 5.57 | The solution should be equipped with knowledge base functionality that is accessible by users and easily editable by agents. These interfaces should be separate (even if the information is largely similar). It should come with basic features such as preformatted article and FAQ templates, compatibility with both natural and wildcard search, the ability to rank most useful or popular knowledge base articles and usage and search metrics | R | |
| 5.58 | Vendor must migrate the existing data into the new system | R | |
| Vendor Capabilities: | |||
| 6.1 | The respondent will be required to produce a configuration document as a project deliverable prior to the system’s final configuration. | R | |
| 6.2 | Support Team and Developers must be US based & available during standard business hours (8am to 5pm EST) | R | |
| 6.3 | The respondent should provide four system environments: |
Development/Configuration Test Training Production
| Individual Sandboxes for Admins | R | ||
| 6.4 | provide as built documentation upon delivery, also will provide a detailed system and user documentation to City staff responsible for the operation and support of the system. The Selected Respondent shall provide digital, searchable technical and user manuals to the City. Additionally, the Selected Respondent will also provide the City with complete digital, searchable system implementation documentation concerning installation, configuration, testing, interfaces, and data conversion. The Selected Respondent shall also provide PDF copies of all documentation listed above and unlimited downloads to updated copies | R | |
| 6.5 | The Selected Respondent shall provide, in a timely manner, system documents that describe all software in sufficient technical and functional detail, so that this information can be used by City personnel to maintain the system and resolve identified problems. | R | |
| 6.6 | The Respondent will be required to detail for the City the potential configuration options that are available to meet the requirements. | R | |
| 6.7 | The Respondent will be required to configure all necessary proposed functionality for the City and is expected to work closely with the City’s functional experts to finalize the configurations and transfer knowledge | R | |
| 6.8 | The selected respondent shall provide the City with a comprehensive training program that includes instructor led training to facilitate successful implementation and knowledge transfer of the proposed CRM solution. The City is interested in training services that use employee time efficiently and effectively transfers practical knowledge about the use of the new CRM solution. The Respondent shall propose an approach that includes significant opportunity for knowledge transfer throughout implementation and enhanced system understanding by the use and development of “inhouse trainers.” | R | |
| 6.9 | The respondent will be required to provide a testing strategy and plan (including scripts) as a project deliverable to the City. The final testing plan will be signed off by the City prior to the execution of tests | R | |
| 6.10 | Specify the SLA for restoration of services following an unplanned outage or degradation of services | R | |
| 6.11 | provide external (constituent) discovery before starting implementation | R | |
| 6.12 | Migrate existing open records in the system (minimum 130gb) |
tc={02BCCFA5-4EC1-4800-8F02-C84F506FCD3D}: [Threaded comment]
Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924
Comment:
Cherin to check on this amount tc={5239660B-E4CD-4EE5-AEB6-8CD089211C78}: [Threaded comment]
Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924
Comment:
Optional but interested in seeing what's possible tc={419479BF-9B0A-4732-A9B8-2D215B662E4C}: [Threaded comment]
Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924
Comment:
| Cherin to update in the actual functional requirements | R | ||
| 6.13 | Selected respondent to assist in educating and informing residents about the City's CRM initiative | W | |
| 6.14 | Selected respondent to assist Identifying bidirectional channels to collect and process feedback | W | |
| 6.15 | Selected respondent to assist developing tactics to utilize to build "common ground" with residents | W | |
| 6.16 | Selected respondent to assist Encouraging adoption of and participation by the residents in all channels | W | |
| 6.17 | The selected respondent will work with identified City staff to develop policies, procedures, and protocols for maintaining the knowledge base after implementation | W | |
| 6.18 | The Selected Respondent will work with the City to ensure that at the time of cutover, the system is functioning with performance superior to that of the current CRM system. | R | |
| Reporting: | |||
| 7.1 | The solution shall provide role-based data/metrics reporting capabilities through configurable dashboards that include visualization and geospatial mapping of captured service request data. |
Dashboards must tailor views to different user roles (e.g., City Council members viewing requests from their constituents; Department Managers viewing requests for their department).
Visualizations should include charts (e.g., trends over time, request categories, SLA status) and interactive maps that plot service requests by location with filters (date range, status, priority, neighborhood, department, requester type).
Users should be able to drill down from aggregated metrics to individual request details and export data (CSV/XLS/PDF) according to their permissions.
| R | ||
| 7.2 | Data/metric reporting would allow for data visualization of captured service request information and mapping within the solution | R |
| 7.3 | “The system shall provide flexible reporting and analytics capabilities that allow users to generate performance‑based reports using City‑defined indicators—such as request status, customer satisfaction, request submission method, and geographic hot spots—and to access real‑time analytics directly from the agent dashboard. The reporting tools shall support an interchangeable, drag‑and‑assemble style configuration so users can easily select data elements, build new reports, and produce outputs that are visually clear and easy to interpret. | R |
| 7.4 | provide a variety metrics and reporting with graphs and charts - need to be able to filter with no limitations | R |
| 7.5 | Reporting features including exporting tickets to .csv, .pdf and/or Excel | R |
| 7.6 | Query on reports based on physical location, legislative district, and/or neighborhood (ward, street, cross roads) | R |
| 7.7 | must provide Advanced Reporting Tools: |
User satisfaction surveys problem or case status trending and issue identification
| reporting filterable by day, week, month, time to resolve, Status, etc | R | ||
| 7.8 | Printed reports should include who printed the report, when it was printed, from what location. | R | |
| 7.9 | The system must generate clear and simplified Service Request (SR) printouts that present all relevant information in a short (can be modified to less than a page) and an easy‑to‑read format. Each printout must include: |
• Key SR details displayed prominently
• An embedded map showing the SR location
• All attachments associated with the SR
| R | |||
| 7.10 | must provide user audit reports for compliance and IT Security | R | |
| 7.11 | Document import and export abilities | R | |
| Deduplication and Clustering | |||
| 8.1 | Streamline processes by consolidating duplicate requests into a single | ||
| work order through deduplication. | R | ||
| 8.2 | The system shall group tickets into logical ‘Clusters’ or ‘Hot Spots’ by identifying patterns and proximity based on attributes such as street name, DPW division, legislative district, ticket type, cross streets, address, and parcel information. | R | |
| 8.3 | The system shall generate ticket Clusters using configurable criteria, including distance, ticket type, reporter, and other relevant factors. The system shall also provide selection controls (e.g., checkboxes) that allow users to include or exclude specific tickets within each Cluster. | R | |
| 8.4 | The system shall establish a parent–child relationship among related tickets submitted by different users in order to identify and manage duplicates. When a parent ticket is updated or resolved, all associated duplicate (child) tickets shall be automatically resolved simultaneously, and all customers or submitters linked to those duplicate tickets shall receive the same status updates and communications generated from the parent ticket. | R | |
| 8.5 | Automatically remove duplicate tickets from the same reporters. | R | |
| 8.6 | The system shall automatically identify and generate Clusters or Hot Spots by grouping tickets from different reporters that occur within the same local geographic area and relate to similar issues. The system shall visually represent these Clusters using icons or color‑coding, and shall automatically generate corresponding heat maps to provide spatial insight into areas with high ticket concentration | R | |
| 8.7 | Automated escalation measures for Clusters based on volume or issue type. | R |
Optional but interested in seeing what's possible
Cherin to update in the actual functional requirements
Cherin to check on this amount index
| Core Capability |
| Configurable by Vendor |
| Configurable by City Staff |
| Requires Customization |
| Provided in Conjunction with a 3rd Party |
| Not Applicable |
File details come from the government source that posted it. Updated .