Department of Financial Management 411 West Ocean Boulevard, 6th Floor

Long Beach, CA 90802

(562) 570-6425

September 17, 2026

NOTICE TO PROPOSERS

ADDENDUM NO. 1: Q & A

No. RFP ER-26-719

Refuse Routes Software

This addendum changes and supersedes the language in the original RFP.

Please acknowledge receipt of this addendum by signing and submitting with your proposals. Any proposer who fails to submit this addendum may be disqualified.

The City would like to remind Proposers that pursuant to Section 5.2.27 of the RFP, the City will not be responsible for or bound by any oral communication or any other information or contact that occurs outside the official communication process specified herein, unless confirmed in writing by the City Contact.

The City would like to provide the following link to the Pre-Proposal Meeting:

Optional Pre-Proposal Meeting Video link: https://youtu.be/z4X0wMSTnCU

The questions and answers are as follows:

1. Q: The City currently uses Geotab location history. Does the City intend for the selected solution to consume existing Geotab vehicle/location data, replace portions of that functionality, or operate alongside Geotab? (Page 6)

A: The City currently uses Geotab as its telematics platform, primarily for vehicle location history and operational tracking. The City anticipates that the selected routing solution will operate alongside Geotab and is not expected to replace Geotab. Direct integration with Geotab is not a mandatory requirement for the proposed solution. However, Proposers may describe their ability to utilize Geotab data and any associated benefits, capabilities, or costs.

2. Q: The RFP requires integration with an active GPS navigation system. Will the

City accept a solution in which the route-optimization platform integrates with a third-party commercial navigation provider via API/SDK, rather than requiring the prime contractor to own the navigation technology? (Page 9) https://youtu.be/z4X0wMSTnCU

2 | P a g e

RFP ER-26-719

A: Yes. The City will accept a routing solution that integrates with a third-party commercial navigation provider through an API or SDK, provided the proposed solution meets all cyber security, navigation, operational, vehicle-routing, and safety requirements identified in the RFP. Proposers should identify any third-party navigation providers, licensing requirements, integration dependencies, or additional costs associated with their proposed approach.

3. Q: Beyond two-way streets, one-way streets, and other road restrictions, does the City expect the navigation engine to account for vehicle dimensions, weight, restricted roads, turn restrictions, vehicle-specific accessibility, or other commercial-vehicle constraints? The RFP currently specifies turn-by-turn navigation and re-navigation after route deviation. (page 10)

A: Yes. The City expects the proposed navigation solution to consider applicable operational and commercial vehicle constraints where available, including vehicle dimension, road restrictions, turn restrictions, accessibility limitation, and other restrictions that may affect the safe operation of collection vehicles.

4. Q: Solutions have you demo’ d recently, if any?

A: The City has performed market research and due diligence prior to the release of the RFP and is open to all solutions that meet the requisite scope of work and evaluation criteria as specified in the RFP.

5. Q: Does the City operate dedicated rear-load routes for alleys, or are alley stops mixed with curbside stops to be performed by the same vehicle? Are alley routes operated exclusively by rear-loaders now, or is that preferred?

A: The City's collection operations include both dedicated and mixed-service conditions. Alley service is primarily performed using rear-loader vehicles, while curbside service is primarily performed using side-loader vehicles.

However, vehicle assignments may vary based on operational needs and route conditions.

6. Q: For Oracle Customer Care & Billing: is there an existing integration layer/middleware in place (e.g., MuleSoft, an ESB), or would this be a direct API

3 | P a g e connection to CC&B? Is the exchange expected to be real-time (webhook-driven) or batch/scheduled?

A: Current Integrations with CC&B are both via direct API and Batch file. For the integration with a new routing software, the preferred method would be via a real-time API, however a batch interface could be explored if it met the needs of Energy and Environmental Services.

7. Q: Is Geotab expected to remain the City's telematics provider for the life of this contract, or is that under evaluation? Beyond location history, is there interest in pulling Geotab diagnostic/engine data into the routing platform?

