RFI_Response_Template.docx

SPD RFI Response — Parking Enforcement Modernization & ALPR

RESPONSE TO REQUEST FOR INFORMATION (RFI)

Parking Enforcement Modernization and Automated License Plate Recognition (ALPR) Solutions Issued by the Seattle Police Department (SPD)

RFI Reference Information

Date submitted

Responding Vendor Company / legal name

Product / solution name

Primary contact

Title

Email

Phone

Mailing address

Website

Authorized signatory

Instructions to Responder This document mirrors the structure of SPD’s RFI. Complete the shaded and bordered response areas below each question. This RFI is for market research only; it is not a solicitation for bids, pricing proposals, or contractual commitments.

How to use this form:

1. Type directly into each “[ Enter response here ]” box. Boxes expand as you type; there are no length limits, but concise, specific answers are preferred.

1. For Section 3.1 (Mandatory ALPR Compliance), check the capability status for each requirement, add a target date for anything marked “Roadmap,” and describe how the requirement is met in the response box beneath it.

1. Where a capability is delivered through a third-party product, identify the product and describe how it is licensed, supported, and integrated.

1. Sections 3.3 C–F include capability checklists: mark a status for each listed capability, then use the notes box for the “how it works” detail.

1. Attach supporting material (architecture diagrams, sample reports, references) as clearly labeled appendices.

Capability statuses (used throughout this form):

Note: “Supported” represents that the capability exists in the current shipping product. Roadmap items should be accompanied by a realistic target date.

Table of Contents

Vendor Snapshot Complete this one-page summary (we suggest filling it in last). It gives evaluators an at-a-glance view of your solution for quick side-by-side comparison; every figure here should also be supported in the detailed sections that follow.

Company / product name

Deployment model (SaaS / cloud / on-prem / hybrid)

Hosting / data residency

Mobile platforms supported

No. of parking-enforcement implementations

No. of municipal customers (total)

Largest / most comparable agency (name & size)

Typical implementation timeline

System uptime (%, excl. scheduled maintenance)

Primary integration methods

ALPR compliance summary (___ of 12 “Supported”)

Cooperative purchasing (Yes / No; vehicle)

2. Purpose and Background Purpose and Background

2.1 Introduction

SPD issued this RFI to gather information about commercially available technologies that support modern parking enforcement operations. This section confirms the responding vendor’s understanding of the RFI’s purpose and scope.

Guidance: Briefly confirm your understanding of the RFI’s purpose and note anything about your company or solution the City should keep in mind while reading this response.

[ Enter response here ]

2.2 Project Background

Parking Enforcement currently relies on multiple systems, data sources, and manual processes across citation issuance, ALPR, permit validation, payment verification, GIS-based enforcement, court workflows, customer service, and reporting. SPD is evaluating opportunities to modernize by reducing manual work and improving interoperability, efficiency, and field tools.

Guidance: Describe, at a high level, how your solution aligns with SPD’s modernization goals: reducing manual work, improving interoperability, and enhancing tools for field staff and supervisors.

[ Enter response here ]

3. Requested Information

3.1 Mandatory ALPR Compliance Capability

Washington’s ESSB 6002 (chapter 10.130 RCW) establishes statewide requirements governing ALPR technology. The City is also subject to Seattle’s Surveillance Ordinance (SMC 14.18) and applicable City-approved ALPR policies. The City intends to provide and maintain mapping of designated no-collection zones around sensitive facilities.

For each mandatory requirement below, check the capability status, add a target date for any roadmap item, and describe how the requirement is met (identifying any third-party product involved). Attach supporting detail as a labeled appendix if a response needs more room.

3.1.1 Configures and applies City-provided maps of designated no-collection zones.

Capability status (check one):

Supported | Config | Custom | Roadmap | Not available Target date (if on roadmap):

Describe how this requirement is met, and identify any third-party product involved:

[ Enter response here ]

3.1.2 Prevents ALPR data collection when equipment is operating within a designated no-collection zone.

