Transit Agency Operations Software: Why Runcutting, Dispatch and Federal Reporting Never Agree

Why transit operations software breaks where the union contract starts

It is 4:20am in a dispatch office. Three operators have called out. The dispatcher is holding a printed runcut, a clipboard listing the extraboard in seniority order, and a mental model of who has already worked into overtime this week and who is protected by a guarantee. She fills two of the three runs. The third goes uncovered, a trip drops, and by 9am a rider has posted about it and a board member has forwarded the post to the general manager. Nowhere in that sequence did a piece of software help, and at the end of the month the dropped trip may or may not be reflected in the revenue hours reported to the federal government.

Transit agencies buy scheduling software and are then surprised that it does not run operations. Trapeze Group, Init, Optibus, Clever Devices and Via are all real products with real strengths. Optibus is genuinely good at generating an efficient runcut. Init and Clever Devices know vehicle systems and passenger counting. What none of them does out of the box is encode your particular labour agreement, which is where transit operations actually lives. The pick rules, the spread time penalties, the guarantee, the report and travel allowances, the rules on who can be held over and for how long, the order in which the extraboard is offered work, and what happens when nobody accepts. That document is negotiated locally, it changes every contract cycle, and the entire daily cost of your operation is decided by it.

So the software produces a plan, and a human turns the plan into reality using rules the software does not know. That human is your single point of failure, and when they retire the agency loses the only working copy of how dispatch actually works.

Problem one: the pick is a scheduling problem and a legal event at the same time

Pick week is the most consequential week of the operating year. Operators select work in seniority order, and every selection constrains the next. Get the sequence wrong, mis-state a run's spread or platform time, or offer a run that violates the agreement, and you have a grievance, a rerun of the pick, and an operator relations problem that lasts a year.

Most agencies run the pick on paper or in a spreadsheet with someone physically present in a room. The runcut lives in the scheduling product, the seniority list lives in human resources (HR), the leave calendar lives somewhere else, and the reconciliation is manual. Vacation picks and work picks are often separate exercises even though they interact.

What a custom build does is treat the pick as a transaction against validated rules. Each operator sees only the work they are eligible to hold, the system checks the selection against spread, rest, and qualification rules at the moment of the click, and every offer and selection is logged with a timestamp so a grievance is answered with a record rather than a recollection. Agencies that run a remote or phased pick this way stop losing three days of a supervisor's life and stop paying for the room.

Problem two: daily dispatch is where the money leaks and nobody measures it

The scheduled cost of service is set at the runcut. The actual cost is set at 4am by whoever fills the open work. Hold an operator over into overtime when an extraboard operator was available and eligible, and you paid a premium for nothing. Offer the work out of seniority order, and you paid the premium and bought a grievance.

Off the shelf dispatch modules handle the recording of an assignment. They do not model your offer sequence, your guarantee, or the running weekly overtime position of each operator, because those are contract specific. So the dispatcher carries it. Ask any agency what a covered absence costs against a straight assignment and the honest answer is that nobody knows at the daily level, only at the payroll level a fortnight later.

A build worth paying for makes the cost of every coverage decision visible at the moment of the decision. The dispatcher sees the eligible list in the correct order, sees the projected premium of each option, and records the reason when they deviate. Two things follow. The daily premium becomes a managed number instead of a payroll surprise, and the deviation log becomes the evidence base for the next round of negotiation, because you can finally show what a specific clause costs to operate.

Problem three: the federal numbers are assembled, not captured

Formula funding under the federal transit programme depends on data reported to the National Transit Database, and the definitions are specific. Revenue hours and revenue miles are not the same as pull out to pull in. Deadhead does not count as revenue service. Passenger miles have sampling requirements. A dropped trip changes actual delivered service and should change the number.

In most agencies these figures are reconstructed after the fact from a scheduled runcut, an odometer report, a farebox summary and an automatic passenger counter feed that nobody fully trusts, then adjusted by a person who understands the definitions. That reconstruction is legitimate work, but it is also the point where an agency stops being able to defend its own numbers in a review, and it is why so many agencies quietly under report delivered service.

Custom software fixes this by capturing at the source. If dispatch records the actual assignment, the actual pull out and pull in, and the trips actually operated, then revenue hours are a derived value from operational truth rather than an estimate. The reporting build then becomes a set of definitions applied to a clean event log, and when a reviewer asks how a number was produced you answer with a lineage rather than a spreadsheet.

