Bus stop asset management: a practical guide

Bus stop asset management is the work of knowing what is at every stop in a transit network, what condition it is in, what has been done to it and why, and what it will need next. It covers the bus stop itself and everything installed there: shelters, benches, signs, lighting, trash cans and real-time displays. Done well, it lets an agency answer a rider, a council member or an auditor from the record instead of from someone's memory.

Most of the work is unglamorous. Decide what to record and get it right once. After that, the job is making sure every visit, repair and decision lands on the same record. Records rarely fail all at once. They drift, one unlogged repair at a time.

What bus stop asset management covers

Two kinds of things need records.

The bus stop. A bus stop is a place: a point on a route that riders know by a name, and often by a number on the sign. It has a pole and a sign, a landing pad where riders wait and board, and a position relative to the nearest intersection. It usually makes sense to treat the sign and pole as part of the bus stop rather than as separate assets, because they rarely move unless the stop does.

The assets at the bus stop. These are the physical things installed there:

• shelters
• benches
• trash cans
• lighting, from a solar light in a shelter roof to a dedicated pole
• real-time arrival displays
• information cases and maps
• bike racks

Each asset has a make and model, an install date, a cost and a working life, and each can be removed, put in storage and installed somewhere else. That is the distinction that matters most: a bus stop is a place, and an asset is a thing. Keep them as separate records, linked by where each asset is now.

Why bus stops are hard to keep track of

A bus stop network is a large number of small assets spread over a large area, each one visited rarely. A cleaning crew might see a given shelter once a week; a planner might not see it for years. Problems tend to surface as complaints, often long after they started. I have worked as a planner at agencies whose networks ran from a few hundred bus stops to thousands, and it held true at both ends of that range.

Responsibility is often split. At a single bus stop, the agency might own the sign and the bench, the city the sidewalk and the landing pad, an advertising company the shelter, and a state department of transportation the road itself. In my experience, the organizations involved usually know which of them owns what. The public often does not. As a planner I took many calls from exasperated people who only wanted a sidewalk fixed and had been passed from office to office trying to find out who to ask. The bus stop inventory guide covers how to capture that split.

Many people touch the same bus stop. Planners add and move bus stops with service changes. Facilities staff and contractors clean and repair them. Customer service takes complaints about them. Capital projects install new amenities, and developers and road projects move bus stops, sometimes for a season and sometimes for good.

And bus stops outlast the people who know their history. A shelter installed under a grant is often still standing long after the planner who chose its site has moved on. The questions arrive years later: when it went in, who paid for it, why the bus stop moved to the far side of the intersection, what the developer agreed to build.

What a good bus stop record answers

A record is good enough when it can answer four questions about any bus stop, quickly:

1. What is there now? Each asset at the bus stop, by type, with its own ID.
2. What condition is it in? The result of the last inspection or visit, and its date.
3. What has been done, and why? Every work order, repair, complaint and decision, with the documents and photos behind them.
4. What will it need next? The next scheduled inspection, and where each asset stands against its expected life.

The records I worked with were often incomplete and kept in no standard form, so they could not be searched. When a search came up empty, I never knew whether the record did not exist or I simply could not find it.

If any of those answers depends on asking a particular person or searching an inbox, that is the place to start.

Start with an inventory

Everything else depends on knowing what is at each bus stop. Your GTFS feed already lists every bus stop you serve, with an ID, a name and a location, but it says nothing about what is installed there. So an inventory starts from that list and a survey of every bus stop. How to build a bus stop inventory covers what to record for each stop and asset, and how to collect it.

Route work through work orders, and verify it

Every piece of work at a bus stop should start as a work order tied to that stop, and to the asset when there is one: a rider's complaint about broken glass, a problem an inspection found, a planner's request for a new bench. The work order records who asked and what they asked for, who did the work and when, and what they found. Once it is closed, the work is part of the bus stop's history instead of a memory or an email thread.

Two habits make work orders trustworthy.

Close out with photos. A photo of the finished work, taken at the bus stop, is the cheapest proof there is. It also shows the next person what the bus stop looked like after the repair, and if a job went wrong, the photo shows it while it is still a small fix, before it becomes a bigger problem.

Verify. Whoever asked for the work should confirm that it was done, and done correctly, before the job counts as finished. Without that step, "completed" only means that someone marked it completed.