Capability status (check one):

Supported | Config | Custom | Roadmap | Not available Target date (if on roadmap):

[ Enter response here ]

3.1.3 Updates designated no-collection zones as legal requirements and City mapping evolves.

Supported | Config | Custom | Roadmap | Not available Target date (if on roadmap):

[ Enter response here ]

3.1.4 Validates that geofencing / no-collection-zone controls function correctly after implementation and after subsequent mapping or configuration updates.

Supported | Config | Custom | Roadmap | Not available Target date (if on roadmap):

[ Enter response here ]

3.1.5 Supports auditing and exportable reporting of geofencing and no-collection-zone compliance.

Supported | Config | Custom | Roadmap | Not available Target date (if on roadmap):

[ Enter response here ]

3.1.6 Supports configurable data-retention schedules and automated deletion; deletes ALPR parking-enforcement data no later than 12 hours after final disposition, including exhaustion of appeals (§4(2)).

Supported | Config | Custom | Roadmap | Not available Target date (if on roadmap):

[ Enter response here ]

3.1.7 Provides technical controls against unauthorized access or use, including unauthorized data sharing, secondary transfer, or access by nonauthorized agencies (§5(6)).

Supported | Config | Custom | Roadmap | Not available Target date (if on roadmap):

[ Enter response here ]

3.1.8 Prevents selling, leasing, renting, or otherwise allowing access to ALPR data by any nonauthorized agency, person, or entity (§5(7)).

Supported | Config | Custom | Roadmap | Not available Target date (if on roadmap):

[ Enter response here ]

3.1.9 Logs every access to / query of the system (user identity & affiliation, date/time, query data elements, purpose, call-for-service or case number, camera location); logs exports, downloads, and sharing; makes vendor audit-trail data available to the City; retains audit data ≥ 2 years (§8).

Supported | Config | Custom | Roadmap | Not available Target date (if on roadmap):

[ Enter response here ]

3.1.10 Allows authorized users to manually suspend and resume ALPR collection, with associated permissions, supervisory controls, and audit logging.

Supported | Config | Custom | Roadmap | Not available Target date (if on roadmap):

[ Enter response here ]

3.1.11 Limits collection to the intended enforcement area; prevents capture from private lots, no-collection zones, or unauthorized locations, including near zone boundaries; includes associated configuration/control capabilities.

Supported | Config | Custom | Roadmap | Not available Target date (if on roadmap):

[ Enter response here ]

3.1.12 Defaults all data-sharing settings to prevent unauthorized sharing; requires the City's knowledge and explicit consent before any vendor change, including software updates, that may affect sharing permissions (§5(8)).

Supported | Config | Custom | Roadmap | Not available Target date (if on roadmap):

[ Enter response here ]

Additional ALPR compliance notes (optional) Guidance: Use this space for any cross-cutting information about your ALPR compliance approach that is not tied to a single requirement above — for example, overall architecture for geofencing, audit logging, and data retention.

[ Enter response here ]

3.2 Current Environment

SPD operates multiple independent systems supporting: parking citation issuance; ALPR; GIS and curb regulation; data analytics; residential and commercial permit programs; parking payment systems; physical chalking for time-limit enforcement; court case processing; scofflaw enforcement; hotsheet and officer-safety alerts; customer service requests; reporting and analytics; vehicle towing and impound workflows; and daily reports of activities by enforcement officers.

Guidance: Note which of these functions your solution supports natively, which it integrates with, and which are out of scope. This helps the City understand coverage and integration effort.

[ Enter response here ]

3.3 Requested Information

A. Solution Overview Guidance: Cover: primary capabilities; overall system architecture; deployment model (SaaS, cloud, on-premises, hybrid); mobile capabilities (iOS vs Android, cell phone vs dedicated ticket writer); the types and sizes of agencies currently using your solution (with examples of similar size and scope); and how your solution differs from traditional parking enforcement platforms.

Deployment model (check all that apply):

