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

Long Beach, CA 90802

(562) 570-6425

August 28, 2025

NOTICE TO PROPOSERS

ADDENDUM NO. 4

RFP No. DV-25-556 Short Term Rentals Tech Solution

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.

Update to Section 2 Scope of Work > 2.1 Description of Services > System Security:

2. The solution system shall be Payment Card industry (PCI) compliant, and proof of compliance must be verified by the City prior to the final vendor selection process.

a. The Contractor shall provide an unexpired Attestation of Compliance (AOC) (or equivalent document) which is signed by an authorized executive of the Contractor organization.

b. The AOC form must leverage current PCI v4.0.1 requirements and include all

Contractor products and services to be utilized by the City of Long Beach.

c. If the Contractor is a PCI Level 1 merchant, the AOC (or equivalent document) must also be signed by a Qualified Security Assessor (QSA) in good standing with PCI

Council.

d. Third Party Contractor(s) whose system(s) have the ability to impact the Contractor’s system shall submit individual AOC(s) with the same requirements as the Contractor or are required to be listed and covered by the Contractor’s AOC.

e. A PCI v4.0.1 Responsibility Matrix must be submitted with each AOC by the Contractor and/or Third Party Contractor(s).

f. Proof of compliance shall be performed for each Contractor and/or Third Party

Contractor(s) by the City’s PCI Compliance Team.

g. Contractor and/or Third Party Contractor(s) with invalid AOC and Responsibility Matrix documents shall be requested to resubmit documents and/or participate in City PCI activities as requested.

h. If a Contractor and/or Third Party Contractor(s) do not resubmit valid documents by the due date, they may no longer be eligible to participate in the RFP.

Addendum # 4 RFP DV-25-556 Pg. 2

Update to Section 2 Scope of Work > 2.1 Description of Services > (New section) Payment Processing:

The solution system shall be able to process payment card payments online.

The questions and answers are as follows:

1. Q: What is the target go-live date for the solution? The RFP mentions 9/22/2025

A: The target go-live date will be on or before summer of 2026. The date in the RFP reflected the initial projection, and the schedule has since been adjusted to align with the updated plan.

2. Q: Can the City please provide a breakdown of estimated number of users who need access to the solution by user group? Examples include: Contact Center Agents, IT

Admin & Support Staff, Internal Users, External users, field staff who will go to fix the issue, Scheduler (who will be dispatching the field staff) etc.? What are the City's requirements for user roles and access levels within the new system?

A: In total, the City will require access to between 8-10 individuals at the outset. Most of these users will be administrative and supervisors, with some inspection staff. At this time, it is anticipated that all these users will require full access. The ideal scenario is the solution Proposer providing one or two City-users the authority to create new users and delegate access, however, the City would also be satisfied with a Proposer who can quickly respond to access changes and add/remove users if needed.

3. Q: With respect to Data Migration & Consolidations, can you please share the volume of data that would be required to be migrated from legacy system?

A: A data migration would include the following records:

• All application data. Currently there are 4,100+ application records as of August

4. All applications have been submitted electronically and have 40-45 ‘fields’ of data that would need to be carried over. One of these fields is a comment field with timestamped notes and attachments. At the very least, we would require the comments and their timestamps to be migrated. The City would prefer the attachments to be transferred, but it is not required.

• All payment data. We have almost 20,000 payment records, and similarly, there would be 40-45 fields of data that would need to be migrated.

• STR hotline calls. We have ~700 hotline call records that would need to be migrated. While there are fewer fields associated with these calls, each call record has a downloadable audio recording that the City would need to migrate.

Like the applications, these records also have a comment field with timestamps that should be migrated.

4. Q: Provide more details in regard to ‘Third-party integrations:

Pg. 3

a) How many integrations are required in total (e.g. GIS, property database system, financial accounting system etc.) needs to be integrated with the new Short Term

Rental Solution? Please provide name for each.

A: For integrations, the City is predominantly interested in how the Proposer will assist with collecting and remitting payments to the City. While the City currently uses Stripe to collect and remit payments for short-term rentals, as it is tied to the current solution, the City may consider other integration options provided they are functional for the needs of the City.

b) Should the integration be one-way or two-way, and will any middleware be necessary?

A: At minimum, the Proposer should be open to using a middleware to collect payments, however the City will consider one-way or two-way integration proposals.

c) With respect to the ‘Integration with telephony systems’, please clarify which telephony system is currently in use and will require integration for telephony system setup. Also, if applicable, share the use cases/business requirement for call logging and recording.

A: The City does not retain a ‘telephony system’ that requires integration for this service.