I learned this from a sign. I sent a work order to install one at a bus stop on the edge of town, and about three months later I drove past that stop for the first time since. The sign was held up with duct tape. All I could do was send a second work order, and I could not even tell who had done the first one. I did not blame the technician. Nothing in the process asked anyone to show the finished work, or gave me a way to check it.

Contractors should send back the same kind of record. Monterey-Salinas Transit's 2020 invitation for bids for bus stop cleaning and shelter maintenance asks for a weekly task report, completed for each stop serviced, with the date, the bus stop number, a description of the maintenance performed, and before and after photos when the facilities supervisor asks for them (MST IFB 20-04). A report like that is most useful filed against each bus stop's record, where the next person to look at the stop will find it.

Inspect on a schedule

Complaints only find what riders notice and take the time to report. Inspections find the rest: the cracked panel nobody called about, the light that went out, the bench bolted to a crumbling pad.

• Set the interval by asset type, not one bus stop at a time. For example, an agency might check shelters and real-time displays every quarter and benches and signs once a year, because glass, lights and screens fail faster than steel.
• Adjust for location where it matters. The shelter that gets tagged every month, or the bus stop outside a high school, earns more visits than the default for its type.
• Count from the last completed inspection, so the schedule follows what actually happened rather than what was planned.
• Use the visits you already make. If a cleaning contractor visits each bus stop on a fixed cycle (MST's bid asks its contractor to visit each stop up to three times per week), a short checklist on each visit turns those visits into condition data.

An inspection that finds a problem should produce a work order, so the finding and the repair end up in the same history.

Keep the history, and keep it with the asset

History is the one part of the record that cannot be rebuilt later. A few rules keep it intact.

• Archive instead of deleting. A removed bus stop, a cancelled work order and an old note should stay findable, marked for what they are. The question about why a bus stop was removed tends to arrive after the stop is gone.
• Attach the documents to the bus stop. Site plans, developer correspondence, the grant that paid for a shelter, the email that answered a council member: years later, these are what people ask for, and they belong with the bus stop they are about. A program that installs amenities at many bus stops needs this most. On one grant-funded shelter and bench program I helped plan and permit, the records of site-by-site coordination with the installer and the close-out documents went into one large archive. None of it was filed by bus stop, so it was hard to pull up for any one site later, and there was no good way to tell which stops had been part of the program.
• Let history follow the asset. When a shelter is removed for construction and later installed at another bus stop, the repair it had two years ago belongs to the shelter, not to its old location. Record the move at both bus stops, and keep the shelter's own history with the shelter.

One request still bothers me. A rider asked us to move a bus stop to a spot right next to where it used to be. Old Google Street View images showed it had been moved away from there about twelve years earlier, and we suspected a safety report was the reason. We declined on that suspicion. A copy of the report would have let me show the rider why, but I had none to send, and I still wonder whether there was ever a report at all.

Plan replacements from age and useful life

To plan replacements, record an install date and a cost for each asset, and an expected life for each asset type. The expected life is your agency's figure, from the manufacturer, your capital plan or your experience with that type.

For example, if a bench went in six years ago and your agency expects twelve years from that type of bench, it is halfway through its expected life, and its replacement belongs in the capital plan about six years out. Roll that up by asset type and by corridor and you can answer the questions a capital plan asks: which shelters reach the end of their expected life in the next five years, and what replacing them will cost.

Record the dates of each placement, not only the original install date. An asset that spent two years in storage during a construction project has been in service for less time than its age suggests. With the dates on record, its age can be worked out whichever way your agency's finance or asset management rules count it.

Choosing a system

Whatever system holds the record should be organized around bus stops, start from the stops in your GTFS feed, carry work from request to verified close-out, keep every record and document, work on a technician's phone, and be simple enough to use without training. How to choose bus stop management software turns those requirements into a checklist, with questions to ask in a demo.

Where Roote fits

Roote is bus stop asset management software for public transit agencies. It keeps one record for each bus stop and each asset, with the work orders, photos, documents and decisions behind it, and shows a stop's full history in one timeline. Supervisors route work orders to the right technician and verify the work was done. Technicians work from a mobile queue and close out jobs with photos. Managers see the age and condition of every asset across the network, with the data to plan replacements and capital spend. Agencies bring their existing bus stops in from GTFS, and the Roote team migrates existing asset data, so the system is useful from the first day.