SaaS | Cloud (hosted) | On-premises | Hybrid Mobile platform / hardware (check all that apply):

iOS | Android | Cell phone | Dedicated ticket writer [ Enter response here ]

B. Parking Enforcement Modernization Guidance: Describe how your solution modernizes operations — e.g., reducing manual processes and paperwork, streamlining officer workflows, improving efficiency and officer safety, increasing data quality, supporting future growth, integrating with other software, and protecting the public’s privacy. Call out capabilities that distinguish your platform from traditional solutions.

[ Enter response here ]

C. Citation and ALPR Workflow Mark the status for each capability your solution provides:

License plate recognition Supported | Config | Custom | Roadmap | Not available Citation issuance Supported | Config | Custom | Roadmap | Not available Simultaneous evaluation of multiple parking restrictions Supported | Config | Custom | Roadmap | Not available Permit verification Supported | Config | Custom | Roadmap | Not available Parking-payment verification Supported | Config | Custom | Roadmap | Not available Scofflaw identification Supported | Config | Custom | Roadmap | Not available Officer-safety alerts Supported | Config | Custom | Roadmap | Not available Citation lifecycle management Supported | Config | Custom | Roadmap | Not available Mobile workflows Supported | Config | Custom | Roadmap | Not available Then describe the operator controls available during ALPR enforcement — configuring or selecting the capture area, side of the street, direction of travel, and the parking restrictions being enforced.

[ Enter response here ]

D. GIS, Mapping, and Geofencing

GIS-based enforcement Supported | Config | Custom | Roadmap | Not available Dynamic curb regulations Supported | Config | Custom | Roadmap | Not available Blockface / side-of-street restrictions Supported | Config | Custom | Roadmap | Not available Residential permit zones Supported | Config | Custom | Roadmap | Not available Temporary parking restrictions Supported | Config | Custom | Roadmap | Not available Temporary No Parking Zones Supported | Config | Custom | Roadmap | Not available Permit layers Supported | Config | Custom | Roadmap | Not available Geofencing Supported | Config | Custom | Roadmap | Not available GIS visualization Supported | Config | Custom | Roadmap | Not available Then explain how GIS information is maintained, how updates are applied, how quickly changes reach the field, and how users verify GIS accuracy. Name any third-party GIS dependencies.

[ Enter response here ]

E. System Integration

Permit management Supported | Config | Custom | Roadmap | Not available Court systems Supported | Config | Custom | Roadmap | Not available GIS platforms Supported | Config | Custom | Roadmap | Not available Parking-payment systems Supported | Config | Custom | Roadmap | Not available Customer-service request systems Supported | Config | Custom | Roadmap | Not available CAD / dispatch systems Supported | Config | Custom | Roadmap | Not available Reporting platforms Supported | Config | Custom | Roadmap | Not available Business intelligence platforms Supported | Config | Custom | Roadmap | Not available Then describe standard APIs, batch vs real-time support, the typical approach for new integrations, and support for future integrations. Identify any third-party products required and how they are licensed, supported, and integrated.

[ Enter response here ]

Integration methods available (check all that apply):

REST API | SOAP | Webhooks | SFTP / flat-file | Batch | Real-time F. Reporting and Analytics Mark the status for each capability your solution provides:

Operational dashboards Supported | Config | Custom | Roadmap | Not available Management reporting Supported | Config | Custom | Roadmap | Not available GIS visualization Supported | Config | Custom | Roadmap | Not available Compliance analysis Supported | Config | Custom | Roadmap | Not available Deployment analysis Supported | Config | Custom | Roadmap | Not available Enforcement-trend analysis Supported | Config | Custom | Roadmap | Not available Operational performance metrics Supported | Config | Custom | Roadmap | Not available Business intelligence Supported | Config | Custom | Roadmap | Not available Logging and audit trails Supported | Config | Custom | Roadmap | Not available Then provide examples of how agencies use these capabilities to improve operations.

[ Enter response here ]