A: Geotab is the City's current telematics platform. The City does not anticipate replacing Geotab as part of this procurement. The primary interest at this time is vehicle location and operational data. However, Proposers may describe additional capabilities for utilizing diagnostic or engine data where beneficial.

8. Q: Regarding "capable of supporting integration with future technologies, including on-truck camera systems” is there a specific platform or timeline already contemplated?

A: The City does not currently have a specific truck-mounted camera platform or implementation timeline identified for this project. The proposed solution should demonstrate the ability to support future integration with camera systems and emerging technologies.

9. How are multi-family accounts serviced today — individual carts collected like residential, or dumpster/commercial-style collection?

A: Multi-family accounts may be serviced using different collection methods depending on the property configuration and service requirements. This may include individual carts and/or container service. The proposed solution must be flexible enough to support varying services configurations.

10. Q: Does the City have current baseline data on hand (missed pickups, mapped service point accuracy, tonnage by route, etc.) to compare against the Phase

One targets in Section 2.2.1, or would establishing that baseline be part of

Phase One itself?

4 | P a g e

A: The City has existing operational data available from various systems, including Customer Care & Billing, ArcGIS, Geotab, weight tickets, and operational records. Establishing and validating the baseline measurements for performance metrics will be part of Phase One.

11. Q: Does the City operate dedicated rear-load routes for alleys, or are alley stops mixed with curbside stops performed by the same vehicle? Are alley routes operated exclusively by rear-loaders today, or is that a preference rather than a hard rule?

A: Please see the response to Question 5. Alley service is primarily associated with rear-loader operations, but this is not intended to be an absolute vehicle restriction. The proposed solution should evaluate operational conditions and support the appropriate vehicle assignment.

12. Q: In the RFP documentation you give the following information: 'A fleet of approximately 110 collection vehicles encompassing front-loaders, side loaders, rear-loaders, specialty vehicles'. Do you have a breakdown of the number of trucks in each of these classifications? How many side loaders etc.

A: Since the release of the RFP, the City’s collection fleet has increased. The current fleet includes approximately 48 automated vehicles, 39 rear-loader vehicles, 4 front-loader vehicles, 7 mini rear-loader vehicles, and additional specialty vehicles, including flatbed and scout trucks.

Although the City does not anticipate additional vehicle deliveries in 2026, the proposed solution should have the capacity to support a fleet of approximately 110 vehicles to accommodate future fleet growth and operational needs.

13. Q: Section 3.1 requires the Contractor to have successfully implemented solid waste routing optimization services for at least one jurisdiction with 100,000 or more service locations. Will the City accept an implementation for a private-sector solid waste operator or other collection organization serving 100,000 or more service locations, or must the qualifying implementation specifically be for a single lo governmental jurisdiction?

A: Yes. The City will accept qualifying experience with either a governmental jurisdiction or a private-sector solid waste collection organization. However, 5 | P a g e the Proposer must demonstrate successful implementation of solid waste routing optimization services for an operation serving 100,000 or more service locations and demonstrating comparable scale and operational complexity to the City's collection environment.

14. Q: Section 3.1 also requires a minimum of three client references with a

“similar service load. ” Please define what the City considers a similar service load. Must each of the three references individually serve approximately

100,000–134,000 service locations, or may references demonstrate comparable complexity through fleet size, route volume, mixed service types, municipal operations, or a combination of these factors?

A: "Similar service load" does not require each reference to serve the exact same number of service locations as the City. The City will consider comparable scale and complexity, including service locations, fleet size, route volume, mixed-service operations, residential and commercial collection, and other relevant operational characteristics.

15. Q: The RFP states that the City's current collection fleet consists of 87 collection vehicles and is expected to fluctuate to approximately 110 vehicles by the end of 2026, while the Scope of Work describes the project as supporting a fleet of approximately 110 vehicles. For purposes of licensing and the Cost Proposal, should Proposers base pricing on 87 currently active vehicles, 110 vehicles, or provide scalable unit pricing based on the number of active vehicles?

