CRM_Functional_Requirements_for_RFP_2_(1).xlsx
XLSX spreadsheet 31 KB Posted
- Attached to
- Customer Relationship Management System
- Solicitation number
- 2023-RFP-143
- Issued by
- Allegheny County, Pennsylvania
About this file
The document is a detailed Functional Requirements spreadsheet for a Customer Relationship Management (CRM) system Request for Proposal (RFP) issued by the City of Pittsburgh's Office of Management & Budget and Department of Innovation and Performance. The RFP seeks a comprehensive SaaS solution for a 311 service request management system, requiring 120 total user licenses (15 for call center operators and supervisors, 100 for full entry department users, and 5 for IT/system administrative users). The solution must provide multi-channel constituent service request capabilities, support various communication methods including social media and mobile platforms, and enable robust tracking, reporting, and analytics functionality.
The proposed system requires extensive integration capabilities with existing city systems like ESRI GIS, Cartegraph, Oracle Business Intelligence, and various municipal databases. The City expects the vendor to migrate approximately 130GB of existing data, provide four system environments (development, test, training, and production), and deliver comprehensive documentation and training. The solution must include advanced features such as geofencing, automated escalation, multilingual support, ADA compliance, knowledge base functionality, and sophisticated reporting tools with real-time dashboards. The RFP emphasizes scalability, customization, and the ability to support complex interdepartmental workflows while maintaining a user-friendly interface for both city employees and constituents.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Customer_Relationship_Management_System_(Addendum_#2_Revision).pdf | ||
| Technical_Requirements_2022_-_2023_(4).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 | 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
| 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 | Solution gathers constituent's name, address, contact information (phone, email(s), social media handles), and geographic location and any and all requests they have submitted, including current status. | 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 to procure the following number of licenses: |
311 Call Center Operators and Supervisors - 15 Named Users / 15 Concurrent Users Full Entry Dept Users - 100 Named Users / 70 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 | R | ||
| 1.8 | While the City is requesting a specific number of licenses, it is imperative that this solution is scalable in nature. 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, etc | 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 (mailchimp/constant contact) | W | |
| 3.2 | view and sort requests using Dept specific metrics that include but are not limited to: by requester, by request type, by time period, by status, by Agent, by location (add location services for drop down list of intersections/cross streets, District, Neighborhood), by reporting channel (social media, phone, 311 app, etc) | 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 | |
| Solution Capabilities: | |||
| 5.1 | language translation | R | |
| 5.2 | be ADA compliant - The 311 web portal must be compliant with Section 508 of the American with Disabilities Act (and other legislation or regulations as applicable including ) | R | |
| 5.3 | provide chatbot that has a machine learning capability to optimize the user experience and guide requestor to best answer | W | |
| 5.4 | 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.5 | 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.6 | be capable of withstanding high load emergency situations | R | |
| 5.7 | have the ability to update service requests and manage assignments from field operations. | R | |
| 5.8 | operate in an offline mode | R | |
| 5.9 | 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.10 | 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) |
| 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. | R | ||
| 5.11 | 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.12 | query system by alowing smart searches (tags, keywords, etc) and not only 6 digit ticket number | R | |
| 5.13 | 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.14 | Tickets need to have heirarchy of subtickets or tasks so that other Depts can have visibility. When assigned a task or view only, the secondary Dept also gains visibility to the ticket. |
ability to duplicate a case ability to create tasks within a case completion of a task will activate the next sequential task and make it visible to responsible dept
| --owner of previous task has the option to make their task viewable to other depts | W | ||
| 5.15 | 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.16 | 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.17 | 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.18 | 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.19 | 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.20 | 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.21 | build multiple processes, flows and forms for multiple depts | R | |
| 5.22 | 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.23 | mobile application | R | |
| 5.24 | map system that can easily incorporates multiple map layers (wards, divisions, zones, etc...) | R | |
| 5.25 | constituent interface to view life cycle of 311 submissions | R | |
| 5.26 | file/module/page in CRM with Foreman names and assigned areas | W | |
| 5.27 | 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.28 | Threshold notifications of aging tickets, notify the Dept that created ticket that X number of hours have passed without activity. | R | |
| 5.29 | Gratitude module (for constituents who want to say "thank you" ) | W | |
| 5.30 | be able to use the city’s existing GIS data for geospatial applications. Geospatial data should be easily imported and exported and users should be able to provide feedback on map quality. The solution should also have the ability to generate or incorporate GIS maps and services and plot it to a service request |
incorporate the City's GIS data (street adressing, zoning, council districts, ....etc.). while being able to discern between City and nonCity locations. It also has the ability to inform users if the address entered into the address field is not recognized as a Pittsburgh address. The system will recognize service requests that are outside of the City jurisdiction and will be able to close the City ticket, and properly route and forward the request via email to the appropriate non-City agency
Integration with GIS for street drop down menu
Import a .csv or other common format file for a dropdown selection set be able to use the city’s existing GIS data for geospatial applications. Geospatial data should be easily imported and exported and users should be able to provide feedback on map quality. The solution should also have the ability to generate or incorporate GIS maps and services and plot it to a service request
| incorporate the City's GIS data (street adressing, zoning, council districts, ....etc.). while being able to discern between City and nonCity locations. It also has the ability to inform users if the address entered into the address field is not recognized as a Pittsburgh address. The system will recognize service requests that are outside of the City jurisdiction and will be able to close the City ticket, and properly route and forward the request via email to the appropriate non-City agency | W | |
| 5.31 | include APIs to directly connect to multiple systems. It must be able to integrate with City systems, including but not limited to: |
ESRI GIS
Cartegraph Computronix
| Integration with O365 outlook calendar | R | |
| 5.32 | include APIs to directly connect to multiple systems. It must be able to integrate with City systems, including but not limited to: |
Oracle Business Intelligence Enterprise Edition Microsoft Access JD Edwards Special Events and Film Permiting Solution (TBD) EngagePGH page Park & Shelter Reservations (TBD) Twilio CMS content mgmt system CSS finance system RouteSmart Env Services SkyHawk Monday.com CAD (Computer Aided Dispatch System) - Police Axxon - geographical presence of Police RMS Records Management System - Police Agency Counter will build integrations for:
Facebook Twitter
| 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 | W | ||
| 5.33 | 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.34 | When an Agent queries an address the system displays any violation notices / court dispositions past and present. | R | |
| 5.35 | Preconfigured automated answers and responses, for example weekends, holidays, emergencies, and outages | R | |
| 5.36 | 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.37 | 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.38 | 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 | The respondent should provide four system environments: |
Development/Configuration Test Training
| Production | R | ||
| 6.3 | provide as built doccumentation 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.4 | 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.5 | The Respondent will be required to detail for the City the potential configuration options that are available to meet the requirements. | R | |
| 6.6 | 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.7 | 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.8 | 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.9 | Specify the SLA for restoration of services following an unplanned outage or degradation of services | R | |
| 6.10 | provide external (constituent) discovery before starting implementation | R | |
| 6.11 | Migrate approximately 130gb of data | R | |
| 6.12 | Selected respondent to assist in educating and informing residents about the City's CRM initiative | W | |
| 6.13 | Selected respondent to assist Identifying bidirectional channels to collect and process feedback | W | |
| 6.14 | Selected respondent to assist developing tactics to utilize to build "common ground" with residents | W | |
| 6.15 | Selected respondent to assist Encouraging adoption of and participation by the residents in all channels | W | |
| 6.16 | The selected respondent will work with identified City staff to develop policies, procedures, and protocols for maintaining the knowledge base after implementation | W | |
| 6.17 | 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 | provide data/metrics reporting capabilities - dashboards oriented towards different users, city council viewing requests for their constituents, separately from managers viewing requests for their dept, etc | R | |
| 7.2 | have the ability to generate reports based on performance and use indicators that are designated by the City of Pittsburgh. Indicators may include but are not limited to: reporting on requests by status, customer satisfaction, method used to generate the request, geographic ‘hot spots’, etc. This solution should also include the ability to display real-time analytics. These functions should be easily performed using the agent dashboard. | R | |
| 7.3 | provide a variety metrics and reporting with graphs and charts - need to be able to filter with no limitations | R | |
| 7.4 | Reporting features including exporting tickets to .csv and/or Excel | R | |
| 7.5 | Query on reports based on physical location, legislative district, and/or neighborhood (ward, street, cross roads) | R | |
| 7.6 | 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.7 | Printed reports should include who printed the report, when it was printed, from what location | R | |
| 7.8 | must provide user audit reports for compliance and IT Security | R | |
| 7.9 | Dcoument 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 | Organize tickets into "Clusters" or "hot spots" based on criteria such as | ||
| Street Name, DPW Division, Legislative District, Ticket Type, Cross streets, address, and parcel. | R | ||
| 8.3 | Create Clusters based on distance, type, reporter, or other factors. | ||
| Implement check boxes for including or excluding specific tickets within a Cluster. | R | ||
| 8.4 | Establish a parent/child relationship for multiple tickets from different | ||
| users to address duplicates and efficiently resolve them. For example, if a DNS server issue affects logins and email, treat them as related and close the duplicates. | R | ||
| 8.5 | Automatically remove duplicate tickets from the same reporter. | R | |
| 8.6 | Identify Clusters or Hot Spots by grouping tickets from different reporters | ||
| within the same local geographical area and addressing similar issues. Use icons or color codes to represent these Clusters. | R | ||
| 8.7 | Automated escalation measures for Clusters based on volume or issue type. | R |
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 .