5. Q: What online payment methods does the City want to support (e.g., ACH, credit card, digital wallets)? Are there any payment processors or gateways the City prefers or is contractually obligated to use?

A: The City currently uses Kubra and Stripe to collect online payments, but there is no obligation to use either of those services. Of these, Stripe would be preferred as this is the service that STR staff are most familiar with. If using a third-party collection/remittance processor, the City would prefer as many PCI online payment options as possible to assist the customers.

6. Q: What are the City’s requirements and expectations for offering, managing, and enforcing payment plans, including eligibility criteria, plan structure (standard or custom), and handling of missed or late payments?

A: For renewal registrations there will be no payment plans. ‘Missed’ or ‘late’ payments would be handled administratively by the City.

Payment-plan agreements for delinquent Transient Occupancy Tax (TOT) accounts are managed individually at the City’s discretion by the Department of Financial Management. To be considered for a plan, the business must first file all overdue TOT returns. Once reporting is current, the business submits a formal hardship application that explains its financial situation and includes a proposed schedule of monthly payments. If approved, the City may extend up to 12 months to repay the full outstanding balance, with installment amounts due on the regular monthly filing dates. The

Pg. 4 agreement is conditional on adherence to its terms. Any missed payment or newly unpaid TOT filing will automatically void the plan, return the account to delinquent status, and may trigger enforcement actions. For handling, it would be ideal if there were an option in the system for City staff to waive delinquency penalties prior to payment.

7. Q: Section 1.3 Goals and Section 2.2.1 Performance Metrics both speaks to the need to shorten registration review times. Could you provide some information on the current manual review process? what are the most time-consuming or error-prone verification steps currently?

A: Much staff time is lost due to customer input errors. For instance, the customer will submit a new application instead of renewing their current application. Since payment is made/collected and a record is created, this leads to significant effort to correct the error, including working with applicant to re-submit or contacting the vendor to correct the record and move the payment, as well as sometimes working with internal staff for a refund which, for financial control purposes, can only be made by cutting and mailing a check. This process often results in customers receiving a second registration number, which leads to more confusion and inconsistency in TOT reporting. The snowball effect of a single error consumes substantial staff time. Ideally, the proposer would provide a straightforward solution to this common mistake.

8. Q: Section 5.3, Item 12 - Seamless integration and compliance with the City's data ownership and security requirements - What is the City's preferred technology environment and data exchange protocol?

A: Azure DevOps

9. Q: In the evaluation criterion the ease of operation and ability of the city to independently manage the solution – Does the city have the staff who can directly configure and adjust any AI or rules that the automated system uses?

A: It is not anticipated that the City would need to adjust any AI. As it relates to managing the solution, the City would like the capability to manage items which they have direct knowledge of to improve function. For instance, in a solution where county property records are integrated into the system, the City would prefer to be able to modify those records. One reason of many for this is, throughout the year, the City receives requests to block certain properties from applying. It is quicker in this scenario for the City to modify a database versus reaching out to their vendor counterparts to enact the change.

With regards to configuring automated systems, the City would be hopeful that staff could at least modify trigger criteria in some cases, such as dates or statuses. As an example, if the City wanted to stop accepting non-primary registrations for any property residing in a particular Census Tract, the City would be able to modify the application to reject those applications and provide a rejection message for those applying. There may also be configurations with date-based notifications that the City may need to change in the future. For instance, for a STR registrant to renew, currently the ordinance requires payment 30 days before their current registration expires once the non-primary registration cap is met. Since the cap has not been met, the City does not currently enforce this provision, however, in the event that the City reaches this limit, this payment

Pg. 5 due date would be enforced and City users should be able to change the solution to match this change in enforcement.

10. Q: The Solution Component #2 item 1 state the solution to “Provide the ability to correctly match online short-term rental listings to existing properties, with human verification of each listing identified and justification of matching criteria used” - We would like to confirm that the verification here refers to review and not to matching

A: The City accepts that AI and algorithms are predominantly used in this industry to identify and match listings to properties. The request here is that after the match is made by the software, a human will review the match and confirm the result of the match. So, yes, the human verification is to the review of the machine matching.

11. Q: Could the City please confirm the total number of new applications or renewals expected on an annual basis?

A: New applications would be approximately 450 per year. Renewal applications would be approximately 700 per year if current trends hold.

12. Q: Could the City confirm what integration would be required to support SSO?

A: The integration required would be with Azure.

PREPARED BY: Janet Kariuki, Procurement Analyst I

ACKNOWLEDGED BY:

Company Name

Print Name Title

Signature Date