ETA Blog

Every transit agency knows the drill. It’s 5:45 AM. Pull-out starts in fifteen minutes. A dispatcher is on the radio asking where Bus 412 is parked. A utility worker is walking the lot with a flashlight. Maintenance thinks it’s in the back row. Nobody’s sure.

For many transit agencies, onboard screens are a standard part of the rider experience. From next-stop information, route maps, and the occasional service alert, they display the info that reminds riders they are being taken care of. As someone relatively new to the transit technology space, I believe these screens have the potential to do much more as our tech continues to evolve. When paired with the right technology foundation, onboard infotainment can become a powerful operational and communication tool— one that improves service delivery, reduces operator workload, and creates measurable value for agencies.

Transit operations rarely go exactly as planned. Mechanical failures, farebox issues, vehicle accidents, or even a minor passenger injury can disrupt service and create stress for your entire operations team. That’s why ETA built a dedicated Transit Incident Management module inside our SPOT CAD/AVL platform.

Transit operations depend on people, from dispatchers and operators to supervisors and administrators. But when turnover hits, even the most experienced agency can struggle to keep service running smoothly. Without an easy-to-use CAD/AVL system, service disruptions, delayed responses, and training gaps become the norm. That’s why ETA designed SPOT, a browser-based platform built to keep service on track, no matter who’s at the controls. 

Universities face unique pressures: student and faculty ridership satisfaction, limited budgets, and the need for accurate data to secure funding. Outdated systems, consumer-grade tablets, and unreliable reporting only make things worse. 

Transit agencies aren’t just looking for new software—they’re looking for stability, transparency, and a partner that understands the realities of running a public transportation system. Too often, legacy CAD/AVL vendors sell a product and disappear until it’s time for renewal. Agencies are left dealing with downtime, unreliable hardware, and limited visibility into what’s really happening on the street.

Computer-Aided Dispatch Automatic Vehicle Location (CAD/AVL) is the backbone of modern transit management. The solution provides the tools to deliver safer, more reliable, and more efficient service. It powers digital tools to assign and manage vehicles, replacing traditional radio-based dispatch with a data-driven future-facing solution.

As American cities race toward cleaner, greener transportation, public transit agencies are at the forefront of adopting zero-emission buses. The two leading technologies-battery-electric (EV) and hydrogen fuel cell buses-each offer unique benefits and challenges. Drawing on robust data from the U.S. Department of Energy, agency case studies, and international trends, this post explores how agencies are charting the future of zero-emission transit.

In the past, deploying a new Computer-Aided Dispatch/Automatic Vehicle Location (CAD/AVL) system could take many months or even years. Today, however, modern technologies and advanced implementation techniques have dramatically shortened deployment times, allowing for faster and more efficient system installations.

In the world of public transit, understanding industry language is critical. Whether you’re evaluating new technology, reading procurement documents, or coordinating with vendors, transit acronyms and technical terms are everywhere. That’s why we built the ETA Glossary—a helpful resource to support transit professionals like you to quickly decode industry jargon.

Tally was inspired by my experience as a transit planner at LeeTran in Fort Myers, Florida. A year in as a transit planner, I was tasked with overseeing the average passenger trip length surveys for the fiscal year 2016-2017. At that time, LeeTran’s Automatic Passenger Counters (APCs) were not certified for National Transit Database (NTD) reporting, which forced us to use manual methods for collecting data on boardings and alightings. This labor-intensive process involved generating random trip selections, calculating distances between stops, and manually entering data into spreadsheets for analysis.

Accurate data collection is critical for transit agencies, especially when reporting to the National Transit Database (NTD). One essential measure is the Average Passenger Trip Length (APTL), which helps agencies calculate the distance passengers travel on average for each unlinked trip. Reporting APTL is a key part of ensuring compliance and maximizing funding from the Federal Transit Administration (FTA).

Customer references can make or break a transit agency’s choice for a Computer-Aided Dispatch (CAD) and Automatic Vehicle Location (AVL) system. These complex systems influence everything from service efficiency to rider satisfaction. Sifting through stacks of Request for Proposal (RFP) documents can be daunting, and agencies often think a handful of references will suffice. This blog post reveals why it’s crucial for transit agencies to request all of the vendors’ references, not just the standard three.

As the public transit industry continues to evolve, so do the regulatory requirements designed to ensure that transit agencies provide accurate and reliable data. One such development is the Federal Transit Administration’s (FTA) mandate for Automated Passenger Counters (APCs) certification by report year 2025. This change is poised to have a significant impact on how transit agencies manage and report ridership data. Let’s explore what this requirement entails, why it’s important, and how transit agencies can prepare for it.