A: Proposers should base their Cost Proposal and proposed system capacity on a fleet of approximately 110 vehicles. While the City does not anticipate additional vehicle deliveries in 2026, the proposed solution should accommodate future fleet growth and operational needs up to approximately

110 vehicles.

Proposers should clearly identify the basis for any vehicle-based licensing or pricing, including applicable minimums, tiers, or scalable pricing, and identify any assumptions regarding changes in pricing based on fleet size.

16. Q: The current fleet is described as 87 vehicles, including 45 automated vehicles, 37 rear-loaders, and 3 front-loaders, with additional specialty vehicles

6 | P a g e

“to be detailed. ”Please provide the complete current fleet breakdown, including the remaining vehicle types, and, if available, the anticipated vehicle-type breakdown of the approximately 110-vehicle fleet expected by the end of

2026.

A: Since the release of the RFP, the City’s collection fleet has increased. The current fleet includes approximately 48 automated vehicles, 39 rear-loader vehicles, 4 front-loader vehicles, 7 mini rear-loader vehicles, and additional specialty vehicles, including flatbed and scout trucks.

The City does not anticipate additional vehicle deliveries in 2026 and does not currently have a finalized vehicle-type breakdown for future fleet growth.

17. Q: The Cost Proposal requires Contractors to submit costs for each phase of the project; however, Section 2.2.1 primarily defines Phase One, Phase Two, Phase Three, and Phase Four as performance-metric milestones rather than discrete scopes of work. Please provide or clarify the expected scope, deliverables, acceptance criteria, and duration of each project phase for purposes of preparing phase-based pricing.

A: The phases identified in Section 2.2.1 are intended to establish performance milestones throughout the project and are not intended to prescribe specific implementation activities or deliverables for each phase. Proposers should recommend an implementation methodology that identifies the major activities, deliverables, timelines, and acceptance criteria associated with each phase. Proposers should also provide phase-based pricing consistent with their proposed implementation approach.

18. Q: The Narrative Proposal Template asks Proposers to address “pilot testing, evaluation, and transition planning, ” but the Scope of Work does not define a required pilot. Does the City anticipate a pilot deployment? If so, please identify the anticipated number of vehicles, routes, teams, service locations, collection types, duration, and acceptance criteria for the pilot.

A: The City anticipates that the selected Contractor will include appropriate testing and validation prior to full deployment. The City does not currently prescribe a specific pilot size or duration. Proposers should describe their recommended pilot testing, evaluation, and transition approach as part of their implementation methodology.

7 | P a g e

19. Q: Please provide additional information regarding the required integration with Oracle Customer Care & Billing, including the Oracle CC&B version/environment, available APIs or integration methods, required data objects and fields, expected synchronization frequency, and whether the integration is expected to be one-way or bi-directional.

A: Current Integrations with CC&B are both via direct API and Batch file. For the integration with a new routing software, the preferred method would be via a real-time API, however a batch interface could be explored if it met the needs of Energy and Environmental Services. CC&B is hosted on-premises and the current version of CC&B is 2.7, however, the City is currently undergoing a project to upgrade to version 25.4 which is anticipated to be completed by May

2027. Any additional specific requirements for how the interface will function will be discussed during the discovery and requirements gathering portion of the project.

20. Q: Please clarify the expected level of integration with ArcGIS Pro and ArcGIS

Online. Is the routing solution expected to consume City GIS layers, publish optimized routes and updated service locations back to ArcGIS, maintain bi-directional synchronization with ArcGIS feature services, or simply support

GIS-compatible import/export?

A: Bidirectional synchronization with ArcGIS is not required for this proposal.

The City will consider routing solutions with the capability to export and import to and from ArcGIS.

21. Q: The Background states that routes are currently tracked using GeoTab location history, and telematics/GPS information is identified as a source for multiple performance measures. Is direct integration with the City's existing

