1-3 - 26RFP14 Williamson County EAM RFP - Attachment B.xlsx
XLSX spreadsheet 184 KB Posted
- Attached to
- 26RFP14 Enterprise Asset Management System State and local contract opportunity
- Solicitation number
- 26RFP14
- Issued by
- Williamson County, Texas
About this file
Williamson County EAM RFP - Attachment B Summary
This is an attachment to a Request for Proposal (RFP) issued by Williamson County, Texas for an Enterprise Asset Management (EAM) System. The county is seeking turnkey software, consulting, and implementation services to establish a new EAM system with an anticipated initial term of ten (10) years. The attachment contains detailed specifications and requirements that potential respondents must address in their proposals, including technical capabilities, implementation timelines, training and support provisions, and system performance standards necessary to meet the county's asset management objectives across multiple departments and operational areas.
The file serves as a technical and administrative framework document that outlines the county's expectations for system functionality, data integration, reporting capabilities, and vendor qualifications. Respondents are required to demonstrate experience with similar EAM implementations, provide detailed project plans and timelines, and confirm their ability to support the system throughout the contract term. The attachment establishes evaluation criteria and specification requirements that will be used to assess proposals, including system architecture, scalability, security measures, user training programs, and ongoing maintenance and support services to ensure successful deployment and long-term operational effectiveness of the EAM system.
View the file
Other files for this state and local contract opportunity
| File | Type | Posted |
|---|---|---|
| 4-6 - Proposal Affidavit rev.081325 fillable.pdf | ||
| 7-9 - Cancelled or Terminated Contracts (FILLABLE).pdf | ||
| 12-2 - 26RFP14 Williamson County EAM RFP - Attachment A.docx | DOCX document | |
| 5-7 - RFP CIQ (3) (2).docx | DOCX document | |
| 8-10 - Similar Contracts (FILLABLE) 5-21-25 (3).pdf | ||
| 11-1 - 26RFP14 Williamson County EAM RFP Specifications.pdf | ||
| 3-5 - 26RFP14 Williamson County EAM RFP - Attachment C2.docx | DOCX document | |
| 2-4 - 26RFP14 Williamson County EAM RFP - Attachment C1.xlsx | XLSX spreadsheet | |
| 6-8 - Proposal References FILLABLE.pdf | ||
| 10-Link for virtual RFP Closing for 26RFP14 Enterprise Asset Management System.docx | DOCX document | |
| 9-Link for Teleconference for 26RFP14 Enterprise Asset Management System.docx | DOCX document |
Show all 11
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Table of Contents ERROR:#VALUE! Williamson County EAM System Selection Project
| Functional and Technical Requirements | ERROR:#VALUE! | ||
| Table of Contents | |||
| Tab No. | Requirements Functional Area | Requirements | |
| 1 | General and Technical | 185 | |
| 2 | Public Portal | 70 | |
| 3 | Service Requests | 38 | |
| 4 | Work Orders | 134 | |
| 5 | Asset Management | 114 | |
| 6 | Inventory Management | 115 | |
| 7 | Facilities Maintenance | 51 | |
| 8 | Interfaces | 10 | |
| 9 | Data Conversion | 7 | |
| Total Requirements | 724 | ||
| Indicator | Definition | Instruction | |
| S | Standard: Feature/Function is included in the current software release and will be implemented by the planned phase go-live date as part of the proposal from Vendors in accordance with agreed-upon configuration planning with the County. | Respondents are encouraged, but not required, to provide additional information in the Comments column to further demonstrate the system’s ability to meet the requirement. | |
| F | Future: Feature/Function will be available in a future software release available to the County by July 1, 2026, at which point it will be implemented in accordance with agreed-upon configuration planning with the County. | If a response indicator of “F” is provided for a requirement that will be met in a future software release, the Respondent shall indicate the planned release version, as well as the time the release will be generally available. | |
| C | Customization: Feature/Function is not included in the current software release, and is not planned to be a part of a future software release. However, this feature could be provided with custom modifications. All related customization costs should be indicated in Attachment C1 – Cost Worksheet. | If a response indicator of “C” is provided for a requirement that will be met through a custom modification, the Respondent shall indicate the cost of such a modification. | |
| T | Third Party: Feature/Function is not included in the current software release, and is not planned to be a part of a future software release. However, this feature could be provided with integration with a third-party system. This system should be specified. | If a response indicator of “T” is provided for a requirement that will be met by integration with a third-party system, the Respondent shall identify this third-party system and include a cost proposal to secure this system. If the third-party system is a part of the proposal, the third-party shall respond to the appropriate requirements using the “S”/”C”/”T”/”N” response indicators with a clear notation that the responses are provided by the third-party. | |
| N | No: Feature/Function cannot be provided. | N/A |
&G &14Williamson County&"-,Bold" Enterprise Asset Management (EAM) System Selection Project &"-,Regular"Functional and Technical Requirements &G
Attachment B Page &P of &N Last Updated: December 22, 2025
1. General and Technical
| Indicator | Definition | Instruction | ||
| S | Standard: Feature/Function is included in the current software release and will be implemented by the planned phase go-live date as part of the proposal from Vendors in accordance with agreed-upon configuration planning with the County. | Respondents are encouraged, but not required, to provide additional information in the Comments column to further demonstrate the system’s ability to meet the requirement. | ||
| F | Future: Feature/Function will be available in a future software release available to the County by July 1, 2026, at which point it will be implemented in accordance with agreed-upon configuration planning with the County. | If a response indicator of “F” is provided for a requirement that will be met in a future software release, the Respondent shall indicate the planned release version, as well as the time the release will be generally available. | ||
| C | Customization: Feature/Function is not included in the current software release, and is not planned to be a part of a future software release. However, this feature could be provided with custom modifications. All related customization costs should be indicated in Attachment C1 – Cost Worksheet. | If a response indicator of “C” is provided for a requirement that will be met through a custom modification, the Respondent shall indicate the cost of such a modification. | ||
| T | Third Party: Feature/Function is not included in the current software release, and is not planned to be a part of a future software release. However, this feature could be provided with integration with a third-party system. This system should be specified. | If a response indicator of “T” is provided for a requirement that will be met by integration with a third-party system, the Respondent shall identify this third-party system and include a cost proposal to secure this system. If the third-party system is a part of the proposal, the third-party shall respond to the appropriate requirements using the “S”/”C”/”T”/”N” response indicators with a clear notation that the responses are provided by the third-party. | ||
| N | No: Feature/Function cannot be provided. | N/A | ||
| General and Technical | ||||
| Req # | Description of Capability | Criticality | Respondent Response | Comments |
| Technical Environment | ||||
| GT.1 | The system shall flow all changes made in the system throughout all proposed system modules without the need for duplicate data entry. | Critical | ||
| The system shall import and export data from (or to) standard file formats including but not limited to: | ||||
| GT.2 | .html; | Critical | ||
| GT.3 | PDFs that are text based and searchable; | Critical | ||
| GT.4 | .txt; | Critical | ||
| GT.5 | .csv; | Critical | ||
| GT.6 | .xlsx (MS Excel version 2016 or later, including MS 365); | Critical | ||
| GT.7 | .docx (MS Word version 2016 or later, including MS 365); | Critical | ||
| GT.8 | .ics (MS Outlook version 2016 or later, including MS 365, for calendaring); | Critical | ||
| GT.9 | .heic; | Critical | ||
| GT.10 | .jpeg; | Critical | ||
| GT.11 | .jpg; | Critical | ||
| GT.12 | .xml; | Critical | ||
| GT.13 | .tif; | Critical | ||
| GT.14 | .kmz; | Critical | ||
| GT.15 | .shp; and | Critical | ||
| GT.16 | Other County-defined. | Critical | ||
| GT.17 | The system shall support APIs (Application Programming Interface) for third-party system integration, including both data entry and extraction, as well as execute workflows or initiate processes. | Critical | ||
| GT.18 | The system shall provide a toolkit to create and manage APIs. | Critical | ||
| GT.19 | The system shall support scheduled data feeds for exchanging file import/exports with third-party systems. | Critical | ||
| GT.20 | The system shall provide a centralized data dictionary that fully describes table structure, interdependencies, and appropriate levels of metadata. | Critical | ||
| GT.21 | The system shall provide a production, test, and development environment including the ability to track software changes applied to each environment and roll back as necessary. | Critical | ||
| GT.22 | The system shall support speech-to-text services from a mobile, laptop, or desktop device. | Desired | ||
| Document Management | ||||
| GT.23 | The system shall provide "Document Management System" functionality to track electronic files associated with specific system records. | Critical | ||
| GT.24 | The system shall support data storage with discrete version control in accordance with defined operational standards. | Critical | ||
| GT.25 | The system shall provide the ability to link imported documents to specific records. | Critical | ||
| GT.26 | The system shall use "drag and drop", electronic file upload and scan document functionality to associate electronic files to transactions within the system. | Critical | ||
| GT.27 | The system shall restrict modification of attached documents based on individual or department permissions. | Critical | ||
| GT.28 | The system shall allow a user to scan documents directly into the system. | Critical | ||
| GT.29 | The system shall permit export of a file directly for document storage, for example in a third-party system or network drive. | Critical | ||
| GT.30 | The system shall have the ability to email electronic files to an internal or external party (e.g., send a copy of a photo to another department). | Critical | ||
| GT.31 | The system shall identify records with documentation/attachments. | Critical | ||
| GT.32 | The system shall associate electronic files with a system record with the following types: MS Excel, MS Word, .shp, PDF, .dwg, .tif, .jpg, heic,.kmz,.dgn, and other County-defined file types. Please describe limitations in the comments. | Critical | ||
| GT.33 | The system shall allow the County to restrict or define allowable file types based on appropriate security permissions. | Critical | ||
| GT.34 | The system shall allow the County to set maximum file size limitations. | Critical | ||
| GT.35 | The system shall integrate with third-party signature validation systems (e.g., AdobeSign). | Critical | ||
| GT.36 | The system shall store and apply digital copies of signatures to documents (e.g., checks, notification letters) with appropriate security permissions. | Desired | ||
| GT.37 | The system shall support application of certificate verified internal electronic signatures providing assurance of authenticity, integrity, and non-repudiation. | Desired | ||
| GT.38 | The system shall have the ability to place a County-defined limit on the number of records generated in a query, with a notification to the user of an incomplete data set. With the ability to override based on security permissions. | Desired | ||
| GT.39 | The system shall support the purging of linked electronic files, according to County-defined schedules, allowing for differing schedules based on the document, module, and/or litigation hold. | Desired | ||
| GT.40 | The system shall electronically capture and store files, with Optical Character Recognition (OCR) capabilities. | Desired | ||
| GT.41 | The system shall provide an internal messaging system to message within the EAM. | Desired | ||
| GT.42 | The system shall provide the ability to track internal correspondence and attach to system records (e.g., service requests or work orders). | Critical | ||
| Security | ||||
| GT.43 | The system shall utilize the existing Active Directory user authentication regardless of deployment method. | Critical | ||
| GT.44 | The system shall inherit groups from Active Directory for application authentication. | Desired | ||
| GT.45 | The system shall support Single Sign-On (SSO). | Critical | ||
| GT.46 | The system shall support System for Cross-Domain Identity Management (SCIM) for provisioning and deprovisioning users. | Critical | ||
| GT.47 | The system shall allow for multi-factor authentication for both internal and external users. | Critical | ||
| GT.48 | The system shall provide import and export capabilities with user-level security options to control access to sensitive information. | Critical | ||
| GT.49 | The system shall encrypt data stored in the database (data at rest). | Critical | ||
| GT.50 | The system shall encrypt data stored in the application. | Critical | ||
| GT.51 | The system shall encrypt data in-transit. | Critical | ||
| GT.52 | The system shall provide role-based security. | Critical | ||
| GT.53 | The system shall update all security roles automatically (user discretion) when a change in the "master" role is made with updates made in real time and applied to all in-progress activities. | Critical | ||
| The system shall provide security at the following levels: | ||||
| GT.54 | Department; | Critical | ||
| GT.55 | Division; | Critical | ||
| GT.56 | Role or group; | Critical | ||
| GT.57 | User ID; | Critical | ||
| GT.58 | Screen; | Critical | ||
| GT.59 | Menu; | Critical | ||
| GT.60 | Report; | Critical | ||
| GT.61 | Field; | Desired | ||
| GT.62 | Field value as defined by the County (e.g., asset category, asset class); | Critical | ||
| GT.63 | GIS feature; and | Critical | ||
| GT.64 | Other County-defined levels. | Critical | ||
| GT.65 | The system shall allow the County to determine which fields are visible to which security roles. | Critical | ||
| The system shall track audit changes throughout the system that creates a log of all records maintained and includes: | ||||
| GT.66 | Date; | Critical | ||
| GT.67 | Time, to the nearest minute; | Critical | ||
| GT.68 | User; | Critical | ||
| GT.69 | Information prior to change; | Critical | ||
| GT.70 | Changed information; and | Critical | ||
| GT.71 | Other administrator-configurable information. | Critical | ||
| GT.72 | The system shall provide configurable audit reports. | Critical | ||
| GT.73 | The system shall automatically send configured audit reports on a scheduled basis or by a triggered audit event. | Critical | ||
| GT.74 | The system shall allow auditing within modules to be determined by the module, and configured by the administrator. | Critical | ||
| GT.75 | The system shall allow a County system administrator to configure the duration in which audit logs are retained (e.g., 90 days). | Critical | ||
| GT.76 | The system shall automate the export of audit logs. | Critical | ||
| GT.77 | The system shall allow authorized users to have access to a log of security activity to determine users that have signed on and off the system, as well as unsuccessful attempts to sign on to the system. | Critical | ||
| GT.78 | The system shall allow the County system administrator to add and change permissions for system access. | Critical | ||
| GT.79 | The system shall log users off the system after a County system administrator-defined period of inactivity. | Critical | ||
| GT.80 | The system shall allow multiple levels of County designated system administrators (e.g., IT/technical and end-user department/functional). | Critical | ||
| GT.81 | The system shall provide the ability to mask fields based on County-defined business rules. | Desired | ||
| GT.82 | The system shall apply the same security permissions to system queries and reports as it does to data fields/elements, based on user/role (e.g., data fields masked on a record or transaction are similarly masked on reports run by the user). | Critical | ||
| GT.83 | The system shall be operational on a 24 x 7 scheduled basis. | Critical | ||
| User Interface | ||||
| GT.84 | The system shall provide the user with integrated application modules that offer a consistent user interface to minimize user training and administration of the system. | Critical | ||
| GT.85 | The system shall provide drop down boxes, or other pick list function, for data selection. | Critical | ||
| GT.86 | The system shall provide configurable quick keys or keyboard shortcuts (e.g., function keys). | Desired | ||
| GT.87 | The system supports the ability for the County to designate which non-system required fields can be "made" required to support business operations. | Critical | ||
| GT.88 | The system shall provide the ability for the County to create new fields based on appropriate security permissions. | Critical | ||
| GT.89 | The system shall provide an administrative messaging system (e.g., a message to alert users of system maintenance activity). | Desired | ||
| GT.90 | The system shall provide customizable screens based on roles and permissions. | Critical | ||
| GT.91 | The system shall provide contextual help (i.e., field descriptions that are displayed based on the location of the mouse or cursor). | Critical | ||
| GT.92 | The system shall provide customizable help. | Critical | ||
| GT.93 | The system shall provide data validation on entry. | Critical | ||
| GT.94 | The system shall create error logs with detail associated with the error. | Critical | ||
| GT.95 | The system shall allow users to send error reports to the County. | Critical | ||
| GT.96 | The system shall provide configuration options for the level of detail that is logged in error logs. | Critical | ||
| GT.97 | The system shall spell check on any field with the ability for a user to accept or ignore suggestion. | Critical | ||
| GT.98 | The system shall validate against address field entries to align with County address standards. | Critical | ||
| GT.99 | The system shall search by fragment or portion of a word or number. | Critical | ||
| GT.100 | The system has the ability for multiple windows to be open at the same time. | Critical | ||
| GT.101 | The system shall warn a user that they are about to execute a process and ask if they want to proceed (i.e., to warn before posting a batch of changes). | Critical | ||
| GT.102 | The system shall allow an administrator to configure which business process are prompted with a warning to proceed, with appropriate security permissions. | Critical | ||
| GT.103 | The system shall allow the configuration of processes using either the keyboard only, the mouse only, or a combination of the two, depending on a user's preference. | Desired | ||
| GT.104 | The system shall allow the system administrator to rename field labels. | Critical | ||
| GT.105 | The system shall support pre-filled fields in appropriately pre-formatted screens eliminating redundant data entry. | Critical | ||
| GT.106 | The system shall display which environment the user is logged into (i.e., test vs. production). | Critical | ||
| GT.107 | The system shall render application windows to the set screen resolution without application window truncation, or require scrolling to access all areas of the window. | Critical | ||
| GT.108 | The system shall allow application windows, including text and field dimensions, to be maximized to fit allotted screen size (i.e., increase window size to increase amount of data displayed instead of simply zooming in on data). | Critical | ||
| Workflow | ||||
| GT.109 | The system shall provide workflow functionality in all proposed system modules. | Critical | ||
| GT.110 | The system shall initiate and track workflow and approval processes. | Critical | ||
| GT.111 | The system shall allow users to approve multiple tasks/transactions simultaneously, based on appropriate security permissions. | Critical | ||
| GT.112 | The system shall allow systems administrators to assign different levels of approval for the same user. | Critical | ||
| GT.113 | The system shall allow systems administrators to configure the system to maintain separation of duties related to workflow approval processes. | Critical | ||
| The system shall set workflow rules by: | ||||
| GT.114 | User; | Critical | ||
| GT.115 | Role; | Critical | ||
| GT.116 | Department; | Critical | ||
| GT.117 | Any string in the Chart of Accounts or Account; | Desired | ||
| GT.118 | Thresholds; | Critical | ||
| GT.119 | Percentage argument; | Critical | ||
| GT.120 | Numerical argument; | Critical | ||
| GT.121 | Record type (i.e., work order type, asset classification); | Critical | ||
| GT.122 | Priority type; and | Critical | ||
| GT.123 | Other County-defined workflow rules. Please describe limitations in the comments. | Critical | ||
| GT.124 | The system shall allow temporary availability status changes of users (e.g., unavailable due to vacation time). | Critical | ||
| GT.125 | The system shall re-route workflow assignments based on availability triggered by user unavailable status. | Critical | ||
| GT.126 | The system shall re-route workflow assignments based on availability triggered by County-defined periods of no response. | Critical | ||
| GT.127 | The system shall notify a County-defined user of unsuccessful workflow processes. | Critical | ||
| GT.128 | The system shall provide event-driven notification by email to multiple users that can be configured at any step within any workflow. | Critical | ||
| GT.129 | The system shall allow graphical tools for documenting workflow. | Desired | ||
| GT.130 | The system shall support workflow groups (e.g., assign a work order to facilities rehab group to be visible and accessible to all users in that group). | Critical | ||
| GT.131 | The system shall have the ability for a user to review and approve a workflow transaction directly from within an email, without requiring the user to follow a link to the system to approve the transaction (e.g., an approver can click "approve" in the email and have the approval be recorded in the system, and trigger the next applicable workflow step). | Critical | ||
| GT.132 | The system shall have the ability for a user to review and approve a workflow transaction directly from within an MS Teams message, without requiring the user to follow a link to the system to approve the transaction (e.g., an approver can click "approve" in the email and have the approval be recorded in the system, and trigger the next applicable workflow step). | Critical | ||
| Vendor Support | ||||
| GT.133 | The vendor will schedule planned outage times to be outside standard County business hours. | Critical | ||
| GT.134 | The vendor will provide support during and outside standard County business hours. | Critical | ||
| GT.135 | The vendor will notify the County of any changes to the County's database or applications as a result of support actions and provide related documentation. | Critical | ||
| GT.136 | The system shall provide an online tutorial to assist users learning the software. | Critical | ||
| GT.137 | The system shall provide online software documentation for all software application modules. | Critical | ||
| GIS | ||||
| GT.138 | The system shall provide bi-directional integration with County's GIS, including access to server-based and desktop GIS software, geodatabases, and other GIS data, based on appropriate security permissions. | Critical | ||
| GT.139 | The system shall provide an integrated bi-directional data search, query and map display with GIS integration. Map-based GIS searches identify records in the system and system data searches generate GIS-based map displays in office-based and mobile platforms. | Critical | ||
| GT.140 | The system shall utilize GIS tools for buffer zone or interactive "lasso" of map features to select those features and records in the system. | Critical | ||
| GT.141 | The system shall provide GIS-based map displays accessed from the system that enables full GIS functionality for pan, zoom, and other basic map display functions. | Critical | ||
| GT.142 | The system shall provide GIS-based map displays accessed from the system, maintaining all geographic reference and display parameters established in the GIS (e.g., annotation, symbology, scale thresholds, coordinate system/projection settings). | Critical | ||
| GT.143 | The system shall allow for synchronized updates of attribute data stored as fields in the GIS database (i.e., data entries or updates in the system will automatically update corresponding fields in the GIS database), based on appropriate security permissions. | Critical | ||
| GT.144 | The system shall allow a user to use GIS-based tools for interactive distance and area calculations, buffer selection, and other basic mapping functionality. | Critical | ||
| GT.145 | The system shall allow map-based mark-up--allowing "redlining" of a map display (lines, shapes, annotations) and saving that marked-up display as a separate document (e.g., PDF). | Critical | ||
| GT.146 | The system shall allow access to thematic mapping tools of the GIS to design and generate custom map displays based on attribute data stored in the system (e.g. work order locations symbolized by work order type or status). | Critical | ||
| GT.147 | The system shall create a work order or inspection associated with longitude and latitude. | Critical | ||
| GT.148 | The system shall create a work order or inspection containing multiple addresses or assets. (e.g., Infrastructure creates a cleaning work order for multiple assets). | Critical | ||
| GT.149 | The system shall create a work order or inspection associated with an attribute from County GIS (e.g., street segment or intersection). | Critical | ||
| GT.150 | The system shall provide GIS access, map display, and data entry from mobile devices. | Critical | ||
| GT.151 | The system shall provide access to multiple basemaps (e.g., satellite imagery, vector, other County-defined basemaps). | Critical | ||
| The system shall integrate with the following Esri products: | ||||
| GT.152 | Esri Roads and Highways; | Critical | ||
| GT.153 | Esri Indoors; | Critical | ||
| GT.154 | Esri Mission; and | Critical | ||
| GT.155 | Other County-defined Esri products. Please describe limitations in the comments. | Critical | ||
| GT.156 | The system shall support Esri service access from Enterprise Portal, ArcGIS Server, and ArcGIS Online. | Critical | ||
| GT.157 | The system shall have the ability to access Esri secured services. | Critical | ||
| Reporting and Dashboards | ||||
| GT.158 | The system shall provide an operational performance dashboard. | Critical | ||
| GT.159 | The system shall allow the County to customize the information presented on the performance dashboard by user. | Critical | ||
| GT.160 | The system shall provide drill down functionality within a query, with the ability to query on multiple fields. | Critical | ||
| GT.161 | The system shall allow the County to customize the information presented on the performance dashboard by group of users. | Critical | ||
| GT.162 | The system shall display information on the performance dashboard in real-time. | Critical | ||
| GT.163 | The system shall provide a library of standard reports (i.e., "canned" reports). | Critical | ||
| GT.164 | The system shall allow a user to modify existing reports, with appropriate security permissions. | Critical | ||
| GT.165 | The system shall provide an integrated report writer that has a consistent look and feel across all proposed system modules. | Critical | ||
| GT.166 | The system shall provide an integrated report writer that allows the creation of reports comprised of any discrete data field throughout the system with proper security permissions. | Critical | ||
| GT.167 | The system shall save a report as a new template after a user copies and modifies an existing report, with appropriate security permissions. | Critical | ||
| GT.168 | The system shall configure and save ad hoc reports by individual user, with the ability to provide access to other users with appropriate security permissions. | Critical | ||
| GT.169 | The system shall save favorite reports in a menu or pick-list by individual user. | Critical | ||
| GT.170 | The system shall allow generated reports to be viewed on screen prior to being printed/exported. | Critical | ||
| GT.171 | The system shall allow reports to be generated that are searchable. | Critical | ||
| GT.172 | The system shall allow users to configure automatic distribution paths for generated reports (i.e., automatically send a report to a particular user). | Critical | ||
| GT.173 | The system shall allow reports to be generated that have "drill-down" capabilities. | Critical | ||
| GT.174 | The system shall print/export graphs and charts for presentation style reports. | Critical | ||
| Mobile Devices | ||||
| GT.175 | The system shall provide a user interface that is fully accessible from mobile devices. | Critical | ||
| GT.176 | The system shall support full GIS functionality on mobile devices. | Critical | ||
| GT.177 | The system shall be device agnostic when run on mobile devices (e.g., the system can be run on Android, iOS, Windows). | Critical | ||
| GT.178 | The system is HTML responsive and can adjust to screen size of the mobile device being used (e.g., iPhone, iPad, laptop). | Critical | ||
| GT.179 | The system shall provide an iOS app for use on both iPhones and iPads. | Critical | ||
| GT.180 | The system shall provide an Android app for use on Android phones and tablets. | Critical | ||
| GT.181 | The system shall allow disconnected data editing on field device (e.g., entering work order comments). | Critical | ||
| GT.182 | The system shall allow the user to work off-line and sync the data when back on-line. | Critical | ||
| GT.183 | The system shall provide a route calculator that will look at the technicians work orders for that day and calculate the most efficient route. | Critical | ||
| GT.184 | The system shall print to a County networked printer from a mobile device in the field. | Desired | ||
| GT.185 | The system shall support a mobile application for creating, editing, and updating GIS features in the field. | Critical |
&G &14Williamson County&"-,Bold" Enterprise Asset Management (EAM) System Selection Project &"-,Regular"Functional and Technical Requirements &G
Attachment B Page &P of &N Last Updated: December 22, 2025
2. Public Portal
| Indicator | Definition | Instruction | ||
| S | Standard: Feature/Function is included in the current software release and will be implemented by the planned phase go-live date as part of the proposal from Vendors in accordance with agreed-upon configuration planning with the County. | Respondents are encouraged, but not required, to provide additional information in the Comments column to further demonstrate the system’s ability to meet the requirement. | ||
| F | Future: Feature/Function will be available in a future software release available to the County by July 1, 2026, at which point it will be implemented in accordance with agreed-upon configuration planning with the County. | If a response indicator of “F” is provided for a requirement that will be met in a future software release, the Respondent shall indicate the planned release version, as well as the time the release will be generally available. | ||
| C | Customization: Feature/Function is not included in the current software release, and is not planned to be a part of a future software release. However, this feature could be provided with custom modifications. All related customization costs should be indicated in Attachment C1 – Cost Worksheet. | If a response indicator of “C” is provided for a requirement that will be met through a custom modification, the Respondent shall indicate the cost of such a modification. | ||
| T | Third Party: Feature/Function is not included in the current software release, and is not planned to be a part of a future software release. However, this feature could be provided with integration with a third-party system. This system should be specified. | If a response indicator of “T” is provided for a requirement that will be met by integration with a third-party system, the Respondent shall identify this third-party system and include a cost proposal to secure this system. If the third-party system is a part of the proposal, the third-party shall respond to the appropriate requirements using the “S”/”C”/”T”/”N” response indicators with a clear notation that the responses are provided by the third-party. | ||
| N | No: Feature/Function cannot be provided. | N/A | ||
| Public Portal | ||||
| Req # | Description of Capability | Criticality | Respondent Response | Comments |
| General Requirements | ||||
| PP.1 | The system shall provide a public portal that is integrated with other system modules including, but not limited to, work orders, asset management, fleet management, and facilities maintenance modules. | Critical | ||
| PP.2 | The system shall provide a public portal that can be customized to have a similar look and feel as the County website. | Critical | ||
| PP.3 | The system shall provide a public portal that is operational on a 24/7 basis. | Critical | ||
| PP.4 | The system shall have the ability to provide for multiple languages in the public portal including, but not limited to, English and Spanish. | Critical | ||
| PP.5 | The system shall provide a public portal that can be natively configured in multiple languages (e.g., not relying on translation tools). | Desired | ||
| PP.6 | The system shall provide a public portal that is fully ADA compliant. | Critical | ||
| PP.7 | The system shall generate and send email notifications of County-defined activity (e.g., successful submission, status changes, work order comments). | Critical | ||
| PP.8 | The system shall generate and send text notifications of County-defined activity (e.g., successful submission, status changes, work order comments). | Critical | ||
| PP.9 | The system shall generate and send notifications by multiple methods of County-defined activity (e.g., successful submission, status changes, work order comments). | Critical | ||
| PP.10 | The system shall display notice of successful submission to a user. | Critical | ||
| PP.11 | The system shall send an email notice of successful submission to a user that contains hyperlinks to the relevant areas of the public portal. | Critical | ||
| PP.12 | The system shall allow documents to be attached to online form submissions in accordance with the requirements described in the "General and Technical" worksheet. | Critical | ||
| PP.13 | The system shall allow the ability to configure certain fields as required fields within the online form submission functionality. | Critical | ||
| PP.14 | The system shall allow the County to define the level of detail that will be made available on the public portal. | Critical | ||
| PP.15 | The system shall provide a public web portal that is optimized for mobile use (e.g., device agnostic). | Critical | ||
| PP.16 | The system shall recognize the device that is being used to view the software to make the necessary window adjustments (e.g., screen optimization). | Critical | ||
| PP.17 | The system shall provide County contact information based on the step in the workflow process (e.g., division information, designated customer service staff for service request submission questions). | Critical | ||
| PP.18 | The system shall allow an authorized user to configure the public portal. | Critical | ||
| PP.19 | The system shall have the ability to embed links to the County website or other County applications. | Critical | ||
| PP.20 | The system shall have the ability to display County-defined contextual help to aid in the online request entry process. | Critical | ||
| PP.21 | The system shall provide an internal request portal that can be configured separately from the public facing portal (e.g., the service request types contain more detail and separate workflow than public portal request types). | Critical | ||
| PP.22 | The system shall provide an embedded map viewer, allowing for map based searches of information. | Critical | ||
| PP.23 | The system shall automate the classification process based on a series of yes or no answers to questions or key word identifiers via the portal (e.g., decision tree to help guide a resident to the correct service request type). | Critical | ||
| PP.24 | The system shall allow a user to save work in progress with the ability to edit prior to submission (e.g., log out and then log back in without losing information). | Critical | ||
| PP.25 | The system shall validate location prior to request submission to verify the location is within the County's jurisdiction before allowing submission, based on service request type (e.g., street repair request outside of County jurisdiction). | Critical | ||
| PP.26 | The system shall have the ability to categorize or view and report on service requests/work orders by County-defined geographical boundaries (e.g., Commissioner precinct, neighborhoods). | Critical | ||
| PP.27 | The system shall have the ability to add internal notes (i.e., not viewable by the public) to service requests/work orders submitted through the portal (e.g., gate code). | Critical | ||
| PP.28 | The system shall support user interface customization (e.g., wallpaper content, fonts, colors). | Critical | ||
| PP.29 | They system shall allow County staff to manage portal content and configuration changes without vendor involvement. | Critical | ||
| PP.30 | The system shall support API integration with other County applications. | Critical | ||
| PP.31 | The system shall support address standardization/validation to minimize errors in capturing location information. | Critical | ||
| PP.32 | The system shall provide the ability to configure County-defined auto-responses based on request type. | Critical | ||
| PP.33 | The system shall allow County staff to customize all notifications (e.g., wording and content, logos, fonts, colors). | Critical | ||
| PP.34 | The system shall support FAQ and Help features. | Critical | ||
| PP.35 | The system shall provide mobile application capabilities for iOS and Android devices. | Critical | ||
| PP.36 | The system shall support multiple file attachments to service requests/work orders. | Critical | ||
| PP.37 | The system shall have the ability for external/public users to be notified of status updates and comments related to their service requests/work orders via email or County-defined preferred delivery method. | Critical | ||
| PP.38 | The system shall allow County staff to create service requests/work orders on behalf of the public to ensure responses are returned to the original requestor. | Critical | ||
| PP.39 | The system shall have the ability to link multiple County staff members to a service request/work order. | Critical | ||
| PP.40 | The system shall have the ability to link multiple service requests/work orders together by location. | Critical | ||
| PP.41 | The system shall have the ability to close linked service requests/work orders at the same time with one closeout process. | Critical | ||
| PP.42 | The system shall have the ability to assign service requests/work orders to staff in a particular work group. | Critical | ||
| PP.43 | The system shall have the ability to geotag (e.g., drop a pin on a map) service requests/work orders. | Critical | ||
| PP.44 | The system shall have the ability to pull GPS location from a mobile device based on device permissions. | Critical | ||
| PP.45 | The system shall have the ability to view County-defined metadata from attachments submitted through the public portal. | Critical | ||
| PP.46 | The system shall have the ability to search and view a map-based interface and see current service requests/work orders to help reduce duplication. | Critical | ||
| PP.47 | The system shall support two-way communication for follow-up between the public and County staff. | Critical | ||
| Security-Enabled Functionality | ||||
| PP.48 | The system shall provide a security-enabled functionality set (e.g., user ID and password required). | Critical | ||
| PP.49 | The system shall use identity and access management to allow users to log-in using accounts like Google or Apple to access the portal. | Critical | ||
| PP.50 | The system shall use identity and access management to allow direct internal users to log-in using MS Dual Authentication. | Critical | ||
| PP.51 | The system shall allow certain information to be restricted for viewing only by users logged-in with appropriate credentials. | Critical | ||
| PP.52 | The system shall provide a single username/password combination that can be used for all security-enabled functionality. | Critical | ||
| PP.53 | The system shall require an authentication email to be acted upon in order to activate a new account. | Desired | ||
| PP.54 | The system shall allow anonymous submission of County-defined record types. | Desired | ||
| PP.55 | The system shall provide challenge-response test for all users prior to accessing the portal. | Critical | ||
| PP.56 | The system shall allow a user to view the status of a request after logging in. | Critical | ||
| PP.57 | The system shall allow for multi-factor authentication for public portal users. | Desired | ||
| PP.58 | The system shall allow authorized County users to restrict specific user accounts from submitting requests (e.g., a public user that submits obscenities). | Critical | ||
| PP.59 | The system shall pre-populate basic identity fields based on the account information stored with the user's ID/password. | Critical | ||
| The system shall provide comprehensive security-enabled functionality including but not limited to the following: | ||||
| PP.60 | Electronic submittal of requests and supplemental material; | Critical | ||
| PP.61 | View status of requests by type; | Critical | ||
| PP.62 | View and print/export approved requests; | Critical | ||
| PP.63 | View request status, results, and County-defined contact information; and | Critical | ||
| PP.64 | Other, County-defined. | Critical | ||
| Document Upload | ||||
| PP.65 | The system shall support the full digital submittal of requests and related documents. | Critical | ||
| PP.66 | The system shall have the ability to accommodate County-defined limitations on file size by file type. | Critical | ||
| PP.67 | The system shall allow files to be added to the public portal through drag-and-drop functionality. | Desired | ||
| PP.68 | The system shall allow requestors to optionally add comments for each document uploaded. | Critical | ||
| PP.69 | The system shall support the attachment of all file types identified in the General and Technical worksheet through the public portal. | Critical | ||
| PP.70 | The system shall support security scanning of attachments submitted through the public portal. | Critical |
&G &14Williamson County&"-,Bold"
&"-,Regular"Functional and Technical Requirements &G
Attachment B Page &P of &N Last Updated: December 22, 2025
3. Service Requests
| Indicator | Definition | Instruction | ||
| S | Standard: Feature/Function is included in the current software release and will be implemented by the planned phase go-live date as part of the proposal from Vendors in accordance with agreed-upon configuration planning with the County. | Respondents are encouraged, but not required, to provide additional information in the Comments column to further demonstrate the system’s ability to meet the requirement. | ||
| F | Future: Feature/Function will be available in a future software release available to the County by July 1, 2026, at which point it will be implemented in accordance with agreed-upon configuration planning with the County. | If a response indicator of “F” is provided for a requirement that will be met in a future software release, the Respondent shall indicate the planned release version, as well as the time the release will be generally available. | ||
| C | Customization: Feature/Function is not included in the current software release, and is not planned to be a part of a future software release. However, this feature could be provided with custom modifications. All related customization costs should be indicated in Attachment C1 – Cost Worksheet. | If a response indicator of “C” is provided for a requirement that will be met through a custom modification, the Respondent shall indicate the cost of such a modification. | ||
| T | Third Party: Feature/Function is not included in the current software release, and is not planned to be a part of a future software release. However, this feature could be provided with integration with a third-party system. This system should be specified. | If a response indicator of “T” is provided for a requirement that will be met by integration with a third-party system, the Respondent shall identify this third-party system and include a cost proposal to secure this system. If the third-party system is a part of the proposal, the third-party shall respond to the appropriate requirements using the “S”/”C”/”T”/”N” response indicators with a clear notation that the responses are provided by the third-party. | ||
| N | No: Feature/Function cannot be provided. | N/A | ||
| Service Requests | ||||
| Req # | Description of Requirement | Criticality | Respondent Response | Comments |
| General Requirements | ||||
| SR.1 | The system shall have the ability to provide a service request functionality that is integrated with other proposed system modules. | Critical | ||
| SR.2 | The system shall have the ability to generate and send email confirmations of user-defined activity. | Critical | ||
| SR.3 | The system shall recognize duplicate service requests and notify County staff to confirm whether to proceed with new service request entry. | Critical | ||
| SR.4 | The system shall have the ability to display notice of successful submission to a user. | Critical | ||
| SR.5 | The system shall have the ability to send an email notification of successful submission to a user. | Critical | ||
| SR.6 | The system shall have the ability to send an email notice of successful submission to a user that contains hyperlinks to the relevant areas of the system. | Critical | ||
| SR.7 | The system shall have the ability to send customized email notifications to the initiator of a service request and its subsequent work order. | Critical | ||
| SR.8 | The system shall have the ability to differentiate between service requests and work orders. | Critical | ||
| SR.9 | The system shall have the ability to transition service requests into work orders. | Critical | ||
| SR.10 | The system shall have the ability to allow documents to be attached to service requests in accordance with the requirements described in the "General and Technical" worksheet. | Critical | ||
| SR.11 | The system shall have the ability to attach multiple files (e.g., photos) to service requests. | Critical | ||
| SR.12 | The system shall have the ability to accommodate County-defined limitations on the size of file type. | Critical | ||
| SR.13 | The system shall have the ability to allow files to be added to the service requests through drag-and-drop functionality. | Critical | ||
| SR.14 | The system shall have the ability to capture location information that is not associated to an address, parcel, or asset (e.g., drop a pin for specific location of an issue). | Critical | ||
| SR.15 | The system shall have the ability to validate location prior to request submission to verify the location is within County-defined limits before allowing submission. | Critical | ||
| SR.16 | The system shall have the ability to validate location prior to request submission to verify the location is within County-defined limits before allowing submission, by service request or work group type. | Critical | ||
| SR.17 | The system shall have the ability to allow a user to view the status of a request/submission. | Critical | ||
| SR.18 | The system shall have the ability to configure target service request response times based on County-defined service request types. | Critical | ||
| SR.19 | The system shall have the ability to link related service requests based on user-defined time and distance parameters (e.g., link service requests within 500 feet). | Desired | ||
| SR.20 | The system shall have the ability to link related service requests by filtering on any discrete data field of other service requests (e.g., address, requestor name). | Critical | ||
| SR.21 | The system shall provide the ability to archive service requests and access archived service requests. | Critical | ||
| SR.22 | The system shall have the ability to convert service requests into work orders and maintain the linkage between the records throughout the lifecycle of the work order. | Critical | ||
| SR.23 | The system shall have the ability to print service requests either individually or in batches. | Critical | ||
| SR.24 | The system shall have the ability to allow emergency service requests to be placed in the front of any queues or batches or sent immediately to dispatch with appropriate security permissions | Critical | ||
| SR.25 | The system shall have the ability to schedule service requests by crew, date and/or time. | Critical | ||
| SR.26 | The system shall have the ability to provide an online calendar showing service requests scheduled by crew, area, date and time. | Critical | ||
| SR.27 | The system shall have the ability to generate a service request record from an email. | Critical | ||
| SR.28 | The system shall have the ability to assign service requests based on capacity and workload balancing according to County-defined workflow. | Critical | ||
| SR.29 | The system shall have the ability to advance schedule service requests based on County-defined criteria. | Critical | ||
| Reporting | ||||
| SR.30 | The system shall have the ability to search by service request number and drill down to associated details (e.g., type, requestor, associated work order). | Critical | ||
| SR.31 | The system shall have the ability to generate a master report of all service requests submitted. | Critical | ||
| SR.32 | The system shall have the ability to provide a master report of service request assignments by individual employee or work group. | Critical | ||
| SR.33 | The system shall have the ability to provide a graphical view of service request assignments by individual employee or work group. | Critical | ||
| SR.34 | The system shall have the ability to generate charts and graphs related to service request information. | Critical | ||
| SR.35 | The system shall have the ability to provide a "heat map" of locations of high service request volume and generate associated reports. | Critical | ||
| SR.36 | The system shall have the ability to generate a variety of reports based on asset, location, district, division, and/or other County-defined information. | Critical | ||
| SR.37 | The system shall have the ability to accommodate ad hoc reporting. | Critical | ||
| SR.38 | The system shall have the ability to notify and report on service request response times based on County-defined criteria. | Critical |
&G &14Williamson County&"-,Bold"
&"-,Regular"Functional and Technical Requirements &G
Attachment B Page &P of &N Last Updated: December 22, 2025
4. Work Orders
| Indicator | Definition | Instruction | ||
| S | Standard: Feature/Function is included in the current software release and will be implemented by the planned phase go-live date as part of the proposal from Vendors in accordance with agreed-upon configuration planning with the County. | Respondents are encouraged, but not required, to provide additional information in the Comments column to further demonstrate the system’s ability to meet the requirement. | ||
| F | Future: Feature/Function will be available in a future software release available to the County by July 1, 2026, at which point it will be implemented in accordance with agreed-upon configuration planning with the County. | If a response indicator of “F” is provided for a requirement that will be met in a future software release, the Respondent shall indicate the planned release version, as well as the time the release will be generally available. | ||
| C | Customization: Feature/Function is not included in the current software release, and is not planned to be a part of a future software release. However, this feature could be provided with custom modifications. All related customization costs should be indicated in Attachment C1 – Cost Worksheet. | If a response indicator of “C” is provided for a requirement that will be met through a custom modification, the Respondent shall indicate the cost of such a modification. | ||
| T | Third Party: Feature/Function is not included in the current software release, and is not planned to be a part of a future software release. However, this feature could be provided with integration with a third-party system. This system should be specified. | If a response indicator of “T” is provided for a requirement that will be met by integration with a third-party system, the Respondent shall identify this third-party system and include a cost proposal to secure this system. If the third-party system is a part of the proposal, the third-party shall respond to the appropriate requirements using the “S”/”C”/”T”/”N” response indicators with a clear notation that the responses are provided by the third-party. | ||
| N | No: Feature/Function cannot be provided. | N/A | ||
| Work Orders | ||||
| Req # | Description of Capability | Criticality | Respondent Response | Comments |
| General Requirements | ||||
| WO.1 | The system shall provide a Work Order module that is integrated with all other proposed system modules including (but not limited to) Service Requests, Inspections, Asset Management, Fleet Management, Facilities Maintenance, and Public Portal. | Critical | ||
| WO.2 | The system shall categorize work orders by fund, department, division, and other County-defined categories. | Critical | ||
| WO.3 | The system shall accommodate email or text notifications through all stages of workflow based on user-defined criteria (e.g., shift schedule) with ability to turn off or on based on user preference. | Critical | ||
| WO.4 | The system shall accommodate MS Teams notifications through all stages of workflow based on user-defined criteria (e.g., shift schedule) with ability to turn off or on based on user preference. | Desired | ||
| WO.5 | The system shall send customized email or text notifications to the internal (County) initiator of a service request and its subsequent work order. | Desired | ||
| WO.6 | The system shall send customized MS Teams notifications to the initiator of a service request and its subsequent work order. | Desired |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .