Vehicle_and_Operator_Scheduling_Requirements.xlsx
XLSX spreadsheet 51 KB Posted
- Solicitation number
- 471
- Issued by
- Los Angeles County, San Francisco City, California
About this file
This is a Vehicle and Operator Scheduling Requirements specification document for the City of Santa Monica's Big Blue Bus (BBB) system. The City is procuring a comprehensive fixed route vehicle and operator scheduling software system through an RFP released on April 16, 2026, with proposals due June 10, 2026, at 3:00 PM and questions due by May 6, 2026. The system must support 17 fixed routes operated by approximately 300 motor coach operators serving over 10 million annual passenger trips. The software must include GIS-integrated mapping capabilities for route definition and scheduling, vehicle blocking and run-cutting functionality, operator absence management and bidding processes, timekeeping and payroll processing, yard management with real-time vehicle tracking, and comprehensive reporting and analytics. The system must support Windows 10 and Windows 11 operating systems, modern web browsers including Chrome, Edge, Safari, and Firefox, and achieve WCAG 2.1 Level AA accessibility compliance. The contract will be awarded to a single qualified firm for an initial five-year term with two optional five-year renewal periods at the City's sole discretion.
Proposers must demonstrate at least five years of experience providing operator and vehicle scheduling software to comparable U.S. transit agencies and a minimum of two years of compatibility experience with Clever Devices CAD/AVL systems. The system must support at least 125 concurrent users and integrate with the City's existing technology infrastructure including Tyler Munis ERP, Clever Devices CAD/AVL, UKG workforce management, ServiceNow Platform, SharePoint, Laserfiche, and Tableau. The software may be deployed as local hosting, cloud hosting, or a full Software-as-a-Service model, with pricing provided for all three delivery options. A minimum one-year warranty from system acceptance is required, with optional extended warranties available for up to five additional years. The City reserves the right to reject any or all proposals. No specific award values or budget ranges are disclosed, and no incumbent vendors or set-aside designations are identified in the procurement documents. Proposers must comply with the City of Santa Monica's Living Wage Ordinance, prevailing wage requirements under California Labor Code, and non-discrimination policies.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Fixed_Route_Vehicle_and_Operator_Scheduling_Software.pdf | ||
| Fixed_Route_Vehicle_and_Operator_Scheduling_Software.pdf | ||
| Enterprise_Core_Technologies.pdf | ||
| Glossary.docx | DOCX document | |
| City_of_Santa_Monica_VISA_Questionnaire_3.1.docx | DOCX document | |
| Glossary.docx | DOCX document | |
| Software_as_a_Service_Template_(11-25).docx | DOCX document | |
| Software_as_a_Service_Template_(11-25).docx | DOCX document | |
| Technology_Services_Template.docx | DOCX document | |
| Technology_Services_Template.docx | DOCX document | |
| Vehicle_and_Operator_Scheduling_Requirements.xlsx | XLSX spreadsheet | |
| City_of_Santa_Monica_VISA_Questionnaire_3.1.docx | DOCX document | |
| Software_Maintenance_Agreement_Template.docx | DOCX document | |
| Architecture_Questionnaire.pdf | ||
| Enterprise_Core_Technologies.pdf | ||
| Software_Maintenance_Agreement_Template.docx | DOCX document | |
| Architecture_Questionnaire.pdf | ||
| Proposer_Checklist.pdf | ||
| Proposer_Checklist.pdf |
Show all 19
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
Vehicle Schd. Requirements
| Requirement ID | Category | Description | Can Comply (Y/N) / If No (N), Identify Exception and Reason |
| 1001 | User Interface and Mapping | The system shall include a mapping component which has the ability to import base map data including Route_Trace_Patterns, Transit_Centers, Layover_Points, Bus_Stops, Bus_Stop_Amenities, and Timetable creation. | |
| 1002 | User Interface and Mapping | The system's mapping component shall support point, line, and polygon Shapefiles. | |
| 1003 | User Interface and Mapping | The system's mapping component shall provide the ability for users to create, modify, and delete shapefiles. | |
| 1004 | User Interface and Mapping | The system shall allow users to draw or attach map images for off-street or internal facilities not shown in underlying maps. | |
| 1005 | User Interface and Mapping | When a new Geographic_Information_System (GIS) map street network is imported, the system's shall identify modifications to the street network and allow for the modifications to be saved. | |
| 1006 | User Interface and Mapping | The system shall possess a user interface for generating and displaying completed Vehicle_Schedules, which can be toggled between tabular and GIS map views. | |
| 1007 | User Interface and Mapping | The system shall provide configurable tabular views (moveable/resizable/sortable columns) for all Trip_Building, Blocking, Run_Cutting and Rostering modules. | |
| 1008 | User Interface and Mapping | The system shall have both “copy+paste” and “cut+paste” features allowing users to copy or cut data from one Schedule to another or within the same Schedule including one or more Trips, Blocks or Runs or a combination of Trips, Blocks, and/or Runs. | |
| 1009 | User Interface and Mapping | Within any system module, the system shall allow users to search for and filter by any associated attributes of Stops, Trips, Runs, and/or Blocks. | |
| 1010 | User Interface and Mapping | The system shall allow users to create datasets of any Trips, Blocks, Runs, Rules, attributes, parameters, or other data from any window based on their characteristics and produce statistics by groups based on selected parameters. | |
| 1011 | User Interface and Mapping | The system shall allow users to have two or more instances of the software or any individual schedule open at one time, preferably in a tabbed view. | |
| 1012 | User Interface and Mapping | The system shall allow any available Schedule version to be opened and displayed on demand. | |
| 1013 | User Interface and Mapping | The system shall record data validation or quality errors. | |
| 1014 | User Interface and Mapping | The system shall use consistent nomenclature (icons or names or both) throughout the system’s interface at all functional levels. | |
| 1015 | User Interface and Mapping | The system shall allow the user to create custom fields in any system module. | |
| 1016 | User Interface and Mapping | The system shall track schedule version history and allow rollback/restore of prior versions. | |
| 1017 | User Interface and Mapping | The system shall log all users and user actions for traceability. | |
| 1018 | Route Definition and Scheduling | The system shall be able to automatically assign Bus_Stops to Route_Patterns or Route_Segments between two or more Timepoints. | |
| 1019 | Route Definition and Scheduling | The system shall allow an unlimited number of Trip_Patterns to be defined as distinct Bus_Stop_Sequences. | |
| 1020 | Route Definition and Scheduling | The system shall allow users to designate selected Bus_Stops in each Trip_Pattern as schedule Timepoints. | |
| 1021 | Route Definition and Scheduling | The system shall allow users to manually override parameters for any Bus_Stop location, Trip, Block, or Run. | |
| 1022 | Route Definition and Scheduling | The system shall calculate distances of and display Route_Segments for Deadhead links, entire revenue Trip_Patterns, as well as any selected Trip_Pattern segments. | |
| 1023 | Route Definition and Scheduling | The system shall be able to show the distance, Planned_Travel_Time, and Segment_Speeds between sets of Bus_Stops or entire Trips | |
| 1024 | Route Definition and Scheduling | The system shall present a map display of all Trip_Patterns occurring within any date and time range defined by the user. | |
| 1025 | Route Definition and Scheduling | The system shall automatically generate turn-by-turn routing instructions for each separate Trip_Pattern to be displayed, exported, or printed on reports designated by users. | |
| 1026 | Route Definition and Scheduling | The system shall allow Routes to be defined as a sequence of Trips using selected Trip_Patterns during defined time periods. | |
| 1027 | Route Definition and Scheduling | The system shall allow users to specify the minimum and maximum Recovery_Times at specific Layover_Points. | |
| 1028 | Route Definition and Scheduling | The system shall allow for manual and system-proposed schedule refinements. | |
| 1029 | Route Definition and Scheduling | All relevant scheduling data and parameters (e.g. Stop_ID, Stop_Location, Length_On_Stops, etc) shall be merged and held in a common system database. | |
| 1030 | Route Definition and Scheduling | The system shall allow users to create and schedule Unique_Trips any time during a Sign-Up_Period. | |
| 1031 | Route Definition and Scheduling | The system shall provide suggested Running_Times based on current Block/Run data and historical Running_Time data. | |
| 1032 | Route Definition and Scheduling | The system shall provide predictive optimization (AI or rules-based) for running time and schedule refinement. | |
| 1033 | Route Definition and Scheduling | The system shall allow for system- or user-defined On_Time_Performance (OTP) parameters to be utilized for calculating and defining Running_Times. | |
| 1034 | Route Definition and Scheduling | The system shall be able to apply Run_Times to Trips and Trip_Segments based on the time of day the bus enters the Trip_Segment, instead of only based on the Trip start time. | |
| 1035 | Route Definition and Scheduling | The system shall allow users to manage any type of service, planned or unplanned. | |
| 1036 | Route Definition and Scheduling | The system shall allow users to create, activate, deactivate, rename, and edit Detours in a schedule. | |
| 1037 | Route Definition and Scheduling | The system shall allow for various types of services including, but not limited to, Revenue_Routes, Non-Revenue_Routes, Shuttles, and Special_Routes. | |
| 1038 | Route Definition and Scheduling | The system shall allow Route_Terminal_Point_Capacity_Limits to be configured by Line and total vehicles, and shall warn users if the capacity is exceeded when schedules are built. | |
| 1039 | Route Definition and Scheduling | The system shall allows users to categorize Timepoints as public and/or internal. | |
| 1040 | Route Definition and Scheduling | The system shall allow individual Bus_Stops to be set as active or inactive. | |
| 1041 | Route Definition and Scheduling | The system shall estimate bus Arrival_Times at Bus_Stops between designated Time_Points. | |
| 1042 | Route Definition and Scheduling | The system shall allow users to add comments to any vehicle scheduling system attribute, including, but not limited to: Time_Points, Bus_Stops, Patterns, Trips, Routes, Blocks, Operator Runs, and Rosters. | |
| 1043 | Route Definition and Scheduling | The system shall allow users to select any Time_Point as the build point for a route. | |
| 1044 | Route Definition and Scheduling | The system shall be able to display and/or modify all Trip_Path types and Segment_Speed_Factors on a GIS map or in table form. | |
| 1045 | Route Definition and Scheduling | The system shall allow users to export map views of modified Trip_Paths as .PDF or .jpeg file types. | |
| 1046 | Route Definition and Scheduling | The system shall allow for any point to be used for sorting in the schedule, even if the sort point is different from the build point. | |
| 1047 | Blocking | The system shall provide schedule validation engine to detect conflicts (orphan trips, unassigned blocks, inconsistent times). | |
| 1048 | Blocking | The system shall allow users to designate one or more yards/garages that can be attributed to specific Blocks. | |
| 1049 | Blocking | The system shall be capable of manual or automated Trip_Building using Route_Trip_Pattern_Sequences. | |
| 1050 | Blocking | The system shall allow users to modify, delete, or add trips to an existing schedule. | |
| 1051 | Blocking | The system shall be capable of automatically building Trips based on user-specified attributes. | |
| 1052 | Blocking | The system shall allow users to define one or more Exceptions to daily operating schedules. | |
| 1053 | Blocking | The system shall automatically assign or allow users to manually assign Trip and Block numbers. | |
| 1054 | Blocking | The system shall allow users to create and assign vehicle types to any Trip, Trip_Pattern, or Block | |
| 1055 | Blocking | The system shall allow for the application of minimum and maximum Recovery_Times as a fixed amount of time. | |
| 1056 | Blocking | The system shall allow for the application of minimum and maximum Recovery_Times as a percent of Running_Time. | |
| 1057 | Blocking | The system shall allow for the application of minimum and maximum Recovery_Times as a combination of fixed time and Running_Time. | |
| 1058 | Blocking | When the system is generating Blocking solutions, it shall optimize recommended Blocking solutions based on criteria (such as Vehicle_Types, minimizing Deadhead time, minimizing Total_Vehicle_Revenue_Hours, Total_Vehicle_Revenue_Miles, Interlining at multiple locations) as defined by the user | |
| 1059 | Blocking | The system shall allow both automatic and manual vehicle Block development based on user-defined variables. | |
| 1060 | Blocking | The system shall automatically validate that all Trips have been assigned to Blocks and notify the user about any missing assignment. Provide configurable tabular views (moveable/resizable/sortable columns) for all modules. | |
| 1061 | Blocking | The system shall allow users to add, modify, and delete notes on Trips, Trip_Time_Points, Blocks, or a selection set of any combination of these items. | |
| 1062 | Blocking | The system shall be able to generate multiple alternative Vehicle_Blocking_Assignments for the purpose of comparing alternative scenarios. | |
| 1063 | Blocking | The system shall include a scenario evaluation mode to compare alternative Blocking scenarios. | |
| 1064 | Blocking | The system shall allow the user to Unblock the Line and recreate Trips after the user has made a Blocking change. | |
| 1065 | Blocking | The system shall allow multiple Lines to be identified, viewed, and exported based on whether the Lines have common Time_Points, End_Points, or Segments. | |
| 1066 | Blocking | The system shall allow Lines to be grouped to be used for Interlining purposes. | |
| 1067 | Blocking | The system shall allow Trips and Lines to be Interlined, with the ability to create Deadheads between Line ends or segments to allow systemwide Interlining based on, but not limited to; common start/end points, common Vehicle_Types, Trip arrival/departure times vs. Deadhead times, etc. | |
| 1068 | Blocking | The system shall allow users to specify operational costs for Blocking scenarios including capital costs, system overhead and maintenance costs on a per mile or per hour basis. | |
| 1069 | Blocking | The system shall generate cost estimates by Routes, groups of Routes, or system-wide. | |
| 1070 | Blocking | The system shall allow users to build a new schedule from scratch. | |
| 1071 | Blocking | The system shall allow users to report on any trip, block, schedule. | |
| 1072 | Blocking | The system shall be capable of exporting trip and block numbers to downstream systems, external system, and reports. | |
| 1073 | Blocking | The system shall allow users to specify allowable vehicle types for certain Trip_Patterns or Blocks. | |
| 1074 | Blocking | Alternative Blocking scenarios shall be savable based on Sign-up_Periods. | |
| 1075 | Blocking | Previously saved scenarios shall be maintained such that they can be re-selected as the implementable scenario. | |
| 1076 | Run Cutting | The Run_Cutting module shall either be fully integrated into the overall vehicle scheduling system, or shall have a standard interface. | |
| 1077 | Run Cutting | The system shall allow users to create multiple custom Work_Assignment Run_Types (such as, full-time and part-time Runs, Extraboard assignments, vacation relief, etc.) | |
| 1078 | Run Cutting | The system shall allow for both driving and non-driving elements to be configured as part of a Work_Run. | |
| 1079 | Run Cutting | The system shall allow adjustments to Trip_Relief times to optimize Run_Cuts. | |
| 1080 | Run Cutting | The system shall be able to cut single-piece and multi-piece Work_Runs. | |
| 1081 | Run Cutting | The system shall allow Blocks to be split, swapped, truncated, extended, or otherwise modified as part of an automatic Run_Cutting process. | |
| 1082 | Run Cutting | Changes made during Run_Cutting shall be automatically reapplied through Blocking and Trip_Building without requiring the user to manually restart the process. | |
| 1083 | Run Cutting | The system shall have the capability to optimize the development of Operator_Runs based on the completed Block_List. | |
| 1084 | Run Cutting | The system shall have an “undo” / “redo” feature to revert back to previous Route_Schedule, Blocking_Scenario, or Run_Cut iteration made after a system save with options to undo beyond the last save point. | |
| 1085 | Run Cutting | The system shall ensure each Run has the same start and finish location, except where specifically overridden by a user. | |
| 1086 | Run Cutting | The system shall enable users to automatically and manually assign alphanumeric Run_Numbers which shall be made available to downstream systems. | |
| 1087 | Run Cutting | The system shall ensure there are no duplicate Run_Numbers. | |
| 1088 | Run Cutting | The system shall allow a custom Blocking and Run_Cutting numbering system to be used for numbering the City's Blocks and Work_Runs. | |
| 1089 | Run Cutting | The system's Run_Cutting module shall allow for the inputting of Work_Rules parameters that shall restrict the ability to apply non-conforming Runs. | |
| 1090 | Run Cutting | The system shall notify the user when a manual or automatically generated Run_Cut violates any applicable City business rule, management rule, operating rule and/or any applicable City labor agreement provision. | |
| 1091 | Run Cutting | The system shall allow users to define, modify, turn off/on, soft and hard Work_Rules. | |
| 1092 | Run Cutting | The system shall include a scenario evaluation mode to compare alternative Run_Cutting scenarios. | |
| 1093 | Run Cutting | The system shall automatically or allow users to manually generate Run_Cut scenarios from Blocks to optimize alternatives to achieve operational objectives defined by the user. | |
| 1094 | Run Cutting | The system shall allow users to configure Hard_Rules on specific parameters, while allowing levels of cost or hourly penalties per unit violation on Soft_Rules. | |
| 1095 | Run Cutting | The system shall allow Run_Cuts to be created for each Service_Day. | |
| 1096 | Run Cutting | The system shall allow users to lock selected Trips, Blocks and Runs, such that they will not be affected by any automatic system operation, and cannot be modified by manual operation unless the lock is first removed. | |
| 1097 | Run Cutting | The system shall allow for Rostering of Runs. | |
| 1098 | Run Cutting | The system shall allow users to create and apply custom work types. | |
| 1099 | Run Cutting | The system shall allow users to select from any of the generated Run_Cut alternatives to compare resulting costs for each scenario. | |
| 1100 | Run Cutting | The system shall suggest the optimal Run_Cut scenario | |
| 1101 | Reporting & Analytics | The system shall provide user-friendly and flexible reports as outputs. All reports shall be customizable to the City’s particular needs via the inclusion of desired data field(s). | |
| 1102 | Reporting & Analytics | If any 3rd party Business Intelligence tool is leveraged by the system for satisfying the report generation requirements, a developer license for this tool shall be provided to the City. | |
| 1103 | Reporting & Analytics | All reporting tools shall be directly accessible from the Vehicle Scheduling system’s main graphical user interface even if the Contractor leverages a 3rd party Business Intelligence tool to satisfy the City’s report generation requirements. | |
| 1104 | Reporting & Analytics | The system shall support the creation of reports that incorporate Exceptions. Exception reports shall show Service_Hours and Service_Miles by day including variances in Trips running on individual days. These reports shall configurable to any selected time period (Week, Month, Shake-Up, Fiscal or Calendar Year) to distinguish what trips are operating on each individual day. | |
| 1105 | Reporting & Analytics | The standard report templates provided shall have variable attributes/parameters which can be adjusted by City users via the system’s graphical user interface and subsequently saved as new report templates which can then be run going forward. | |
| 1106 | Reporting & Analytics | Standard Report templates shall be provided to aid City staff in fulfilling National_Transit_Database (NTD) reporting requirements including: | |
| i. Annual_Service_Days by service day type. | |||
| ii. Run_Rosters (for Operator signup). | |||
| iii. Trip_Patterns for each selected Run. | |||
| iv. Trip_Patterns for each selected Block. | |||
| v. Number of Trips by user-defined time periods. | |||
| vi. Vehicle_Miles, Revenue_Miles, Deadhead_Miles. | |||
| vii. Total Vehicle_Miles and Running_Times for each selected Trip_Pattern, between each Stop. | |||
| viii. Total Vehicle_Miles and Running_Times for each selected Trip_Pattern, between each Time_Point. | |||
| ix. Selected fields from the Bus_Stop definition (e.g. location, amenities, conditions) for each selected Bus_Stop. | |||
| x. Stops for each selected Trip_Pattern. | |||
| xi. Departure times for each Stop on each selected Run. | |||
| xii. Departure times for each Stop on each selected Block. | |||
| xiii. Vehicles_Operated_In_Annual_Maximum_Service (VOMS). | |||
| xiv. Time service begins and time service ends, for Routes or system-wide, by Service_Day, AM_Peak, midday, and PM_peak. | |||
| xv. Deadhead hours | |||
| 1107 | Reporting & Analytics | The system shall allow users to create vehicle schedule statistics and other statistical reports for user-specified time intervals (date range, Service_Day types, and/or day time periods or a combination of these) and user-specified days of the week or combination of specifications. | |
| 1108 | Reporting & Analytics | The system shall have the ability to access and print reports from any workstation. | |
| 1109 | Reporting & Analytics | All reports shall have the capability to be exported into common formats including .pdf, .xlsx and .docx | |
| 1110 | Reporting & Analytics | The system shall allow for the automatic generation of a peak vehicle usage report based on the information contained in the vehicle schedule for the current Shakeup period. Vehicles within the report shall be categorized by subtype (e.g. 30’ buses, several variants of 40’ buses, 60’ articulated buses and Battery Electric Buses), and the report shall return peak vehicle usage values for Weekdays, Saturday and Sundays. The output of the report shall be sortable by Line, Bus_Type, Pull_In and Pull_Out times. | |
| 1111 | Reporting & Analytics | The system shall produce printable Paddles based on any selected Run_Cuts. | |
| 1112 | Reporting & Analytics | The system shall produce a Run_Guide to assist Operators in selecting work during a bid process. |
Operations Sched. Requirements
| Requirement ID | Category | Description | Can Comply (Y/N) / If No (N), Identify Exception and Reason |
| 1113 | Absence Management | The system shall have separate modules to track paid time off accruals and absences. | |
| 1114 | Absence Management | The system shall reconcile absence codes from FMLA rules and the City's current and future ERP systems. | |
| 1115 | Absence Management | The system shall automatically extend the end date when the Operator has not been manually removed from the Long_Term_Absence_List to ensure the Operator is not prematurely reinstated in the system as available for Work_Assignment. | |
| 1116 | Absence Management | The system shall allow Motor_Coach_Operators to enter Planned_Absences and Unplanned_Absences into the timekeeping module via a secure website or mobile application. | |
| 1117 | Absence Management | The system shall allow users to view the list of Operators that cannot be assigned due to the Operator being absent. | |
| 1118 | Absence Management | The system shall allow users to remove an Operator's Work_Assignment when a Planned_Absence is approved or when an Unplanned_Absence is registered. | |
| 1119 | Absence Management | The system shall allow authorized users to maintain the list of Operators on the Long_Term_Absence_List. | |
| 1120 | Absence Management | The system shall allow users to enter future planned non-avalibilities during defined periods, such as mandatory training or official City or union business. | |
| 1121 | Absence Management | The system shall allow a pre-configured list of users to be notified of absence requests so the requests can be approved/denied. | |
| 1122 | Absence Management | The list of absent Operators shall display the duration of and reason for the Operator's absence. | |
| 1123 | Absence Management | The system shall allow authorized users to adjust the start and end date for which the Operator was unavailable for work assignment. | |
| 1124 | Absence Management | Operators on the Long_Term_Absence_List shall not be reinstated until manually reinstated by an authorized user. | |
| 1125 | Absence Management | When an Operator's request for Worker's Comp leave is granted, the system shall open up their work for the time requested | |
| 1126 | Bidding | The system shall provide assignment details for all bidded Work_Assignments throught the Operator_Web_Portal. | |
| 1127 | Bidding | In the bidding module, the system shall provide Operator with access to Vacation, Extra_Board and Work_Assignments as well as days off. | |
| 1128 | Bidding | The system shall have the ability to determine which Operators will participate in the Bidding process. | |
| 1129 | Bidding | In the bidding module, bidding period date/time thresholds shall be configurable. | |
| 1130 | Bidding | The bidding cut-off time needs to be configurable, even if the Assignment process is in progress. | |
| 1131 | Bidding | Users need to be able to move Operators from one bidding group to another without affecting Operator_Seniority. | |
| 1132 | Bidding | The system shall support Cafeteria_Style_Bidding. | |
| 1133 | Bidding | The system shall allow users to configure Shakeup_Period and allow bidding by operators during these predefined periods. | |
| 1134 | Bidding | The system shall allow users to configure and perform individual bids for runs that open up during a shake up period as needed by the transit agency at no additional cost. | |
| 1135 | Customer Comments, Commendations, and Complaints | The system shall have the ability to send email notifications at various steps during investigations of customer feedback. | |
| 1136 | Customer Comments, Commendations, and Complaints | Customer feedback records shall be customizable and, at minimum, contain the following fields: date, time, Operator, Route, Vehicle ID, Bus_Stop_ID, customer name, and customer phone number. | |
| 1137 | Customer Comments, Commendations, and Complaints | The system shall allow users to track activities and actions taken in response to the customer complaint/commendation and enable faster detection of recurring problems. | |
| 1138 | Customer Comments, Commendations, and Complaints | The system shall have the ability to email notifications and complaints. | |
| 1139 | Customer Comments, Commendations, and Complaints | The system shall allow for user configurable customer feedback categories. | |
| 1140 | Customer Comments, Commendations, and Complaints | The system shall allow the user to classify customer feedback by category. | |
| 1141 | Customer Comments, Commendations, and Complaints | The system shall allow the user to specify a priority level, status, and classification code for internal tracking of a customer feedback record. | |
| 1142 | Customer Comments, Commendations, and Complaints | The system shall provide the ability to attach or reference electronic documents to a customer feedback record, including .pdf, .xlsx, .docx, .jpg, .png and a reference to a video filename from BBB’s on-board bus security system. | |
| 1143 | Dispatch User Interface | The system’s user interface and functionality shall be consistent throughout and use common UI elements. | |
| 1144 | Dispatch User Interface | All tabular views in the system shall be dynamically resizable | |
| 1145 | Dispatch User Interface | The system shall allow each screen view to be printed and/or exported in common file formats, including but not limited to .csv, .xlsx, .txt, and .xml. | |
| 1146 | Dispatch User Interface | The system shall have a backend control panel that allows designated users to manage user accounts, user groups, and user roles. | |
| 1147 | Dispatch User Interface | The system shall log all users and user actions for traceability. | |
| 1148 | Dispatch User Interface | The system shall remember a user’s window arrangement such that the next time the user logs into the system, it will present the same window layout as before. | |
| 1149 | Dispatch User Interface | The system shall allow Operators to be assigned to Work_Assignments via drag-and-drop functionality. | |
| 1150 | Dispatch User Interface | The system shall have both “copy+paste” and “cut+paste” features allowing users to copy or cut data from one Work_Assignment to another or within the same view. | |
| 1151 | Dispatch User Interface | The system shall support undo/redo functionality which allows the previous operation to be completely reversed (or reapplied) at the user’s discretion. | |
| 1152 | Dispatch User Interface | The system shall have a real-time visual output to display current Operator_Assignments and Daily_Activities on external displays in the Operator check-in area. | |
| 1153 | Dispatch User Interface | The system shall allow users to have two or more instances of the software or any individual schedule open at one time, preferably in a tabbed view. | |
| 1154 | Dispatch User Interface | The employee management display (Daily_Activity_Display) shall include a table layout and a Gantt chart layout. | |
| 1155 | Dispatch User Interface | The system shall allow users to query Work_Assignments, employee profiles, parameters, settings, rules and other data from any window containing associated information. | |
| 1156 | Dispatch User Interface | Displayed data shall be sortable. | |
| 1157 | Dispatch User Interface | The system shall allow users to create queries and save them for future use. | |
| 1158 | Dispatch User Interface | The system shall allow the following four types of user access roles to be assigned to individual users or groups of users: read-only, read/write, restrictions on specific modules, and full control. | |
| 1159 | Dispatch User Interface | The system shall allow users to selectively lock certain database tables or records. | |
| 1160 | Dispatch User Interface | The system shall allow users to create queries and store queries for future use. | |
| 1161 | Labor Rules | The system shall automatically verify that Bids do not violate any established Work_Rules and notify designated users of potential Work_Rule violations. | |
| 1162 | Labor Rules | The system shall track and report Operator work hours such that Operator Assignments will not violate Work_Rules. | |
| 1163 | Labor Rules | The system shall provide an interface that allows designated users to configure custom Work_Rules. | |
| 1164 | Operator Assignments | The system shall allow users to create custom types of Work_Assignments. | |
| 1165 | Operator Assignments | The system shall show which Operator is currently assigned to each Run. | |
| 1166 | Operator Assignments | Within a configurable period of time before the Scheduled_Pullout, the system shall notify the user of any runs that do not have an assigned Operator. | |
| 1167 | Operator Assignments | The system shall not allow an Operator to be assigned to multiple Runs at one time and shall notify any user who attempts to assign an Operator to multiple Runs. | |
| 1168 | Operator Assignments | The system shall allow users to enter reasons for unassigning Operators from Runs. | |
| 1169 | Operator Assignments | When a user attempts to assign an Operator to a Run, the system shall automatically notify the user if the Assignment would violate defined City labor agreements and/or Work_Rules. | |
| 1170 | Operator Assignments | The system shall automatically display and update a list of Operators (including the Operator's contact information) available to fill unassigned Runs without violating defined Labor_Agreements and Work_Rules. | |
| 1171 | Operator Assignments | The system shall indicate when an Operator selection would result in overtime being paid, taking into account the Runs already assigned and/or completed during the current pay period. | |
| 1172 | Operator Assignments | Operator preferences regarding accepting overtime shall be automatically considered by the system and visually indicated in the Operator assignments module. | |
| 1173 | Operator Assignments | The system shall allow allow configuration of time periods when Operators are not available for assignment. | |
| 1174 | Operator Assignments | The system shall allow users to assign and/or reassign an Operator to future Runs and off days. | |
| 1175 | Operator Assignments | The system shall allow users to view operator Work_Assignments and time worked for the current pay period and for individual days. | |
| 1176 | Operator Assignments | The system shall allow designated users to sign Operators into the system. | |
| 1177 | Operator Assignments | If an Operator has not signed in within a configurable time period prior to the Scheduled_Pullout for an assigned Run, the system shall automatically unassign the Operator from the Run and notify a designated group of users (e.g. MCO Supervisors) | |
| 1178 | Operator Assignments | The system shall include a comprehensive Operator work calendar. | |
| 1179 | Operator Assignments | The system shall generate customizable Operator Paddles in a printable format. | |
| 1180 | Operator Assignments | The system shall be able to assign a Standby_Operator to replace the currently assigned Operator in the field. | |
| 1181 | Operator Assignments | The system shall automatically track the rotation of volunteers based on seniority and last work shift. | |
| 1182 | Operator Assignments | The system shall allow users to create and assign Special_Work_Assignments. | |
| 1183 | Operator Assignments | The system shall allow designated users to enter exceptions for each Operator (e.g. where an Operator is not authorized to be assigned to a particular Vehicle_Type). | |
| 1184 | Operator Assignments | The system shall warn of any relevant Operator accommodations requirements (e.g. a specific vehicle type) prior to generating an applicable Operator Work_Assignment. | |
| 1185 | Operator Assignments | The system shall allow for configuration of both Driving and Non-Driving elements as part of the Operator's workday. | |
| 1186 | Operator Assignments | The system shall show which Operators are not assigned to a Run. | |
| 1187 | Operator Assignments | The system shall automatically notify users of Runs where the assigned Operator has become unavailable and a new Operator must be assigned to cover the Run. | |
| 1188 | Operator Assignments | The system shall allow users to enter Assignments for any future dates within the current Shakeup_Period. | |
| 1189 | Operator Assignments | The system shall display real-time Operator sign-in status. | |
| 1190 | Operator Assignments | The system shall allow for the Assignment of a Standby_Operator to a Block; the Standby_Operator shall automatically be converted to the Primary_Operator in a Relief scenario. | |
| 1191 | Operator Assignments | The system shall automatically log the Absence_Code and issue a Miss-Out after replacing an Operator during an unplanned Relief scenario. | |
| 1192 | Operator Assignments | The system shall track the assignment of Vehicles to Blocks. | |
| 1193 | Operator Assignments | The system shall track pull out and pull in times for each Block via integration with Clever Devices CAD/AVL. | |
| 1194 | Operator Assignments | The system shall allow for the tracking of changes to the Vehicle and Operator Assignments throughout the day via manual entry from the user, including: |
i. What data items were changed and what each was changed to;
ii. Identify of the user who made each change; and
iii. The date and time of the change
| 1195 | Operator Assignments | The system shall allow users to define Staffing_Level_Requirements for the each day of regular or special service. |
| 1196 | Operator Assignments | The system shall allow users to maintain a daily calendar of Schedules in production. |
| 1197 | Operator Assignments | The system shall allow users to define holidays and associated work schedules. |
| 1198 | Operator Assignments | The system shall allow for configuration of relief time reporting limitations (in terms of vehicles and in terms of minutes) globally, by Routestart and end locations, schedule type, time of day, by individual Lines, and by location. |
| 1199 | Operator Assignments | The system shall analyze modes of travel (Pool_Cars, Pull_Reliefs, riding on buses currently in service, and/or a combination of these) for Operators between the facility and Relief_Locations to determine which mode is more efficient. |
| 1200 | Operator Assignments | The system shall track pool vehicle locations and Standby_Operator in use while making Relief |
| 1201 | Operator Assignments | The system shall track the assignment of Operators to Runs. |
| 1202 | Operator Assignments | The system shall allow users to view and identify any calendar-specific schedules planned to operate on a given day. |
| 1203 | Operator Assignments | The system shall have the ability to configure absence quotas for each work day. |
| 1204 | Operator Assignments | The system shall have the ability to auto approve absence requests at limits configurable by the agency. |
| 1205 | Operator Sign-in | The Operator sign-in solution shall interface with the Operator scheduling system and the vehicle scheduling system to access Work_Assignment details. |
| 1206 | Operator Sign-in | The Operator sign-in solution shall allow Operators to sign in using their unique City-assigned employee ID (alphanumeric) and a unique password. |
| 1207 | Operator Sign-in | Immediately after an Operator signs in to their daily Work_Assignment, the sign-in solution shall visually confirm that the sign-in is complete and display the sign-in time. |
| 1208 | Operator Sign-in | Immediately after an Operator signs in to their daily Work_Assignment, the system shall display the day's Work_Assignment for the Operator, the vehicle number that has been assigned to the initial Block for the Run, and the vehicle's parked location either in bus yard or at Relief_Location. |
| 1209 | Operator Sign-in | The system shall notify defined dispatchers when an Operator has not signed in prior to a City-configurable amount of time before the Operator's scheduled shift. |
| 1210 | Operator Sign-in | The Operator sign-in solution shall log all Operator interactions with the system. |
| 1211 | Operator Sign-in | Immediately after an Operator signs in to their daily work, the system shall automatically print a receipt with the day's Run_Assignment for the Operator, the vehicle number that has been assigned to the initial Block for the Run, and the vehicle's parked location in the bus yard, and a customizable message for the Operator. |
| 1212 | Operator Sign-in | The system shall allow Operators to "clock in" by tapping their RFID employee badge on an RFID card reader at designated sign-in workstations. |
| 1213 | Operator Sign-in | The Operator sign-in solution shall be web browser-agnostic and capable of running on any modern browser. |
| 1214 | Operator Sign-in | The Operator sign-in web application shall not require 3rd party plugins or tools for operation. |
| 1215 | Operator User Interface Portal | The Operator web portal shall allow users to access their personal information. |
| 1216 | Operator User Interface Portal | The Operator web portal shall allow users to submit absence requests and update accrual balances in real time. |
| 1217 | Operator User Interface Portal | The system’s Operator_Web_Portal shall allow the City to bundle in the following supplementary content in both web based and mobile versions: |
i. Online Operator training
ii. Training documentation
iii. Employee counseling
iv. Employee commendations and complaints (if applicable as per exercised Option)
vi. Medical certification and testing management
| 1218 | Operator User Interface Portal | The system shall be able to manage workers compensation absence requests via the Operator_Web_Portal with agency configurable standard forms. |
| 1219 | Operator User Interface Portal | With respect to bid results, the system’s Operator_Web_Portal shall show real time updates allowing operators to: |
i. View when their group’s Bids will be processed.
ii. See their ranking within the group (based on Operator_Seniority).
iii. View available Run_Numbers and sort them according to number, working or paid time, and days operated.
iv. Specify which positions they prefer and rank them in the Operator_Web_Portal accordingly.
| 1220 | Operator User Interface Portal | The Operator web portal shall allow users to select Bid_Units. |
| 1221 | Operator User Interface Portal | The Operator web portal shall allow users to submit Vacation_Bids. |
| 1222 | Operator User Interface Portal | The Operator web portal shall allow users to view a calendar displaying Daily_Assignments, days off, and absences. |
| 1223 | Operator User Interface Portal | The Operator web portal shall allow users to view and print records such as time card and a summary of vacations/absences. |
| 1224 | Operator User Interface Portal | The Operator web portal shall allow users to submit availability and preferences for overtime and on-call work. |
| 1225 | Operator User Interface Portal | The Operator web portal shall allow users to view informational messages. |
| 1226 | Operator User Interface Portal | The Operator web portal shall allow users to write up accident reports within the system. |
| 1227 | Reporting | The system shall provide daily Pay_Hour_Exception reporting. |
| 1228 | Reporting | The system shall provide the ability to do real time reporting based on Absence_Codes over customizable date ranges. |
| 1229 | Reporting | The system shall have the ability to create and customize reports. Report data shall be granular to tenths of an hour. The system shall provide the capability to export reports into various data type formats. Examples of reports to be supported shall include but are not limited to: |
i. Individual generic absence report with the capability to pull any combination of absence data for a specified date range.
ii. Total generic absence report with the capability to pull any combination of absence data for a specified date range.
iii. Sick or dependent care usage report with the capability to pull summary and detailed data by Operator for a specific date range.
iv. Individual accrual balance reporting with the capability to select all or a specific accrual type for a specific date range
v. Total accrual balance reporting by Operator with the capability to select all or a specific accrual type for a specific data range
vi. Total union official business hours with the capability to pull data for a specific date range
vii. Summary reporting by Operator for any timekeeping Pay_Code or Pay_Code combination for a specific date range.
viii. Detailed reporting by Operator for any timekeeping Pay_Code or Pay_Code combination for a specific date range
ix. Detailed Work_Run relief (Extra_Board, vacation relief Extra_Board and part-time) reporting for any timekeeping Pay_Code or Pay_Code combination for a specific date range
x. Detailed casual work reporting for any timekeeping Pay_Code or Pay_Code combination or a specific date range.
xi. Detailed Individual FMLA usage for a specific date range
xii. Total FMLA usage by Operator for a specific date range
| 1230 | Reporting | System shall have the ability to run a report for each leave type to display available accrual balance. |
| 1231 | Reporting | The system shall allow users to create and run customizable reports. |
| 1232 | Reporting | If any 3rd party Business Intelligence tool is leveraged by the system for satisfying the report generation requirements, a developer license for this tool shall be provided to the City. |
| 1233 | Reporting | All reporting tools shall be directly accessible from the Operator Scheduling system’s main graphical user interface even if the Contractor leverages a 3rd party Business Intelligence tool to satisfy the City’s report generation requirements. |
| 1234 | Reporting | As part of the system design and implementation, the vendor shall coordinate with City staff to develop standard reports. |
| 1235 | Reporting | The Contractor shall provide the City with a full database structure and field definitions for the system, in order to allow City users to create customized reports utilizing third-party software, at the City’s discretion. |
| 1236 | Reporting | The system users shall be able to generate reports on a daily basis with data from the previous 24 hours at a minimum. |
| 1237 | Reporting | Reports shall be filterable by user-selectable fields. |
| 1238 | Reporting | The standard report templates provided shall have variable attributes/parameters which can be adjusted by City users via the system’s graphical user interface and subsequently saved as new report templates. |
| 1239 | Reporting | The system shall allow a user to select a previously generated report as a template for the creation and generation of a new report. |
| 1240 | Reporting | The system shall allow for a distribution list and generation schedule to be configured by the City for each generated report. |
| 1241 | Reporting | The system shall be capable of exporting reports in the following standard formats: .pdf, .csv, .docx, .xml, and others as appropriate to the reports generated. |
| 1242 | Reporting | The system shall provide a bi-weekly report that lists employee pay hours by pay code and by division for each day within the previous two week period. |
| 1243 | Reporting | The system shall provide the capability to create, calculate and customize Timekeeping_Alerts (e.g. in-application notification, e-mail, SMS) on a daily, weekly, and bi-weekly basis. The following Timekeeping_Alerts are examples of what must be tracked and reported in both summary and detailed formats: |
i. Jury duty absence alert. The system shall alert the user when operators have been on jury duty for more than 10 days.
ii. Operators not entitled to holiday accrual.
iii. Operators not entitled to Easter Holiday pay. Operators are entitled to Easter Holiday pay after one year of employment
iv. Union official business meeting hours.
v. CALSIC/Kin care usage by both full-time and part-time operators.
vi. Long term Leave of Absence of more than 30 days. The system shall also alert the training staff when an Operator that’s been off work for more than 30 days and will be returning to work.
vii. No holiday pay alert. The system shall provide a list of Operators that did not receive holiday pay. This occurs when an Operator has a chargeable absence the day before, on or after the holiday and required documentation has yet to be received.
viii. Sunday substitution alert. The system shall provide a list of Operators with Sunday off who worked on a holiday that falls on a weekday. When a Sunday schedule is substituted for a holiday that falls on a weekday, the Operator is entitled to overtime pay) for working on the holiday even though the holiday fell on his/her regular work day.
ix. Absent without pay (AWP) / sick without pay (SWP) during a week with a holiday alert. The system shall provide a list of employees that are AWP/SWP during any week with a paid holiday. Overtime hours worked on a holiday that are equal to AWP/SWP hours incurred during the holiday week shall be adjusted to a straight rate.
x. YTD fiscal year union meeting usage in hours
xi. YTD Santa Monica official business usage in hours
| 1244 | Reporting | The system shall have the ability to create and customize queries. Query data shall be granular to tenths of an hour. The system shall provide the capability to export query results into various data types. |
| 1245 | Reporting | Prior to go-live, the system shall work with the transit agency to generate the following reports at a minimum: |
i. Operator_Assignments for each selected Run
ii. Run assignments for each selected Operator
iii. Vehicle_Assignments for each selected Block
iv. Block_Assignments for each selected vehicle
v. Vacation_Time_Assignments for a selected time period
vi. Vacation_Time_Assignments for a selected Operator
vii. Operator vacation availability for the annual Vacation_Bid
viii. FMLA departmental summary report
ix. Runs completed for the current pay period for each selected Operator (including hours worked/overtime and hours Operators have been paid for)
x. Blocks completed by each selected vehicle
xi. Vehicle circle check (Daily Vehicle Inspection Report) results summary 1246 Reporting Upon delivery of the system, the following report templates shown in Exhibit X, representing reports currently generated manually by the City, shall be pre-configured and available for running:
i. Timekeeping Queries
ii. Motor Coach Operator Absence Comparison Report
iii. Unscheduled Overtime Comparison Report
iv. Motor Coach Operator Vacation Bid (includes vacation availability, current vacation accrual balances, accrual rates)
v. Supplemental Time Card 1247 System Deployment Prospective bidders, if chosen, shall be prepared to provide the following:
i. Project Schedule.
ii. Integration plan with other City software, if applicable.
iii. Project management plan including method of communication and tracking project deliverables, status and reporting.
iv. Quality assurance plan.
v. Testing plan – Contractor shall thoroughly test the software solution for conformance with the scope of work and specifications, including integration with other City software systems prior to delivery to the City.
vi. Specifications for installation on City servers (where applicable under the non-SaaS or hosted delivery method)
vii. Training plan for each user group to include transfer of knowledge and recommended training resources.
| 1248 | System Deployment | Where installation of system software is required on City computers, the software shall be compatible with Windows 10, Windows 11, and all future Microsoft Windows operating system releases. |
| 1249 | System Deployment | For the server side processing, the system shall have the option of being locally hosted by the City in a virtualized server environment, or cloud hosted by the Contractor, or a full SaaS model, and pricing shall be provided for moving forward with all three different delivery models. |
| 1250 | System Deployment | For a multi-tiered architecture, all tiers shall provide secure encryption throughout the network. |
| 1251 | Timekeeping and Payroll Processing | The system shall support configurable Pay_Rules for the three types of BBB Operators: Full-time, Part-time, and Trainee and allow the ability to add different BBB Operator types as deemed necessary at no extra cost to the agency. |
| 1252 | Timekeeping and Payroll Processing | The system shall provide the ability for users to create Casual_Work_Assignments. |
| 1253 | Timekeeping and Payroll Processing | The system shall allow users to make timekeeping adjustments to current and previous work periods. |
| 1254 | Timekeeping and Payroll Processing | The system shall provide users the ability to override established system parameters. |
| 1255 | Timekeeping and Payroll Processing | The system shall allow designated users to adjust Work_Schedules on a weekly basis. |
| 1256 | Timekeeping and Payroll Processing | The system shall calculate Pay_Hours on a weekly and bi-weekly basis. |
| 1257 | Timekeeping and Payroll Processing | The bi-weekly employee pay hour data shall list daily, weekly and bi-weekly hours for each Operator up to 12 months as well as display total hours in hours:minutes or tenths by Payroll_Code. |
| 1258 | Timekeeping and Payroll Processing | The system shall have the ability to create, calculate and customize Premium_Pay_Codes defined by the City such as MTI (line instructor), ART (accident report premium), SV5 (supervisor premium) and CHP (log premium), and export these back into the City’s payroll system as a flat file. |
| 1259 | Timekeeping and Payroll Processing | The system’s FMLA module shall provide the capability to track FMLA usage rolling back 365 days, balance and certification parameters for operators and admin staff. The certification data field shall include a name, date range, relationship, leave (intermittent, continuous) and comment (for parameters) data field. The balance data fields shall include usage detail with a running balance. |
| 1260 | Timekeeping and Payroll Processing | The system shall provide a training class module that creates multiple pieces of Pay_Premium_Codes so that Transit Safety and Training can assign the training Pay_Premium_Codes to the class attendees. |
| 1261 | Timekeeping and Payroll Processing | Overrides to established system parameters shall be logged by date, user and time change occurred. |
| 1262 | Timekeeping and Payroll Processing | When converting between a weekly and bi-weekly basis, the system shall automatically account for Unpaid_Absences. |
| 1263 | Timekeeping and Payroll Processing | The system shall possess a Bid_Unit for Motor_Coach_Operator_Trainee. |
| 1264 | Timekeeping and Payroll Processing | The system shall sync information concerning Employee_Accrual_Hours in real time from the City's enterprise resource planning system. |
| 1265 | Timekeeping and Payroll Processing | The system shall allow designated users to edit Daily_Work_Schedules to accommodate mixed work schedules that may occur in any given week (e.g. both 10-hour and 8-hour work days in the same week) |
| 1266 | Timekeeping and Payroll Processing | The system shall have the ability to assign Work_Orders to Pay_Hours. |
| 1267 | Timekeeping and Payroll Processing | The system shall provide the capability for Operators to enter overtime hours through the Operator_Web_Portal when ending their shift late (e.g. arriving at the yard late due to traffic). This feature shall include an approval field so that the dispatch supervisor can approve the overtime once it’s been verified as valid. |
| 1268 | Timekeeping and Payroll Processing | The system shall have the ability to add, create and customize paid time off accruals and absences codes. |
| 1269 | Timekeeping and Payroll Processing | The system shall provide an adjustment module for entering previous pay period adjustments that interfaces with the City’s payroll system. |
| 1270 | Timekeeping and Payroll Processing | The previous pay periods adjustment module shall have an approval component that automatically updates the pay hours in the timekeeping system once the adjustment is approved. |
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 .