GeoTab environment a required component of the proposed solution, or may the routing application use GPS data generated directly by the City's Samsung tablets for real-time vehicle tracking and route execution?

A: Direct integration with the City's existing Geotab environment is not a mandatory requirement for the proposed routing solution. The City will consider solutions that utilize GPS data generated by City provided tablets for real-time route execution and tracking. Proposers may also describe the

8 | P a g e benefits and capabilities of integrating with the City’s existing Geotab environment.

22. Q: Please confirm whether Oracle Customer Care & Billing, ArcGIS Pro/ArcGIS

Online, Microsoft Azure Single Sign-On, and potentially GeoTab constitute the complete set of integrations required for initial implementation and go-live.

A: The City's required initial integrations are Oracle Customer Care & Billing

(CC&B), ArcGIS Pro/ArcGIS Online, and Microsoft Azure Single Sign-On. Geotab is not a mandatory integration. Proposers should identify any additional interfaces, integrations, data sources, or third-party services required for their proposed solution to meet the RFP requirements and should clearly identify any associated costs or dependencies.

23. Q: The RFP requires tablet-based photo capture, future integration with truck-mounted cameras, and, beginning in Phase Two, “automated flagging” for access issues, contamination, blocked service points, and route deviations.

Please clarify whether automated flagging of contamination, blocked service points, and access issues is expected to be generated through operator-entered exceptions, business rules/telematics, or automated camera/computer-vision analysis.

A: For the initial implementation, the City does not require computer vision or automated camera analysis to generate flags. The City expects the proposed solution to support flagging of operational exceptions using available data sources, which may include operator-entered exceptions, business rules, GPS/telematics data, route-deviation information, and other system data. The solution should also be capable of supporting future integration with truck-mounted cameras, computer vision, and other emerging technologies.

24. Q: Please clarify whether photographic service verification is required at every serviced location or only when documenting exceptions such as contamination, blocked access, not-out conditions, or missed collections.

Please also specify the required photo retention period, preferred image quality/resolution, and whether photos must be made available within Oracle

CC&B, ArcGIS, or another City system.

A: Photographic documentation is primarily expected for service exceptions and operational issues, including contamination, blocked or restricted access, 9 | P a g e missed collections, and other service-related conditions. Photographs are not required at every serviced location unless proposed as part of the Contractor's solution. The City has not prescribed a specific photo resolution or retention period at this stage. Applicable photo storage, retention, security, and integration requirements will be established during implementation in accordance with City policies and applicable systems. Proposers should identify their proposed photo-storage approach, retention assumptions, integration capabilities, and any associated licensing, storage, or other costs.

25. Q: The RFP states that tonnage is currently manually entered from weight tickets received at four transfer stations, while the proposed solution must report tonnage by route. Please clarify the expected workflow for capturing tonnage under the new solution. Is the Contractor expected to integrate with transfer-station scale systems, electronically capture disposal tickets, allow operators to enter or photograph weight tickets through the mobile application, or receive tonnage information from another City system?

A: The City currently manually records tonnage information from weight tickets received at transfer stations. The City expects the proposed solution to provide a practical method for associating tonnage with routes. Proposers should describe their recommended approach, which may include integration, electronic data exchange, mobile entry, ticket capture, or other methods. The

City is not currently requiring integration with transfer-station scale systems unless proposed by the Contractor.

26. Q: Phase Three states that drive time, route mileage, service delays, and missed pick-ups are to be “reduced by 80%. ” Please confirm whether 80% is the intended target and whether this target applies individually to each of these four measures. Please also identify the baseline period and methodology that will be used to calculate these reductions.

A: Yes. The intended target is an 80% reduction for each measure individually:

drive time, route mileage, service delays, and missed pick-ups. Phase One will establish and validate the baseline period, data sources, measurement methodology, and calculation methods for each performance measure.

Performance in subsequent phases will be evaluated against the validated baseline for each individual measure.

10 | P a g e

27. Q: Please confirm the required customer support coverage. Sections 1.3, 2.1.2, 2.2.1, and 2.2.2 reference support Monday through Friday from 6:00 AM to

