A transit software RFP is one of the most important documents a small public agency will produce. Get it right, and you end up with a vendor that fits your program, your budget, and your team. Get it wrong, and you spend months in a contract with software that does not quite work, working through change orders you did not anticipate, or going back to procurement a year later to start over.
The challenge for most small agencies is that their procurement team has not written many transit software RFPs. General IT procurement templates do not translate cleanly to transportation management software. And large-agency RFP templates pull in requirements that a small program does not need, while leaving out specifics that matter most for demand-response and paratransit operations.
This guide covers what a transit software RFP for a small agency should include, the mistakes that cost agencies the most time and money, and how to evaluate vendor responses once they come in. The goal is to give your team a clear framework before you write the first line.
What a Transit Software RFP Needs to Cover
A transit software RFP is not just a list of features you want. It is a structured document that helps vendors understand your program, tells them exactly what you need, and creates the evaluation criteria you will use to compare responses fairly. The sections below are the minimum a well-constructed RFP should address.
Program Overview and Service Description
Start by describing what you run today. Vendors need to understand your service model before they can tell you whether their platform fits. Include:
- Service type: demand-response, fixed-route, paratransit, or a combination
- Fleet size: number of vehicles, vehicle types, any accessibility-equipped vehicles
- Trip volume: approximate daily or monthly trip counts
- Rider population: general description, whether you serve seniors, residents with disabilities, or the general public
- Geographic service area: city, county, or regional
- Current tools: what you are replacing or supplementing
This context sets the scope for the entire RFP. Vendors who cannot support your service model will self-select out. Vendors who can will give you more relevant responses.
Functional Requirements
This is the core of the document. List the specific capabilities your program requires, organized by function. For a small transit agency, the key functional areas typically include:
- Trip scheduling: Can the platform handle demand-response scheduling, recurring trips, round trips, and multi-passenger bookings? Can riders self-schedule through an app?
- Dispatch and live tracking: Does the dispatcher have a real-time map view showing vehicle locations, trip status, and driver status? Can they make manual overrides without disrupting the rest of the route?
- Route optimization: Does the system automatically generate optimized routes? How does it handle same-day changes, cancellations, and additions?
- Driver tools: Is there a driver app with turn-by-turn navigation, trip assignments, and pre-trip checklists? Does it work on standard smartphones or require proprietary hardware?
- Rider communication: Does the platform send automated trip confirmations, reminders, and arrival notifications? In what languages?
- ADA and accessibility support: Can the system track wheelchair trips, manage accessibility-equipped vehicle assignments, and flag special needs at the trip level?
- Fare collection: Does the platform handle fare payment? Does it support cash, card, or both?
- Reporting: What reports does the platform produce out of the box? Can you configure custom reports? Does it export data in formats compatible with your grant reporting requirements?
For each requirement, indicate whether it is required, preferred, or optional. This helps vendors prioritize their responses and helps you score them consistently.
Integration Requirements
Small agencies often have existing systems that new software must connect with. Common integration points to address in your transit software RFP include:
- CAD/AVL systems if you have existing vehicle tracking hardware
- Payment processors or financial systems
- State or federal reporting portals
- Scheduling or HR systems if the platform will need to pull driver availability
If you do not have integration requirements, say so. Vendors will not assume. Be clear about whether the platform needs to connect with other tools, and if so, how: via API, file export, or direct integration.
One practical note: small agencies procuring transit software for the first time often discover that they have fewer hard integration requirements than they expected. A platform that replaces a spreadsheet-based process does not need to integrate with the spreadsheet. Clarifying what you actually need versus what you are used to doing can simplify this section significantly.
Support, Training, and SLA Requirements
Software quality is only part of the procurement decision. For a small agency with a two-person operations team, the vendor's support model may matter as much as the feature set. Address the following in your RFP:
- Implementation support: What does the vendor provide during setup and go-live? Is onboarding included in the contract price or billed separately?
- Training: How are dispatchers, drivers, and administrators trained? Is training on-site, remote, or self-paced? What is the estimated time to competency for a new user?
- Ongoing support: What are the vendor's support hours? What is the expected response time for urgent issues? Is there a dedicated account contact or a general support queue?
- Uptime SLA: What uptime percentage does the vendor guarantee? What is the process for reporting and resolving outages? What credits or remedies apply if SLA commitments are not met?
- System updates: How frequently does the platform update? Are updates automatic? Do they require downtime?
For programs serving seniors and riders with disabilities, reliability is not a nice-to-have. It is a program requirement. Riders who depend on this service have no fallback if the software goes down. Ask vendors to describe their uptime track record, not just their SLA commitment on paper.
Pricing Structure
Transit software pricing varies significantly across vendors. Some charge per vehicle. Some charge per trip. Some bundle everything into a flat platform fee. Some require hardware purchases. Understanding what you are comparing requires vendors to present pricing in a consistent format.
Ask vendors to break out:
- Base platform license cost (monthly or annual)
- Per-vehicle fees, if applicable
- Per-trip fees, if applicable
- Implementation and onboarding fees (one-time)
- Hardware requirements, if any
- Add-on costs for features listed as optional in your requirements
- Price at contract renewal: does the rate change after the initial term?
Software-only platforms with no hardware requirements and no per-trip fees are generally the most predictable for small agency budgets. They let you forecast costs accurately as trip volume grows, without a surprise line item when ridership increases.
Demo Requirements
A written response tells you what a vendor claims their platform can do. A live demo tells you whether it actually does it, and whether your team can use it without a steep learning curve. Your RFP should specify what the demo must cover.
For small transit agencies, a useful vendor demo should include:
- Scheduling a demand-response trip and viewing it in the dispatch dashboard
- Simulating a same-day change (cancellation or late addition) and seeing how the system responds
- The driver app experience from trip assignment through completion
- Running a standard performance report
- The rider app or booking interface, if applicable to your program
Specify in the RFP that the demo should use a scenario similar to your actual program, not a generic walkthrough. Ask the vendor to show edge cases, not just the happy path.
Common Mistakes Small Agencies Make in Transit Software RFPs
The following mistakes appear consistently in transit software procurements at small agencies. Knowing them before you write saves time on both sides of the table.
Using a Generic IT RFP Template
General technology procurement templates were designed for software like HR systems, finance platforms, or document management tools. They ask for things like data center certifications, API documentation, and disaster recovery plans, but they miss the operational specifics that matter most for transit software: how does the routing engine handle cancellations? Can the driver app work offline? What happens when a vehicle breaks down mid-route?
Start with a transit-specific framework. The American Public Transportation Association (APTA) publishes procurement resources that can help ground your requirements in industry standards.
Writing Requirements That Only One Vendor Can Meet
RFPs that describe a specific vendor's feature set by name, or list requirements so narrow that only one platform can satisfy them, create legal risk for public agencies and undermine the competitive procurement process. Write functional requirements that describe what the software needs to do, not how it should do it technically.
If you have already evaluated vendors and have a preference, that is fine. Your scoring weights can reflect your priorities without making the RFP noncompetitive.
Skipping the Total Cost of Ownership
The base platform license is not the total cost. Hardware requirements, implementation fees, per-trip costs, and the internal staff time required to manage the system all factor into what the software actually costs over a three-year term. Ask vendors to provide a total cost of ownership estimate for your program size, not just a monthly rate.
Ignoring the Reporting Requirements Upfront
Federal grant programs require specific data. If your program receives Section 5310 funding or other federal transit grants, your software needs to produce the reporting that those grants require. Identify your reporting obligations before you send the RFP and include them as a specific requirement. Finding out after selection that your chosen platform cannot produce a required report is a painful and expensive discovery.
Not Asking About the Implementation Timeline
Small agencies often have a hard go-live date tied to a grant period, a budget cycle, or a contract start date. Ask vendors to provide a realistic implementation timeline, including what they need from your team to stay on schedule. A platform that takes six months to implement when you have eight weeks is not a viable option, regardless of how good the software is.
What Successful Transit Software Procurement Looks Like
Two Ohio municipalities, the City of Dublin and the City of Hilliard, both went through structured procurement processes before launching their transit programs with SHARE Mobility. Their outcomes illustrate what the right software choice enables over time.
Dublin's program, the Dublin Connector, provides on-demand transit for seniors and residents with disabilities. Since launch, the program has completed more than 29,900 rides and maintains an overall rider satisfaction rating of 4.95 out of 5. Approximately 80 percent of ridership comes from seniors and residents with disabilities, directly aligning with the program's stated goals.
Hilliard's program, the Hilliard Express, focuses on advance-scheduled door-to-door service for older adults and residents with disabilities. The program has delivered over 11,000 rides since launch, with trips per driver increasing 48 percent year over year as scheduling efficiency improved. Wheelchair trips represent 30 percent of all trips, reflecting consistent accessibility delivery at scale.
Both programs replaced phone-based scheduling and disconnected tools. Both needed software that could handle demand-response service, produce clean reporting for grant accountability, and operate reliably for a rider population with no transportation alternatives. The procurement process in both cases prioritized those requirements directly.
Amy Van Huffel, Recreation Supervisor for the City of Hilliard, described the outcome: "The City of Hilliard's partnership with SHARE has enabled us to create a safe, reliable ride program for older adults in the City of Hilliard."
How to Evaluate Vendor Responses
Once responses come in, you need a consistent framework to compare them. The following scoring approach works for most small agency transit software evaluations.
Build a Weighted Scoring Matrix
Assign weights to each evaluation category based on your program's priorities. A typical weighting for a small demand-response or paratransit program might look like:
- Functional requirements: 35%
- Pricing and total cost of ownership: 25%
- Implementation and support quality: 20%
- Vendor experience with similar programs: 15%
- Demo quality and ease of use: 5%
Adjust the weights to reflect what matters most to your program. If grant reporting is a compliance requirement, weighting reporting capabilities higher makes sense. If your team is small and not technically experienced, support quality and ease of use should carry more weight.
Check References
Ask finalists for references from agencies similar to yours: similar fleet size, similar service type, similar rider population. A vendor's case studies tell you what they have done. A reference call tells you what it was actually like to work with them. Ask specifically about implementation, what went wrong and how the vendor responded, and whether the platform delivers what was promised in the demo.
Evaluate the Platform, Not Just the Pitch
Demo scoring should reflect how the platform actually performs for your use case, not how polished the presentation is. Give each shortlisted vendor the same scenario to demonstrate. Use a consistent scorecard across evaluators. Ask your dispatcher or operations coordinator to participate in the demo, not just your procurement team. They will catch usability issues that procurement reviewers miss.
Read the Contract Before Signing
Confirm that the contract reflects what was presented in the demo and proposal. Pay particular attention to: what is included in the base price versus what requires an add-on, data ownership and export rights, termination provisions and notice periods, and what happens to your data if you switch vendors. These details matter far more at year two of a contract than they do on signing day.
Writing Your Transit Software RFP: Where to Start
A well-written transit software RFP does not have to be long. It has to be precise. Define your program clearly, state your functional requirements specifically, ask the right questions about support and pricing, and build in a demo that tests the software on your actual use case.
The agencies that get the most out of this process are the ones that treat the RFP as a two-way evaluation: they are assessing the software, and the software vendor is assessing whether they can serve the program well. A vendor who is honest about the fit, or the lack of one, is a better long-term partner than a vendor who wins the contract and then struggles to deliver.
If your agency is evaluating transit software options and wants to understand what a platform built for small-to-mid municipal programs looks like in practice, SHARE's municipal transit page walks through how the platform supports demand-response and paratransit programs from scheduling through reporting. You can also explore reporting capabilities and scheduling features to see how the platform handles the requirements that matter most for grant-funded programs.