G. Towing and Impound Workflows Guidance: The City does not currently use an integrated electronic towing workflow for Parking Enforcement. Describe how your solution supports or could integrate with electronic towing/impound processes — e.g., electronic tow requests, tow-status updates, electronic documentation, impound tracking, and integration with current or future third-party towing software — and identify any technical or operational dependencies.

[ Enter response here ]

H. Future Innovation Guidance: Describe existing or planned capabilities beyond current operational needs: parking-occupancy analysis, curb-utilization analysis, transportation planning, sign inventory/validation, operational planning, workforce-deployment optimization, artificial intelligence, and machine learning. Include any additional capabilities you believe the City should consider, even if not specifically requested.

[ Enter response here ]

I. Solution Demonstration Guidance: If selected for a demonstration, list the capabilities you would show to best showcase your solution (e.g., citation issuance, ALPR enforcement, GIS/mapping, permit validation, payment verification, reporting/dashboards, mobile workflows, administrative functions) and identify anything unique or differentiating.

[ Enter response here ]

3.4 Implementation

Guidance: Describe your typical implementation methodology and timeline; customer and vendor responsibilities; data-migration approach; user training; testing approach; and post-implementation support. Identify implementation dependencies involving third-party systems such as permitting, GIS, court, payment, towing, or other municipal systems.

Key figures:

Typical implementation timeline

Typical time to first production use

[ Enter response here ]

3.5 Vendor Experience

Guidance: Provide a company overview, relevant municipal experience, and typical customer size. Product roadmap is optional. Enter the key figures below, describe your experience in the response box, and list references from similar agencies in the table.

No. of parking-enforcement implementations

No. of municipal customers (total)

Years in market

Typical customer size

[ Enter response here ]

References (similar agencies):

3.6 Commercial Information

This RFI is for market research only; SPD is not requesting formal pricing. The City is seeking implementation approaches, support offerings, and other commercial considerations.

Deployments, Licensing, and Commercial Model Guidance: Describe how your solution is licensed or priced (subscription, perpetual, transaction-based, etc.); the primary pricing drivers (users, vehicles, hardware, storage, transactions, modules); and, if multiple deployment options exist, how they differ in licensing, functionality, maintenance responsibilities, and support.

Licensing / commercial model (check all that apply):

Subscription | Perpetual license | Transaction-based | Other [ Enter response here ]

Solution Components Guidance: Identify functionality included in the standard offering, optional or separately licensed modules, and third-party products commonly required.

[ Enter response here ]

Implementation Costs Guidance: Describe activities that commonly generate implementation costs, typical customer effort during implementation, and typical integration effort.

[ Enter response here ]

Support and Maintenance Guidance: Describe your support and maintenance models, software update process, upgrade policy, and system uptime percentage (excluding scheduled maintenance).

System uptime (%, excl. scheduled maintenance)

Support hours / coverage

Target response time (critical / P1)

[ Enter response here ]

Integrations Guidance: Describe how integrations are licensed or priced, whether APIs are included, and any additional costs for custom integrations or ongoing maintenance.

[ Enter response here ]

Cooperative Purchasing Guidance: Identify whether your solution is available through cooperative purchasing vehicles (e.g., NASPO ValuePoint or other cooperative contracts), and provide the contract name/number if applicable.

Available through cooperative purchasing? (check one):

Yes | No Cooperative vehicle(s) (check all that apply):

NASPO ValuePoint | Other cooperative contract [ Enter response here ]

Budgetary Information (Optional) Guidance: If available, provide representative pricing ranges, budgetary estimates, or examples from similar municipal implementations. These are for planning only and will not be considered binding.

[ Enter response here ]

3.7 Additional Information

Guidance: Provide any additional information that would help SPD understand your solution, implementation approach, or future product direction — including industry best practices, emerging technologies, and innovative approaches — that may benefit Parking Enforcement but were not specifically requested in this RFI.

[ Enter response here ]

Some material used here was created using Claude AI and has been reviewed for accuracy by the SPD.