CrewFoundry
Transit Operator Extraboard and Run Cover Board
The report-time board: open runs by report time, extraboard operators in rotation order, and license, medical card, rest and vehicle checks before a run is offered.
Works with MoveTheWheels
Industry solution
Designed to cover every run, charge every bus and inform every rider before the peak
Run cover, bus and charger readiness, bus bridges, rider notices, reduced fares and board reporting for transit and fleet operators.

The problem
Transit runs on phones, clipboards and a dozen disconnected systems. Sick calls empty the extraboard, chargers fault unseen overnight, disruptions produce conflicting alerts, reduced-fare forms queue on paper and board figures are rebuilt by hand.
Public transport is a promise renewed every morning. Each scheduled trip needs a bus that has passed its inspections and an operator who is licensed, rested and trained on that vehicle, all before report times that often fall before 5 a.m. Operator shortages have made the extraboard the pressure point: every sick call draws on a thin standby list, and a run that cannot be covered becomes a missed trip that riders notice at the stop.
Electrification adds a new dependency. Battery-electric buses must leave the depot with enough charge for the block they are assigned, which ties overnight charger uptime, utility power limits and electricity rates directly to service. Charging networks, including the public chargers many agencies run at park-and-ride lots, answer to drivers and funders who expect chargers to work and uptime to be reported. Boards and funders want evidence that the investment is cutting emissions.
Riders expect real-time, consistent information and simple fares, and public agencies must also run reduced-fare programs for seniors, riders with disabilities, students and low-income riders. Yet the records sit in a scheduling system, a vehicle-tracking system, a fare system, maintenance spreadsheets, charger vendor portals and paper forms that never line up, so every disruption, audit and board meeting starts with reconciling them by hand.
General manager or chief operating officer
Service delivered as scheduled, safety, labor cost and a board packet that holds up when members ask why a number moved.
Director of transportation or depot superintendent
Every run covered at report time by a licensed, rested and qualified operator, and every bus out of the gate on time.
Director of maintenance or fleet manager
Fewer road calls, inspections done on schedule, enough spare buses, and qualified mechanics for battery-electric work.
Zero-emission fleet or energy program manager
Buses charged for their blocks, chargers working, electricity costs in view and emissions evidence funders will accept.
Customer experience and fare programs manager
One consistent service alert, fast answers for riders, and reduced-fare applications decided without repeat visits.
Charging network or mobility operations lead
Charger and vehicle faults fixed quickly, uptime reported to site hosts and funders, and drivers or riders kept informed.
A day in the life
Danielle oversees bus and rail operations, maintenance and customer service for an authority running about 280 buses from two depots, the Millbrook light rail line and public chargers at three park-and-ride lots. A third of the Kestrel depot's buses are battery-electric. The Tuesday below is fictional, but anyone who has worked a transit operations floor will recognize every hour of it.
Tuesday, 4:02 a.m.
Marcus Bell, the dispatcher at Kestrel, has nine absences on the call-in line, and the first open run reports at 4:52. The extraboard is a clipboard in rotation order. He knows Aino Lindqvist's medical card runs out this week but not which day, Mateo Ruiz has not finished articulated-bus training, and Dayo Nwosu signed off a late run at 12:40 a.m. By 4:45 Marcus has held down two operators for overtime out of turn and still has a Route 40 run uncovered. It pulls out twenty-five minutes late.
How this is solved: Open runs at 4 a.m. and an extraboard running short4:40 a.m.
Priya Raman, the night yard supervisor, walks the electric lane and finds bus 2214 at 38 percent. Charger 14 tripped on a ground fault at 1:12 a.m.; the vendor portal shows it, but nobody on nights watches that portal. Bus 2214 is on a block that runs past 9 p.m., and the charging plan is a spreadsheet built to keep the depot under its power limit. Dispatch hears about the swap to a diesel bus from the operator at the gate. Across town, two public chargers at the Eastfield park-and-ride have shown unavailable since Saturday.
How this is solved: Electric buses plugged in overnight but not ready for their block7:20 a.m.
On Route 40, bus 1987's wheelchair ramp will not deploy with a rider waiting at the stop. The operator calls it in, a road call truck goes out and the next bus is fifteen minutes away. At the shop, maintenance manager Kwame Asante faces a whiteboard with 23 buses out of service, four buses past their mileage inspection because odometer readings were keyed in late, a tray of paper defect cards and two electric buses waiting on the one high-voltage-qualified mechanic on shift. It is the third ramp failure on bus 1987 this month, but nothing on the whiteboard says so.
How this is solved: Ramp failures, defect cards and too few spares at pull-out8:04 a.m.
An overhead wire fault stops trains between Elm Street and Wharf Street at the height of the peak, and rail control asks for a bus bridge. Bus dispatch needs eight buses and eight operators in the middle of pull-out and starts phoning both depots. The customer information team writes the alert three times, for the website, the app and social media, and each describes the Canal Market shuttle stop differently. Within twenty minutes the chat queue passes a hundred messages, most asking the same three questions.
How this is solved: A suspended rail segment, a bus bridge and riders left guessing1:30 p.m.
The line at the downtown customer service center reaches the door. Most people are there for reduced fares: seniors with photo IDs, riders with disabilities carrying certification forms, students with enrollment letters. Some are back for a second time because a page was missing. Staff key applications into a spreadsheet and print cards at the counter. Recertification letters went out late this quarter, and riders are finding out at the farebox that their pass has lapsed. A fare inspector calls the office to ask whether a card is still valid.
How this is solved: Reduced-fare applications stuck on paper and in the queue5:00 p.m.
Rosa Ibrahim, the planning analyst, is building next week's board packet, and the monthly service and safety figures for the agency's federal and state funders are due Friday. On-time performance comes from one export, missed trips from dispatch logs with half the cause codes blank, road calls from the maintenance spreadsheet, charger uptime from the vendor portal and ridership from the fare system. When Danielle asks why missed trips rose in September, whether it was operator shortages, road calls or the Millbrook Line closures, Rosa says she needs another day to find out.
How this is solved: Board and funder numbers rebuilt by hand every monthNone of this is unusual; it is an ordinary weekday for a transit operator at full stretch. The challenges below show how Burdenoff products are designed to share one record from the first sick call to the board packet, so Danielle's team can start the next morning knowing which runs are covered, which buses are ready and what riders are being told.
Challenges and how they are solved
Each challenge shows the problem as it happens, how the products are designed to hand work to each other, and the concepts that illustrate it. Share any challenge on its own.
Answers are in plain business terms. Choose Technical, or open any technical detail, to see how it works under the hood.
Challenge 1 of 6
Sick calls arrive in a cluster before dawn, while the extraboard is still kept on paper in rotation order. License, medical card, rest and vehicle qualification records sit in different places, so in the minutes before a report time a dispatcher cannot check them before offering a run. Runs go to whoever answers the phone, overtime is handed out of turn and grieved weeks later, and spread-time premiums reach payroll on paper slips. A run nobody can cover becomes a late or missed pull-out, and the quieter risk is worse: an operator with a lapsing medical card, or no training on an articulated bus, can be sent out because nobody could check.
Late and missed pull-outs, overtime handed out unevenly and grieved later, and a real risk that an operator with a lapsed card or no training on the bus is sent out because nobody could check at 4 a.m.
When operators call in sick, CrewFoundry is designed to list the open runs by report time and suggest extraboard operators in turn, skipping anyone whose license or medical card has lapsed, who is not rested or not trained on that bus. The operator can accept the offer, and MoveTheWheels shows dispatch who is driving each block.
Technical detail
CrewFoundry's people records, skills and time entries are designed to hold each operator's commercial driver's license and passenger endorsement, medical card date and vehicle and route qualifications, and to check rest against the rules the agency sets from its work rules. When absences are logged, CrewFoundry is designed to list the open runs by report time and propose extraboard operators in rotation order, showing the reason beside anyone skipped: card expiring, not rested, not qualified on the vehicle. The dispatcher then offers the run to the operator or posts it as voluntary overtime. MoveTheWheels holds the day's blocks as routes with an assigned bus and operator; CrewFoundry is designed to take the open runs from it and send each covered run back, so dispatch sees who is driving every block before pull-out. Time entries record the overtime and spread time for payroll.
Open runs are covered in rotation order by operators who are licensed, rested and trained on the bus, and dispatch sees the result before pull-out rather than at the gate.
CrewFoundry
The report-time board: open runs by report time, extraboard operators in rotation order, and license, medical card, rest and vehicle checks before a run is offered.
Works with MoveTheWheels
MoveTheWheels
Holds the vehicle and driver registers dispatch works from: status, utilization and who is assigned to each bus.
Challenge 2 of 6
Battery-electric buses are plugged in overnight on the assumption that they will be full by morning. When a charger faults, the alarm lands in the charger vendor's portal, which the night shift rarely watches, and charging is planned in a workbook tuned to the depot's utility power limit, with no spare charger allowed for. Nobody compares each bus's charge with the length of the block it is assigned, so a short-charged bus is found at pull-out or pulled mid-block, and dispatch hears about the diesel swap from the gate. Public chargers at park-and-ride lots fail the same way: drivers see them unavailable for days before anyone opens a repair.
Buses pulled mid-block for low charge, last-minute diesel swaps, public chargers down for days, and electricity use and emissions nobody can tie back to the depot that drew them.
AssetHandler is designed to show every electric bus's charge next to what its day of work needs and to open a repair job the moment a charger fails, while FluidGrids alerts the on-call technician overnight. Dispatch in MoveTheWheels sees at-risk buses early enough to swap them. Botlit tells drivers which public chargers are down, and EcoImpactHub records each depot's electricity use.
Technical detail
AssetHandler registers every battery-electric bus and charger, at depots and park-and-ride lots, as assets. Its connected-device records are designed to take charge and charger status readings and set each bus's charge beside the energy its block needs, taken from the charge management or scheduling system through FluidGrids, or from the MoveTheWheels route distance times a kWh-per-mile figure on the bus's asset record. A charger fault opens a work order listing the buses it affects, and FluidGrids can alert the on-call technician overnight. At-risk buses and proposed swaps are designed to pass to MoveTheWheels, where dispatch moves a short-charged bus to a shorter block. Public charger faults open work orders the same way, and a Botlit agent is designed to tell drivers which chargers are down. The night's metered energy is designed to pass through FluidGrids to EcoImpactHub as Scope 2 entries per depot, and AssetHandler shows each depot's emissions from those metrics.
Charger faults are worked overnight, low-charge buses are swapped before pull-out instead of at the gate, drivers know which public chargers are down, and each depot's electricity sits on the carbon record.
AssetHandler
The depot readiness board: each bus's charge against its block's need, faulted chargers with their work orders, swaps shared with dispatch, public chargers that are down and the night's energy draw.
Works with MoveTheWheels, EcoImpactHub, FluidGrids
EcoImpactHub
Records depot charging electricity as Scope 2 and diesel as Scope 1 entries with their emission factors, so each depot's footprint follows the fleet as it electrifies.
Challenge 3 of 6
Wheelchair ramps and lifts fail in service, and each road call leaves a rider who uses a mobility device waiting for the next bus. Operators' pre-trip defect cards arrive on paper and are keyed in hours later, and odometer readings lag, so mileage-based inspections slip overdue without anyone noticing. Repeat failures hide on a whiteboard or in a paper file, so a bus with its third ramp fault of the month goes back out after a quick reset. At pull-out the spare count is a guess: dispatch learns which buses are held only when the shop calls, and electric buses can sit waiting for the one mechanic qualified for high-voltage work.
More road calls and missed trips, riders who use mobility devices left at the stop, inspections found overdue instead of planned, and a spare fleet too thin to cover a bad morning.
AssetHandler is designed to keep every bus's inspections and ramp and lift service on schedule, turn operators' defect cards and breakdowns into repair jobs, and show when a bus keeps failing the same way. Dispatch in MoveTheWheels sees how many spare buses are really available before pull-out, and CrewFoundry shows which mechanics can work on electric buses.
Technical detail
AssetHandler keeps every bus as an asset with preventive schedules driven by mileage and calendar: safety inspections, brakes, air conditioning, and wheelchair ramp and lift service. Pre-trip defect cards and road calls are designed to become work orders on the bus, so a third ramp failure shows in its service history, the evidence behind a repair-or-replace decision rather than another quick reset. The shop's work order queue shows which buses are held, why and when each is due back, and that list is designed to pass to MoveTheWheels, whose vehicle register gives dispatch the real spare count before blocks are assigned. For battery-electric repairs, CrewFoundry's skill records are designed to show which mechanics hold a current high-voltage qualification.
Inspections are planned around service instead of found overdue, repeat ramp and lift failures show up in a bus's history, and dispatch knows the real spare count before pull-out.
AssetHandler
Puts every job raised against a bus in one queue, from pre-trip defect cards to road calls, with its type, priority, status and the mechanic assigned.
AssetHandler
Puts inspections and ramp and lift service on an owned calendar so work orders are raised before a bus goes overdue.
MoveTheWheels
Gives dispatch the vehicle register it plans pull-out from: how many buses are active, how many are in maintenance and which carry a maintenance alert.
Challenge 4 of 6
Rail segments stop without warning: a wire fault, a signal failure, a medical emergency on a train. A bus bridge is requested at short notice, and bus dispatch has to find spare buses and drivers during the busiest hour of the day by phoning each depot. Meanwhile customer information writes the same alert separately for the website, the app, social media and stop displays, and each version names the shuttle stops a little differently. Riders read one version on the platform and another on their phone, and the chat and phone queues fill with the same questions: where the shuttle stops, whether it is accessible and whether their pass is valid on it.
Riders stranded on platforms, shuttles sent to the wrong corner, conflicting alerts across channels and a customer service team overwhelmed at the worst moment of the day.
MoveTheWheels is designed to lay out the shuttle plan: which stations need a stop, which spare buses are coming and who is driving them, with CrewFoundry filling operator gaps. FluidGrids publishes one approved notice to the website, app, social media and stop signs, and Botlit answers riders on chat from it, passing lost property and complaints to staff.
Technical detail
MoveTheWheels is designed to hold the bus bridge as a dispatch plan: the suspended segment, a shuttle stop for each affected station and spare buses by depot with their estimated arrival, leaving out buses AssetHandler lists as off road. Operator gaps are designed to go to CrewFoundry for qualified extraboard cover. A FluidGrids workflow can start from a rail control request or a dispatcher's start; it is designed to take the stop list from the plan, wait for customer information to approve one notice, and publish it to the website, the app, social channels, stop displays and Botlit's service alert knowledge base, so every channel uses the same stop wording. Botlit is designed to answer riders on chat and messaging from that notice, the stop guide and fare rules, show its sources, and hand lost property, complaints and accessibility requests to staff. When the dispatcher republishes the plan, the workflow can update the notice everywhere.
Shuttles reach the right stops with qualified operators, riders see the same stop wording on every channel, and staff spend their time on the cases that need a person.
MoveTheWheels
The bus bridge board: suspended segment, shuttle stops by station, spare buses and operators on the way, and the plan handed to FluidGrids for the rider notice.
Works with CrewFoundry, AssetHandler, FluidGrids
FluidGrids
The notice run: one approved bus bridge notice, previewed per channel with identical stop wording and published to the website, app, social, stop displays and Botlit.
Works with MoveTheWheels, Botlit
Botlit
Answers riders from the current notice and stop guide, shows the passages it used, and says plainly when nothing matches so the question can go to staff.
Challenge 5 of 6
Reduced-fare programs for seniors, riders with disabilities, students and low-income riders each have their own proof rules, yet applications usually arrive on paper at a counter and are retyped into a spreadsheet. A missing page means a second trip, and nobody can tell a rider where an application stands without finding the form. Cards are printed with no link back to the decision, recertification notices go out whenever someone remembers, and riders learn at the farebox that a pass has lapsed. Fare inspectors have no way to check a card on the spot, so they phone the office.
Long lines and repeat visits, riders paying fares they qualify not to pay, inspectors unable to check a card on the spot and staff time lost to data entry.
GovCitizenHub is designed to put every reduced-fare application in one queue where staff check documents and ask for anything missing. An approved pass carries a code a fare inspector can check, and reminders go out before it needs renewing. Botlit is designed to answer eligibility questions and tell riders where their application stands, and FluidGrids passes approved passes to the team that loads fare cards.
Technical detail
GovCitizenHub is designed to publish each reduced-fare program as a service with its eligibility rules and required documents, take applications online or scanned at the counter, and queue them by service level for staff to verify documents, request anything missing and record each decision with a reason. An approved application is issued as a pass with a verification code that a fare inspector can check on a public page, which confirms validity without exposing private details, and a recertification date designed to raise reminders before the pass lapses. Botlit is designed to answer eligibility questions from the program rules and to tell riders where their application stands from GovCitizenHub. FluidGrids is designed to pass each approved pass to the team or system that loads the reduced fare onto the rider's fare card.
Fewer counter visits, decisions recorded with reasons, passes an inspector can check on the spot, and recertification reminders that arrive before a pass lapses.
GovCitizenHub
The reduced-fare desk: applications by program with their proof, missing-document requests, decisions with reasons and recertifications coming due.
Works with Botlit, FluidGrids
GovCitizenHub
Issues approved documents with a unique verification code and an expiry date that anyone can confirm on a public page; each reduced-fare pass is designed to be issued the same way.
Botlit
Answers riders' eligibility questions from the published program rules, shows the passages it used and says plainly when a question needs customer service.
Challenge 6 of 6
Every month the planning team files service, safety and asset-condition figures with federal and state funders and builds a board packet, and each figure comes from a different place: trips and missed trips from the computer-aided dispatch and automatic vehicle location (CAD/AVL) system, road calls from a maintenance spreadsheet, charger uptime from each vendor's portal, and boardings from fare collection. Missed-trip cause codes are entered inconsistently, so nobody can say quickly whether a bad month came from operator shortages, road calls or a disruption. Electrification grants add energy and emissions against the diesel baseline, and the same number often differs between reports.
Days lost to reconciliation each month, figures that disagree between the board packet and funder reports, and questions answered with estimates instead of evidence.
FluidGrids is designed to gather each day's service, repair, charger and fare figures in one place, and BigConsole turns them into one board console that explains what changed and why, including the monthly figures sent to funders. EcoImpactHub tracks energy and emissions against the reduction target, and managers can ask Botlit about the figures.
Technical detail
FluidGrids workflows are designed to collect each day's records into BigConsole datasinks: trips, missed trips and their cause codes from CAD/AVL exports, road calls, asset condition and charger uptime by site from AssetHandler, and ridership from the fare system. BigConsole consoles are designed to show on-time performance by route, missed trips by cause code, mean distance between road calls, charger uptime by site and the monthly service, safety and asset-condition figures the agency files with its funders, and an Explain panel to give short findings cited to the sink and field behind each one. EcoImpactHub keeps the emission factors and reduction targets, so energy and emissions against the diesel baseline trace to ledger lines. Botlit agents can answer managers' and board members' questions from the console figures.
One set of figures for the board, funders and managers, each traceable to its source, and the reason behind a change visible without another day of digging.
FluidGrids
Ends each collection workflow in a datasink, so the day's service, maintenance, charger and fare records land in one place for BigConsole.
BigConsole
Gives short, cited findings on the board console, such as which cause code drove a rise in missed trips, each tied to the sink and field behind it.
EcoImpactHub
Keeps the electrification reduction target against its baseline and the emission factors behind every figure the grant report uses.
How it fits together
Follow one weekday from the first sick call to the board console. Each step is one product doing one thing and passing the work to the next; together they show how the products are designed to work as one system for a transit or fleet operator.
To MoveTheWheels: which buses are ready and which need swapping
To AssetHandler: each depot's energy and emissions figures
To MoveTheWheels: who is driving each open run
To FluidGrids: where the shuttle buses stop and any change to the plan
To Botlit: the approved notice riders will ask about
To GovCitizenHub: riders who want to apply for a reduced fare
To FluidGrids: approved passes to load onto riders' fare cards
Step 1 of 8: Clear buses for pull-out
Technical detail
Products in this solution
Day-of-service dispatch and bus bridges
Is designed to show dispatch which bus and operator are on each piece of work, plan around buses that are out of service or short on charge, and organize replacement shuttle buses when a rail line stops.
Technical detail
Its vehicle and driver registers, routes with an assigned vehicle and driver, and dispatch board are designed to hold each block with its bus and operator, plan around off-road and short-charged buses, and run a bus bridge, with providers listed in its marketplace for extra coaches.
Buses, chargers, inspections and road calls
Is designed to keep one record for every bus and charger: inspections, defects, breakdowns and repairs, and whether each electric bus has enough charge for its day of work.
Technical detail
Its asset registry, mileage-based preventive schedules, work orders and service history are designed to keep each bus and charger in one record, compare each bus's charge with its block's need from the charge management system or route distance, and show depot energy from EcoImpactHub metrics.
Operator and mechanic qualifications and run cover
Is designed to track operators' licenses, medical cards, training and rest, fill open runs from the extraboard in rotation order, and show which mechanics are qualified for work on electric buses.
Technical detail
Its people records, skills, certificates and time entries hold licenses, medical card dates and vehicle qualifications; it is designed to check rest rules, cover open runs from the extraboard in rotation order and show which mechanics hold high-voltage qualifications.
Rider and driver questions during service changes
Is designed to answer riders on chat from the current service notice and fare rules, tell drivers which public chargers are down, show where each answer came from, and pass lost property, complaints and accessibility requests to staff.
Technical detail
Its knowledge bases and channel connectors for web chat and messaging apps are designed to answer riders and drivers from the current notice, stop guide, charger status and fare rules, show the passages used and hand everything else to staff.
Reduced-fare applications and verifiable passes
Is designed to take reduced-fare applications online or at the counter, help staff check documents and decide, and issue passes a fare inspector can verify, with reminders before they need renewing.
Technical detail
Its service catalog, guided applications, casework queue and verifiable permits are designed to run reduced-fare programs from application to a pass a fare inspector can check, with decisions recorded and recertification reminders.
Fleet energy and emissions
Is designed to turn each depot's electricity and diesel use into emissions figures and track them against the agency's reduction target, so grant and board reports share the same numbers.
Technical detail
Its carbon ledger, emission factors and reduction targets are designed to record depot charging electricity and diesel by scope and track progress against an electrification baseline for boards and funders.
Notices, alerts, hand-offs and daily records
Passes the news along: it is designed to publish one approved notice everywhere riders look when a line stops, alert the on-call technician when a charger fails and gather each day's figures for reporting.
Technical detail
Its webhook, manual and schedule triggers, wait steps, connectors and datasinks are designed to publish one approved disruption notice to every rider channel, alert the on-call technician when a charger faults, pass on approved fares and feed daily records into BigConsole.
Board, funder and management consoles
Is designed to give the board, funders and managers one view, refreshed every day, of service, breakdowns and charger uptime, with a short explanation of what changed and where each figure came from.
Technical detail
Its consoles are designed to show on-time performance, missed trips by cause code, road calls, charger uptime and monthly funder figures from FluidGrids datasinks, and an Explain panel to cite the source behind each finding.
All eight products run on Burdenoff Workspaces: one sign-in for dispatchers, mechanics, customer service and managers, roles that decide who sees operator records, rider applications or cost figures, one record of who did what across every product, and one bill for the whole set.
Concept gallery
14 concepts from 8 products. Each one links to its own page on the product's website, and every view has a link you can share.
CrewFoundry
The report-time board: open runs by report time, extraboard operators in rotation order, and license, medical card, rest and vehicle checks before a run is offered.
Works with MoveTheWheels
MoveTheWheels
Holds the vehicle and driver registers dispatch works from: status, utilization and who is assigned to each bus.
AssetHandler
The depot readiness board: each bus's charge against its block's need, faulted chargers with their work orders, swaps shared with dispatch, public chargers that are down and the night's energy draw.
Works with MoveTheWheels, EcoImpactHub, FluidGrids
EcoImpactHub
Records depot charging electricity as Scope 2 and diesel as Scope 1 entries with their emission factors, so each depot's footprint follows the fleet as it electrifies.
AssetHandler
Puts every job raised against a bus in one queue, from pre-trip defect cards to road calls, with its type, priority, status and the mechanic assigned.
AssetHandler
Puts inspections and ramp and lift service on an owned calendar so work orders are raised before a bus goes overdue.
MoveTheWheels
The bus bridge board: suspended segment, shuttle stops by station, spare buses and operators on the way, and the plan handed to FluidGrids for the rider notice.
Works with CrewFoundry, AssetHandler, FluidGrids
FluidGrids
The notice run: one approved bus bridge notice, previewed per channel with identical stop wording and published to the website, app, social, stop displays and Botlit.
Works with MoveTheWheels, Botlit
Botlit
Answers riders from the current notice and stop guide, shows the passages it used, and says plainly when nothing matches so the question can go to staff.
GovCitizenHub
The reduced-fare desk: applications by program with their proof, missing-document requests, decisions with reasons and recertifications coming due.
Works with Botlit, FluidGrids
GovCitizenHub
Issues approved documents with a unique verification code and an expiry date that anyone can confirm on a public page; each reduced-fare pass is designed to be issued the same way.
FluidGrids
Ends each collection workflow in a datasink, so the day's service, maintenance, charger and fare records land in one place for BigConsole.
BigConsole
Gives short, cited findings on the board console, such as which cause code drove a rise in missed trips, each tied to the sink and field behind it.
EcoImpactHub
Keeps the electrification reduction target against its baseline and the emission factors behind every figure the grant report uses.
Pitch kit
Transit and fleet operators keep a promise every morning: each scheduled trip leaves with a safe, charged bus and a qualified, rested operator, and riders know what is happening when something goes wrong. Today that promise is held together by phone calls, whiteboards and a dozen systems. Burdenoff brings run cover, bus and charger readiness, bus bridges, rider notices, reduced-fare programs and board reporting onto one workspace, with each product designed to hand the work to the next.
Questions
No. It is eight Burdenoff products, each handling one part of the work and sharing one workspace, one sign-in and one record of who did what. A few links are built in, such as FluidGrids feeding BigConsole; the other hand-offs show how the products are designed to work together.
Technical detail
No. It is a solution concept that combines eight Burdenoff products: AssetHandler for buses, chargers and maintenance, CrewFoundry for qualifications and run cover, MoveTheWheels for dispatch and bus bridges, Botlit for rider questions, GovCitizenHub for reduced fares, EcoImpactHub for emissions, and FluidGrids and BigConsole for hand-offs and reporting. They share one workspace, one sign-in and one record of activity. Apart from FluidGrids feeding BigConsole consoles, Botlit agents reading consoles and starting workflows, and AssetHandler using EcoImpactHub metrics, which are built into the products, the hand-offs on this page describe how the products are designed to work together.
No. Your scheduling, bus-tracking and fare systems keep doing their jobs. These products handle the day's work around them, and FluidGrids is designed to bring in files and exports from those systems so everyone works from the same figures.
Technical detail
No. Timetables, blocks, runcuts and the operator bid stay in your scheduling software, and your computer-aided dispatch and automatic vehicle location (CAD/AVL) and fare collection systems keep their jobs. These products work on the day of service and around it: covering runs, readying buses and chargers, running bus bridges, publishing notices, answering riders, deciding reduced fares and reporting. FluidGrids is designed to bring in files or exports from the systems you already run, so the products and your reports work from the same figures.
No. AssetHandler is designed to show each bus's charge against its day of work and open repair jobs when a charger fails. Charging schedules and power limits stay with your charging supplier's system.
Technical detail
No. AssetHandler is designed to read charger status and state of charge, compare each bus's charge with the energy its block needs, and turn faults into work orders. That energy need is designed to come from your charge management or scheduling system, or from route distance times a kWh-per-mile figure on the bus record. Charging schedules and power management stay with your charge management system or charger vendor; the readiness board only shows the depot's peak draw as that system reports it, so the yard team can act on it.
Yes, for most of it. Charging networks could track chargers, repairs and uptime and tell drivers which chargers are down; private bus and shuttle operators can cover driver shifts and run dispatch; bike-share operators can track bikes and docks and plan rebalancing van routes. The reduced-fare desk is aimed at public agencies.
Technical detail
Yes, for most of it. A charging network can keep its chargers as AssetHandler assets with fault work orders; FluidGrids is designed to carry uptime by site into BigConsole for site hosts and funders, and a Botlit agent to tell drivers which chargers are down. A contracted bus, shuttle or private fleet operator can use CrewFoundry for driver qualifications and run cover and MoveTheWheels for dispatch. A bike-share operator can keep bikes, docks and stations in AssetHandler and plan rebalancing van routes in MoveTheWheels. The reduced-fare desk in GovCitizenHub is aimed at public agencies.
No. The products are designed to keep the records your team relies on, such as license and medical card dates, inspection schedules and reduced-fare decisions. Deciding what the rules require and who is fit to drive stays with your agency.
Technical detail
No product can guarantee that. CrewFoundry is designed to record license, medical card and qualification dates and apply the rest rules you configure from your work rules, AssetHandler to keep inspection schedules and defect records, and GovCitizenHub to record reduced-fare decisions with reasons. Those records support your own compliance processes; decisions about what the rules require, and who is fit for duty, stay with your agency.
No. Each product works on its own. Start with the one aimed at your biggest problem, such as run cover or charger readiness, and add others later without a new sign-in, user list or separate bill.
Technical detail
No. Each product works on its own, so an operator can start where the pain is sharpest, for example run cover in CrewFoundry or bus and charger readiness in AssetHandler, and add the next product later. Because they share Burdenoff Workspaces, adding a product does not mean a new sign-in, a new user list or a separate bill.
Related domains
Challenges solved
A cross-product solution concept for vehicle makers, suppliers and mobility operators: inbound parts, quality containment, fleet uptime, connected devices and technician qualifications.
Challenges solved
A solution concept for 3PLs, carriers and shippers in which seven Burdenoff products are designed to work together, from carrier status to report card.
Challenges solved
A cross-product solution concept for agencies and municipalities: resident services, casework, permits, public assets, open data, climate reporting and emergency operations.
Tell us about your setup. We will walk you through the products involved and scope a pilot around the challenge that hurts most.
This is a solution concept: it shows how Burdenoff products are designed to work together in this industry. The images are illustrations of the concepts, not screenshots of the actual products, and every name and figure in them is sample data.