Healthy public transportation services rely on sound data collection to secure the maximum funding from the federal government. Automatic Passenger Counter (APC) certification and Average Passenger Trip Length (APTL) survey are two distinct, yet related, processes that agencies employ to ensure they are accurately reporting the unlinked passenger trips (UPT) and passenger miles traveled (PMT) to the federal government.

Public transportation agencies face a constant challenge: optimizing service provision to meet the evolving needs of ridership. Traditionally, planning decisions relied on estimates and historical trends. However, the emergence of Automated Passenger Counting (APC) technology has ushered in a new era of data-driven decision making.

As technology continues its rapid advancement, the future of GTFS development is marked by a commitment to addressing real-world challenges and embracing emerging innovations. Recent contributions and pull requests to the GTFS repository demonstrate an ongoing effort to refine and enhance the specification.

Transit ITS Data Exchange Specification (TIDES) is a remarkable GTFS extension that delves into the realm of historical transit operation data. This repository provides data schemas and tools to support the access, management, and improvement of historical transit operations data, including vehicle operations, passenger activity, fare collection, and other similar data. TIDES bridges the gap between the past and present, allowing transit agencies to store and exchange historical data in a structured and standardized format. This opens a world of possibilities for transit providers, researchers, and developers.

Transit operators require their scheduling and operational systems to seamlessly work together. This synergy is most effectively attained through the adoption of open standards. Although GTFS has proven highly successful as an open standard, its primary purpose is to disseminate information to transit passengers, which means it lacks vital elements essential for transit providers.

GTFS has a rich history that reflects the evolution of public transportation data sharing. It emerged as a response to the challenges posed by fragmented and proprietary data formats, aiming to create a standardized way for transit agencies to share their information with developers and users.

The world of public transportation is undergoing a transformation, and at the heart of this evolution lie s the General Transit Feed Specification, or GTFS. As we kick off this multi-part blog series, we’ll embark on a journey to explore the depths of GTFS, uncover its significance, and reveal how it’s reshaping the landscape of public transit.

In the realm of mass transit technology, it is a rare occurrence to encounter a potential customer who enthusiastically praises their current CAD/AVL (Computer-Aided Dispatch/Automatic Vehicle Location) vendor. To put it simply, transit operators are often dissatisfied with their CAD/AVL vendor. According to our annual surveys of transit agencies, more than two-thirds express their discontent.

Introduction All-in-one tablets are unreliable and unsuitable for public transit applications. Instead, transit agencies must consider investing in transit-grade computers to record and display mission-critical information. Functioning onboard digital devices are essential to: improve operating efficiencies. automate NTD data collection. and enhance the rider experience. Though consumer-grade tablets and all-in-one Mobile Data Terminals (MDTs) with built-in touchscreen displays have become popular choices for transit agencies, these devices are not durable enough for harsh transit environments. In fact, 8 out of 10 transit agencies interviewed in 2023 have cited unreliable hardware as their primary challenge. Malfunctioning hardware is unacceptable for modern transit systems. In this blog, we will explore the reasons why tablets do not work for transit applications and discuss the advantages of using transit-grade computers with separate touchscreen MDTs. Consumer-grade tablets and all-in-one computers are designed for everyday use, but they fall short in the demanding conditions of transit environments. There are a few key reasons for this: Unreliable: Consumer-grade devices are not built to withstand the continuous vibrations, extreme temperatures, and harsh conditions common in public transportation systems. Over time, these factors lead to system failures and downtime. Consequently, agencies grow extremely frustrated with missed onboard announcements, loss of APC data, inaccurate NTD reporting data, and irritated riders due to incorrect bus arrival predictions. Unprotected: Transit agencies need to ensure the security of their systems and data. All-in-one solutions that combine processing and the touchscreen display are installed in exposed locations since the bus operator needs to interact with the system. This placement is more susceptible to theft and tampering, causing decreased system reliability and increased service disruptions. Upkeep: When these all-in-one devices fail during revenue service, it is inconvenient, time-consuming, and costly for transit agencies to manage. In this era of staffing shortages, transit agencies cannot afford to spend their time troubleshooting malfunctioning equipment as essential as MDTs. The Benefits of transit-grade computers with separate touch screen devices To address these challenges, transit agencies should consider using transit-grade computers with separate MDTs that do not have any processing responsibilities or complex operating systems. This design offers several advantages: Durability: Transit-grade computers are specifically designed to withstand the harsh conditions of transit environments. They are built with dependable connectors and housed in protective enclosures, ensuring reliability and longevity. Simple, functionally limited MDTs provide the bus operator with an intuitive driver interface and touch screen to interact with the system but do not impact bus operation or data collection. Security: By separating the touch screen display from the computer, a “dumb” terminal eliminates the risk of system failure or theft affecting the entire system. If the touch screen is damaged or stolen, the system can continue to operate without disruption. Simplified Maintenance: With a “dumb” terminal, updates and maintenance are managed centrally, reducing the burden on transit agencies and ensuring consistent performance across all devices. Cost-effectiveness: While the initial investment in transit-grade computers and touch screen MDTs may be higher than consumer-grade devices, the long-term benefits of reduced maintenance, increased reliability, and improved security make them a more cost-effective solution. Conclusion As transit agencies continue to embrace technology to enhance their operations, it is crucial to select devices that can withstand the harsh environments they will encounter. Consumer-grade tablets and all-in-one computers may seem like an appealing choice, but they are ultimately unsuitable for the demands of public transportation systems. Eventually, the bargain all-in-one solution will cost the transit agency unexpected time and money. By investing in transit-grade computers and touch screen MDTs, transit agencies can ensure the reliability, security, and longevity of their systems, ultimately providing a better experience for both operators and passengers.

