Why Mobility Analytics Software Procurement Is Different
Procuring a software platform that will be used to inform multi-million-dollar service planning and capital investment decisions is not the same as procuring an office productivity tool. The methodology matters. The data rights matter. The vendor's ability to explain what the software is actually doing — not just what it produces — matters in ways that don't come up when you're buying project management software or a scheduling system.
This guide is written for transportation planners and procurement professionals at transit authorities, MPOs, and DOT planning divisions who are preparing to issue an RFP or evaluate vendor responses for a mobility analytics platform. The questions and evaluation criteria here reflect what distinguishes a defensible procurement from one that creates downstream methodological or legal risk.
Before You Write the RFP: Scoping the Analysis Need
The most common procurement failure in transportation analytics isn't choosing the wrong vendor — it's under-specifying the analytical need. An RFP that asks for "mobility data analytics" will receive responses ranging from simple ridership reporting dashboards to full-network demand surface platforms, and there's no meaningful way to evaluate them against each other.
Scope your need by answering these questions before drafting the RFP:
- What specific planning decisions will this analysis inform? (Network redesign? LRTP corridor prioritization? Title VI compliance? All three?)
- What data sources does your agency already have? (GTFS, GTFS-RT, APC, AFC, GBFS from a partner bike-share program?) What data sources would you need the vendor to provide or integrate?
- What are your reporting and export requirements? (GTFS scenario export for your CAD/AVL system? ArcGIS integration? Custom dashboard for public presentation?)
- What is your agency's internal data capacity? (Do you have staff who can run queries and build reports, or do you need turnkey analysis delivery?)
- What is the procurement timeline constraint? (If the network redesign environmental review starts in 8 months, can you get a platform onboarded and producing reliable output in time?)
The answers shape both the RFP requirements and the evaluation criteria. A small transit authority doing its first network redesign has very different needs than an MPO doing a regional LRTP update with multiple transit agencies submitting data.
What to Ask About Methodology
This is the section most RFPs omit and most evaluators underweight. Methodology questions should be non-negotiable for any analytics platform that will be used to inform capital investment or compliance decisions.
Ask vendors to describe their spatial aggregation approach. What spatial unit does the platform use for demand aggregation? How was the resolution selected? Is it documented and consistent across clients? A vendor that can't clearly explain why they use census tracts vs. H3 cells vs. custom polygons probably hasn't thought carefully about the analytical implications of that choice.
Ask how the platform handles data gaps. No agency has perfect data coverage. APC sensors fail; GTFS feeds have missing trip updates; bike-share data goes stale. Ask vendors specifically: "What happens when there's a 3-week gap in our GTFS-RT feed? How does the platform handle it? Is it flagged? Is it filled by estimation? If estimated, what's the basis for the estimate?" A good answer includes documentation of the gap-filling methodology and explicit flagging of outputs derived from estimated rather than observed data.
Ask how accuracy is validated and reported. What validation studies has the vendor conducted? Against what ground-truth data (APC counts? manual counts? travel surveys)? What accuracy metrics are reported, and are they reported per-deployment or as aggregate vendor-level claims? Avoid vendors who provide accuracy claims as single numbers without confidence intervals or methodology description — "97% accurate" is not a useful claim without knowing what's being measured and how.
Ask for a sample methodology brief. Reputable vendors in this space publish methodology documentation that explains, in terms accessible to a planning professional, how the demand surface is constructed. If a vendor refuses to share methodology documentation before contract signing (citing proprietary concerns), that's a significant red flag for an agency that will need to defend the analytical methodology in a public process.
Data Rights: The Provisions That Actually Matter
Data rights provisions in analytics software contracts deserve more careful reading than they typically receive. The specific provisions that matter for government agencies:
- Agency ownership of agency data: Any data your agency provides to the vendor — GTFS feeds, APC data, AFC records — must remain agency-owned. The contract should explicitly prohibit the vendor from using your agency's data to benefit other clients or for purposes not related to your contract. This is standard good practice but is not always reflected in vendor standard-form contracts.
- Derived data rights: More complex: who owns the demand surface outputs derived from your agency's data? These are analytically valuable outputs, and the contract should specify that your agency has rights to use, publish, and share those outputs without vendor permission or additional fees.
- Data portability on contract end: You need to be able to get your data and your analytical outputs out of the vendor's platform when the contract ends, in a format that's usable by a successor system or your own GIS environment. Standard formats (GeoJSON, CSV, GTFS) are appropriate; proprietary formats that require the vendor's software to open are not acceptable.
- Sub-processor disclosure: If the vendor uses cloud infrastructure or sub-processors that store or process your data, those should be disclosed and consistent with your agency's data governance policies. For agencies with sensitive operational data, this may include FedRAMP or CJIS-adjacent requirements.
How to Structure the Evaluation Criteria
Government procurement regulations generally allow agencies to use best-value evaluation criteria rather than lowest-bid selection for professional services, which most analytics platforms fall under. A reasonable best-value evaluation framework for mobility analytics software:
| Criterion | Weight |
|---|---|
| Methodology quality and transparency | 30% |
| Data source compatibility with agency feeds | 25% |
| Relevant experience (similar agency type and size) | 20% |
| Price / cost-effectiveness | 15% |
| Data rights and security posture | 10% |
Weight methodology quality highest because that's the dimension most likely to create downstream analytical and legal risk. A cheaper platform with opaque methodology will cost more in time, staff effort, and potential replanning if the methodology doesn't hold up to scrutiny in a public process or FTA review.
Red Flags in Vendor Responses
After reviewing RFP responses, watch for these specific patterns:
- Proprietary data as a core feature. Vendors that describe their offering primarily in terms of their proprietary mobility data (cell phone traces, device location data, etc.) rather than your agency's operational data are selling a different product than you likely need. For service planning and capital investment decisions, your agency's APC and ridership data is the authoritative demand record. Proprietary mobility data is useful supplemental context, but it shouldn't be the primary analytical basis for decisions that affect service equity and public funds.
- Accuracy claims without methodology. Single-number accuracy claims ("our platform is 94% accurate") without explanation of what's being measured and against what ground truth are marketing statements, not analytical claims. Ask for the methodology and the validation data.
- Demos using generic data rather than your feeds. A vendor who can't or won't connect to your GTFS feed and demonstrate results from your own network before you sign a contract is a vendor you can't evaluate adequately. Require a pilot analysis or a demonstration with your data before signing.
- Vague answers on data rights. If a vendor's legal team can't clearly articulate what happens to your data on contract termination, that's a data governance risk. Standard practice in government-oriented analytics is explicit data return and deletion provisions. If those aren't in the vendor's standard form, they should be negotiated in.
We're not saying every vendor without these answers is acting in bad faith — some of these gaps reflect the state of the market, where government-specific product maturity varies. But the gaps are real risks for your agency, and the procurement process is the right time to surface and address them.
Cooperative Purchasing and Procurement Pathways
Government procurement processes for software can be time-consuming — 6–18 months from initial scoping to contract execution is common. There are a few pathways that can reduce timeline without sacrificing rigor:
Cooperative purchasing vehicles (NASPO ValuePoint, Sourcewell, OMNIA Partners) allow agencies to piggyback on master contracts competitively awarded by a lead agency. Not all mobility analytics vendors are on cooperative purchasing schedules, but it's worth checking. The lead agency's evaluation on a cooperative contract satisfies most state procurement requirements for competitive selection.
Pilot projects structured as professional services engagements (time and materials, limited scope) can be procured under service thresholds that don't require full competitive procurement in many states. A well-designed pilot — with a defined analytical question, specified deliverables, and an evaluation framework for deciding whether to proceed to a full platform contract — reduces procurement risk and builds internal confidence in the methodology before the major investment.
Sole-source justification is available for specialized software when competitive alternatives don't exist or when the agency's data environment creates unique requirements that only one vendor can meet. Use this pathway carefully — it requires formal documentation of the sole-source rationale and, in most cases, supervisor approval — but it's a legitimate tool when the analytical need is urgent and alternatives are genuinely limited.