Problem four: demand response and fixed route are treated as different agencies

Almost every agency runs both. Fixed route is scheduled work against a runcut. Complementary paratransit under the Americans with Disabilities Act is trip based, booked in advance, and scheduled dynamically. Microtransit sits somewhere between the two. In most agencies these run on different systems with different operator pools, different dispatchers and different reporting, which means the one lever that saves real money, sharing operators and vehicles across modes when demand allows, is unavailable because no system can see both.

Vendors sell into this split because their products grew up on one side of it. A custom build does not have to respect the split. One operator record, one vehicle record, one availability model, and mode specific scheduling on top. That is not a small build, but it is the difference between running two operations and running one.

What a custom transit operations build has to include

• An operator record that carries seniority, qualifications, licence and medical certificate expiry, leave balances and the running week to date and period to date hours position.
• Work rules as versioned configuration with effective dates, so a new contract is loaded and validated before it takes effect rather than patched into code.
• A pick engine that validates every selection at the moment of selection and logs offers, declines and selections for grievance defence.
• Daily dispatch with an eligible coverage list in correct order, projected premium cost per option, and a mandatory reason code on deviation.
• Real time adherence against actual vehicle location, with dropped and short turned trips recorded as operational events rather than corrections.
• Clean capture of revenue hours, revenue miles, deadhead and delivered trips at source, with the federal definitions applied as a reporting layer.
• A payroll export that your payroll team can reconcile line by line, because this is the integration that decides whether operators trust the system.
• General transit feed specification output for schedules and real time, so rider facing apps and third parties consume one source of truth.

What this costs and how long it takes

A focused first release, meaning runcut import from your existing scheduling tool, daily dispatch with extraboard and absence coverage, and clean capture of the service actually delivered, runs $90,000 to $180,000 and ships in 12 to 18 weeks. That is a system the dispatch office uses at 4am on day one. A full platform adding the pick engine, real time adherence from vehicle location data, an operator self service portal, payroll export and federal reporting runs $250,000 to $600,000 phased over 9 to 18 months.

What drives the number up in transit specifically: the number of bargaining units, because two unions means two rule sets and two picks; integration with vehicle systems, since automatic vehicle location and passenger counter hardware from Init, Clever Devices or another supplier each speak their own protocol on a real bus rather than in a lab; paratransit scheduling, which is a genuine optimisation problem in its own right; and payroll, because agencies commonly run older payroll systems that need file based interfaces with careful reconciliation.

What keeps the number down: start with fixed route dispatch for one division, keep using your current runcutting tool and import from it, and leave the operator portal until dispatch is proven. Most of the daily premium leak is recoverable in phase one.

When you should not build this

Do not build if you operate under roughly 50 peak vehicles on fixed route only, with no bargaining unit or a simple one, and no complementary paratransit obligation of any scale. Optibus for scheduling plus a modest dispatch tool will serve you, and a custom build would consume capital that should go into service hours. Do not build if your agency has no permanent technology staff and no plan to acquire any, because an operations system needs an owner.

Build when two or more of these are true. Your labour agreement has rules no product can express and dispatch carries them by hand. Pick week costs you a week of supervisory time and produces grievances. You cannot state the premium cost of yesterday's coverage decisions. Your federal reporting is reconstructed rather than captured and you would struggle to defend it in a review. You run fixed route and demand response as two separate operations with no shared visibility. At that point the coordination logic is the agency, and it should not live in one dispatcher's head.

How to choose a developer for transit operations software

Ask them to read your collective bargaining agreement before quoting. Not skim it. Read the work rules articles and come back with questions about spread penalty, guarantee and the offer sequence for open work. A developer who quotes without reading it is quoting a scheduling app and will discover transit halfway through your budget.

Ask how they will handle a contract change mid build, because you will have one. The right answer involves effective dated rule versions and a way to run the new rules against last month's actual assignments to see what changes before the contract starts.

Ask what they have actually integrated on a vehicle. Vehicle location feeds, passenger counters and fareboxes are three different problems and the failure modes involve cellular dead zones and buses in a yard, not test fixtures. Ask for the specific hardware and the specific protocol.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. For a public agency this is also a procurement and stewardship question, and your board should expect the answer in the contract rather than in a conversation.