Tools to help your RFP to set realistic expectations and deliver a focused review. Over our history, ETA has submitted hundreds of proposals for mass transit technology RFPs. We’ve won some, we’ve lost some, and we’ve seen RFPs pulled without warning. Win, lose, or draw our practice is to reach out to transit agencies and ask for feedback about the RFP—our proposal, where we excelled, where we came up short, and what struggles the agency had during the process. That’s the nature of our industry. This last point serves as the subject for this article; what are the common challenges for proposal evaluation? Our 2018 transit agency survey discovered that comparing offerings was the “biggest source of stress” for those on proposal decision committees, followed by “determining value versus price” and “determining the importance of features.” These are all valid concerns—but easily fixed. The key to solving these issues starts with preparing the RFP itself. The same 2018 survey revealed that “preparation,” “creating technical requirements,” and “determining desired outcomes” were the top three headache-inducing tasks. For the most part, an RFP includes the following components: Cover letter or statement of interest Vendor information Proposed solution Strategy for implementation Warranty & support information Cost proposal Required forms Each section should ultimately contribute to the decision-making process. It’s not uncommon for an evaluation structure included in the RFP which looks something like this: Technical response: 20 points Price: 40 points Vendor qualifications: 20 points Organization of the proposal: 10 points Situational understanding: 10 points And that’s about it in terms of the breakdown and weighting of the proposal response. That’s all a decision committee relies on to score and rank their evaluation. The highest score wins, and to the victor goes the spoils. But what if the evaluation criteria are wrong? What if it’s weighted incorrectly? Why does price weigh more than the solution itself (40% of transit agencies use it as their primary decision factor) than the vendor’s track record (vendor experience is the primary factor for just 11% of transit agencies)? What mechanisms exist in your RFP for establishing value versus performance? Our 2019 survey revealed long-term performance (70.2%) must be part of the evaluation process. That certainly isn’t listed in the standard scoring criteria? Just 52 percent of transit agencies say that the intelligent transit system (ITS) they purchased lived up to expectations in our 2020 agency poll. The picture I’m painting here is that the defined evaluation criteria baked into RFP documentation are inherently flawed; they are not up to the task and are highly subjective. Why do so many agencies value long-term performance, but fail to include any sort of measurement tool within their evaluation structure? Why are nearly half dissatisfied with their ITS purchase? How do we change the evaluation so that it most accurately reflects the needs of the transit agency and delivers on the expected outcomes? Here are a few ideas to consider before you put together your RFP: Pre-proposal polling: Conduct an anonymous internal poll of your transit agency. If possible, include everybody. Everybody is drivers, mechanics, dispatchers, planners, customer support, and administration. Use this effort to discover hidden truths about your agency and potential issues. Look for potential areas of resistance. Find pain points in potential solutions. Include the ability for respondents to rank their answers to gauge priority and level of severity. We recommend Survey Monkey, DooPoll, or even use Microsoft Sharepoint to create your surveys and leverage these tools automatically tally the results. Conduct pre-RFP pricing research: We know that transit agencies (ETA included) keep a tight lid on their pricing structure. It’s a competitive industry, after all, and any advantage helps. This practice doesn’t mean they won’t provide you with ballpark figures for planning purposes. Use this information to A) understand the approximate cost for each component (ITS, APC, AVA, etc.), and B) evaluate cost against the amount of funding you have available. If possible, ask for an estimated ‘per vehicle cost’ to help account for hardware, installation, and recurring fees. This effort will help you set expectations before writing your RFP. It is better to know what you’re asking for and compare it to the final pricing. With this baseline pricing in mind, it will help establish expectations for what your agency cannot afford. It will also help you derive a better sense of value from your proposals. It may even cause you to think about how much weight you place on pricing in the overall evaluation hierarchy. Create a compliance matrix with priority values We’ve written before about the importance of including a compliance matrix as part of your RFP documentation. This approach is an excellent way to get answers about what a proposed system can and cannot deliver. What’s missing from the matrix is a correlation between features and their importance to the final solution. A compliance matrix evens the value across all items but does nothing to tell your evaluation committee how to weigh capabilities against price and competition. Including this information will help the vendor present prioritized solutions based on needs. For example, if your internal survey efforts reveal the following priorities: Cloud-based ITS Route and schedule management NTP reporting Automatic passenger counters Onboard Wi-Fi Then assign value to those features within your matrix (a scale of 1–10, perhaps?). The vendors responding to your proposal will understand what you value the most. They can also construct their proposal to prioritize some aspects over others and deliver more up-front value. A well-constructed spreadsheet may even include auto-calculation to help score each entry in advance. An entry in a compliance matrix theoretically might look like this, where “yes” answers to compliance earn full marks, where “no” responses don’t earn points, and “extra cost” applies a multiplier value to adjust the score to account for additional charges: Provide this spreadsheet as part of the RFP and ask vendors to complete it as part of their submission. Lock and hide those columns, cells, and worksheets from the file submitted to vendors. Reveal those fields after submission to see how a vendor stacks up based on their responses. Include in your calculations weighted penalties for unsupported systems. Proposal creation Now that you are adequately armed with priority preferences by role (via the internal survey), you will have more insight into how each business unit will react to your final choice. Additionally, you’ll have a sense of what you can afford and what systems to prioritize (using the ITS Price Estimator) and, ultimately, a point-by-point accounting of each vendor’s capabilities (courtesy of the weighted compliance matrix). With this information, you can create an RFP document that better captures the actual deliverables for your project and have the background data needed to conduct a proper evaluation. With this data in hand, you can quickly rule out submissions below a capability threshold that you identify before evaluating. The goal, after all, is to narrow down proposals quickly. This approach: Greatly assists in the preparation of the RFP Clearly defines the technical requirements It helps determine an agreed-upon, prioritized outcome Reduces internal debate process The process helps build a right-sized transit spec while avoiding common pitfalls and finding that vendor who will be your forever friend. Now that you’re ready to construct your RFP, you can focus on telling a precise story—your story—so that any vendor responding has a full grasp of everything your system needs to accomplish. Construct your RFP to follow a logical progression and use clearly-defined topics and industry-standard terminology. Avoid copying and pasting from other sources, which typically results in a messy, contradictory document. We recommend a sequence that follows this general approach: Introduction (overview of your agency and history) Objectives (description of the challenges you seek to resolve) Resources (provide details about your agency, e.g., number of vehicles, makes and model, installed hardware, contact points, who has the final say, etc. Scope (define every deliverable, feature, and intended use—a good place to include your compliance matrix) Submission requirements (we recommend the following:) Statement of interest About the vendor Technical proposal Implementation plan Warranty & support Price proposal Required forms A significant consideration in this process is to allow enough time for vendors to create a thoughtful response to your solution. A good rule of thumb is six to 12 weeks from the RFP’s issue (or street) date. We also encourage you not to put page limits on the proposal. These highly technical and complex systems allow the vendor the necessary time to explain the system and benefits thoroughly. Yes, this can lead to some lengthy proposals. Consider the amount of money you are about to spend and the consequences of selecting poorly. In this decision, we highly stress that you should err on the side of information. Short summaries could cause a potential vendor to omit details that could otherwise influence your decision one way or another—all to satisfy an arbitrary page count. The added information serves as a handy reference to answer any questions you may have. Proposal evaluation You’ve now laid the groundwork for your evaluation with all your pre-proposal work. The tools and concepts presented above provide your transit agency with enough background information to help identify potential vendors to look for before the issuance of the RFP—and then compare their response against the pre-RFP evaluation. More importantly, you have established a list of criteria based on priority gathered by stakeholders at all levels of your organization. Take your time to evaluate the results. Ask questions. Conduct pilot programs. Take the necessary steps to ensure that you’re making a comprehensive decision in your agency, taxpayers, and riders’ best interest.