6:00 PM Pacific Time, while Section 2.1.7 requires on-demand customer support Monday through Saturday from 6:00 AM to 6:00 PM Pacific Time.

Should Proposers price and staff support coverage for Monday through Friday or Monday through Saturday?

A: The City requires customer and operational support coverage Monday through Saturday, from 6:00 AM to 6:00 PM Pacific Time, excluding Christmas and New Year's Day. Proposers should price and staff their support accordingly.

28. Q: Performance metrics require support requests to be acknowledged within

15 minutes and operational issues to be resolved within four hours, with later phases referencing these requirements across ticket types. Please confirm whether these response and resolution targets apply only to critical/production-impacting incidents or to all support tickets, including non-critical questions and enhancement requests. Please provide the applicable severity definitions and response/resolution targets by severity.

A: The 15-minute acknowledgment and four-hour resolution targets are intended to apply to critical or production-impacting operational issues. These targets are not intended to apply to routine questions, enhancement requests, or other non-critical support matters. Proposers should provide their proposed severity classifications and corresponding response, resolution, and escalation targets for critical, high, medium, and low-priority issues as part of their proposed Service Level Agreement.

29. Q: Please identify which implementation, operational analysis, training, go-live, and support activities the City expects to be conducted on site in Long Beach versus those that may be performed remotely. If on-site activities are required, please provide the anticipated number or frequency of on-site sessions for purposes of preparing the fixed Cost Proposal.

A: The City anticipates that certain implementation activities will require on-site participation in Long Beach, particularly operational analysis, field observation, initial training, testing, and go-live support. Other activities, including configuration, development, project meetings, and ongoing technical support, may be performed remotely where appropriate. Proposers

11 | P a g e should describe their proposed on-site and remote implementation approach and identify any associated assumptions.

30. Q: The RFP requires authorized staff to add, remove, edit, and reposition service locations within the routing solution while also requiring integration with Oracle CC&B and ArcGIS. Which system will serve as the authoritative system of record for service-location data, and how should changes made within the routing application be synchronized back to the City's source systems?

A: Oracle Customer Care & Billing (CC&B) will remain the authoritative system for customer account, billing, and service agreement information. ArcGIS will serve as the City's authoritative source for service-location geography and related GIS information. The routing solution will use the applicable service-location information from the City's systems and must allow authorized City staff to make operational routing and service-location adjustments. Changes made within the routing solution that affect service-location geography or operational routing information should be capable of being exported or synchronized to ArcGIS in accordance with the City's approved integration approach. Changes to customer account or billing information will remain managed through CC&B.

31. Q: The Cost Proposal requires pricing by project phase. For a SaaS solution that includes recurring software licensing in addition to one-time implementation and professional services, should Proposers separately identify (1) one-time implementation/integration costs by phase, (2) recurring annual software/subscription costs, and (3) optional services or modules?

A: Yes. Proposers should clearly separate and identify:

1. One-time implementation, integration, and professional services costs

2. Recurring software, subscription, licensing, maintenance, and support costs

3. Optional services, modules, or enhancements.

32. Q: Section 3.1 requires Proposers to be qualified to conduct business in the

City of Long Beach, while Section 4.2 identifies the City business license and

California Secretary of State registration as documents that may be submitted upon award. Please confirm that an out-of-state Proposer is not required to hold a City of Long Beach business license or California foreign-business

12 | P a g e registration at the time of proposal submission and may obtain these following notice of award.

A: An out-of-state Proposer is not required to obtain a City of Long Beach business license or California foreign-business registration solely for purposes of submitting a proposal. Applicable business licensing and registration requirements must be satisfied by the awarded Contractor in accordance with

City and State requirements following notice of award and prior to conducting business or performing services as required by law.

PREPARED BY:

Elisa Landeros

Elisa Landeros, Procurement Analyst II

ACKNOWLEDGED BY:

Company Name

Print Name Title

Signature Date