How to choose bus stop management software

Bus stop management software should let anyone at the agency open a bus stop and find its assets, their condition and every job done there, with the photos and documents behind them. It should start from your GTFS feed, technicians should be able to use it from a phone, and staff should be able to use it without training. Every one of those is easy to say yes to in a demo. The useful test is whether it holds up with your own bus stops, and the ten questions at the end of this guide are built for that.

Start from the questions you can't answer today

Before looking at any product, write down the questions your agency struggles to answer about its bus stops. They make better requirements than a feature list, because they come from your own work. For example:

• When was the shelter at this bus stop installed, who paid for it, and under which project?
• Was the broken panel reported last month replaced, and who replaced it?
• Which bus stops lost their bench during the road project, and has every one come back?
• How many shelters reach the end of their expected life in the next five years?
• Why was this bus stop moved, and what did the developer agree to build?

Take the list into every demo and ask the vendor to answer two or three of the questions on screen. If the purchase goes through an RFP, put the same questions in its requirements.

Organized around bus stops and routes

People look for a bus stop by its name, its number, its intersection or the route that serves it. The software should find a bus stop by any of those and open everything about it in one place: its assets, its open and past work, its photos and documents, and its history.

Routes matter as much as bus stops. Planners think in corridors and service changes, so you should be able to pull up every bus stop on a route, put them on a map, and narrow the map to, say, shelters in poor condition.

Built on your GTFS feed

Your GTFS feed already lists every bus stop you serve, with fields such as stop_id, stop_name, stop_lat and stop_lon (GTFS Schedule reference). The software should import that list rather than have anyone type it in again, and keep each bus stop tied to an identifier from the feed, usually stop_id, so the asset record and the schedule always agree on which stop is which.

Feeds change with every service change: bus stops are added, moved and removed. Ask how the software handles a new version of the feed. What happens to a bus stop's assets, open work orders and history when the stop is no longer in the feed? Who is told, and what are they asked to do?

Your asset types, your fields

No two agencies have the same amenities. You should be able to define your own asset types, such as a particular shelter model, a solar light or a real-time sign, and the fields each one carries, without waiting on the vendor.

Anything you will want to filter or report on (manufacturer, model, owner, install date, condition) should be a structured field with fixed choices or a date, not free text. Bus stops need their own fields as well: the landing pad, the lighting, who owns the right-of-way. What to record for each bus stop suggests a starting set.

Work orders that close the loop

A work order should be tied to a bus stop, and to an asset when there is one, so the work becomes part of that record. Look for the whole loop:

1. A request comes in: a rider complaint, an inspection finding, a planner's request.
2. Someone assigns it to a technician. Work that nobody has assigned should reach the person who does the assigning, not sit in a list nobody watches.
3. The technician does the work and closes it out with notes and photos.
4. The person who asked verifies that the work was done, and done correctly.

Each step should record who acted and when, and status changes should be logged automatically, so the history of a job never depends on someone remembering to write it down.

As a planner, I saw work slip when nothing tracked it clearly. A job moved only when a supervisor remembered to chase it, and that did not always happen.

Priority needs written definitions. If nobody has written down what makes a job high priority rather than medium, the field loses its value.

Roles that match how your agency works

Planners, supervisors, technicians and managers need different things from the same record. Planners create requests and check the result, supervisors assign and prioritize, technicians do the work and report it, and managers read the totals. In a small agency one person may be the planner and the supervisor.

Ask how permissions are set, and look closely at who can archive or hide a record. If anyone who can edit a job can also make its history disappear from view, the record cannot settle a dispute about what happened.

Keep every record, and keep history with the asset

Ask whether anything can be deleted, and by whom. In a system of record the answer should be close to nobody: removed bus stops, finished work orders and old notes are archived, and they still turn up when someone opens the stop years later. The bus stop asset management guide covers why.

Documents and photos should open from the bus stop, asset or work order they belong to, and an asset's history should go with it between stops and storage. Question 6 below is the test.

Easy to use without training

A feature only helps if people use it. I have seen useful features go unused because even a routine task like creating a work order took several clicks through menus that never explained what their options meant. The people who had been trained got value from them, and everyone else did not.

So treat usability as a requirement, not a preference. In the demo, hand the controls to someone from your agency who has never seen the product, and watch them find a bus stop and create a work order without help. Common tasks should take a few steps, and every option should say what it does.

A mobile app technicians will use

Technicians work from a truck, between bus stops, and they do the job as well as the information in front of them allows. When I went out to a bus stop myself, I needed to know the request before I left, because it decided which tools I brought and how much time I set aside. On a phone, technicians need their own list of assigned work, the request in full, each bus stop's location with a link to navigation, the stop's history, and a quick way to add notes and photos and change a job's status.

Test this in the demo, on a phone, ideally with one of your technicians doing it. If closing out a job with a photo takes more than a few taps, it will not happen in the field, and without that photo a job done wrong can go unnoticed. Ask, too, what happens where there is no signal.

Age, condition and replacement planning

The software should hold an install date, a cost and an expected life for each asset, so you can see what is due for replacement and what it will cost. It should schedule inspections by asset type and show which are overdue. And it should produce the reports that a capital plan, a grant application or a board question needs, in a form you can export.

Getting your existing data in

Your existing data may be scattered: an asset list, past work orders, photos, site plans and correspondence. Ask who moves it into the new system, how long that takes, and what you need to provide. Ask what the system needs from you on the first day, such as your GTFS feed and your list of asset types. And ask how you would get all of your data back out, and in what format.

Pilot with your own data

A demo shows the vendor's sample data at its best. Before committing, ask for a pilot with your own: one route or one district for a few weeks, used by a planner, a supervisor and two technicians. Talk to procurement and IT first, because at some agencies even an unpaid pilot needs a signed data agreement or a security review before agency data goes into it. At the end, hand the planner the list of questions from the start of this guide and see how many they can answer without calling anyone.

Questions to ask in a bus stop management software demo

1. Show one bus stop's complete history, with its documents and photos.
2. Answer two of the questions from our list, on screen.
3. Import a GTFS feed. What happens when a bus stop is missing from the next version?
4. Have one of our staff, with no training, create a work order from a rider complaint. Then assign it, close it out with a photo on a phone, and verify it.
5. Define a new asset type with our own fields, without the vendor's help.
6. Move a shelter from one bus stop into storage and then to another stop. Where does its history go?
7. Show which assets reach the end of their expected life in the next five years, and what replacing them costs.
8. Show what a technician sees on a phone, and how they get to the bus stop.
9. Who migrates our existing data, how long does it take, and what do you need from us?
10. Can records be deleted or hidden, and by whom? How do we get all of our data out?

Where Roote fits

Roote is bus stop asset management software for public transit agencies, organized around bus stops, routes and the assets at each stop, with every work order, photo, document and decision for a stop in one timeline. Agencies bring their existing bus stops in from GTFS, and the Roote team migrates existing asset data. If you have your list of questions, bring it to a walkthrough.