Industry solution

Transportation & Mobility

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.

Products
8
Challenges
6
Concepts
14
Talk to us about Transport & MobilityAsk a question
A technician checks a tablet beside an electric bus charging in a depot at dawn.
MoveTheWheels(opens MoveTheWheels in a new tab)AssetHandler(opens AssetHandler in a new tab)CrewFoundry(opens CrewFoundry in a new tab)Botlit(opens Botlit in a new tab)GovCitizenHub(opens GovCitizenHub in a new tab)EcoImpactHub(opens EcoImpactHub in a new tab)FluidGrids(opens FluidGrids in a new tab)BigConsole(opens BigConsole in a new tab)

The problem

Why running transit and fleets is hard right now

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.

Who this is for

  • 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

The story behind the solution

A Tuesday of sick calls, a tripped charger and a stalled rail line

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.

  1. Tuesday, 4:02 a.m.

    Nine sick calls before the first report time

    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 short

  2. 4:40 a.m.

    A charger that tripped at 1:12

    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 block

  3. 7:20 a.m.

    A ramp that will not deploy

    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-out

  4. 8:04 a.m.

    The Millbrook Line stops at Elm Street

    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 guessing

  5. 1:30 p.m.

    A line out the door for reduced fares

    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 queue

  6. 5:00 p.m.

    Why did missed trips go up?

    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 month

None 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

6 problems, several products, one connected answer

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

Open runs at 4 a.m. and an extraboard running short

CrewFoundry(opens CrewFoundry in a new tab)MoveTheWheels(opens MoveTheWheels in a new tab)

The problem

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.

What it costs

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.

How the products work together

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.

How it works — technical detail

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.

The outcome it is designed for

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.

The concepts behind it

Challenge 2 of 6

Electric buses plugged in overnight but not ready for their block

AssetHandler(opens AssetHandler in a new tab)MoveTheWheels(opens MoveTheWheels in a new tab)FluidGrids(opens FluidGrids in a new tab)EcoImpactHub(opens EcoImpactHub in a new tab)Botlit(opens Botlit in a new tab)

The problem

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.

What it costs

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.

How the products work together

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.

How it works — technical detail

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.

The outcome it is designed for

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.

The concepts behind it

AssetHandler

Electric Bus Depot Charge Readiness Board

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

Concept pagefor Electric Bus Depot Charge Readiness Board on the AssetHandler website (opens in a new tab)

Challenge 3 of 6

Ramp failures, defect cards and too few spares at pull-out

AssetHandler(opens AssetHandler in a new tab)MoveTheWheels(opens MoveTheWheels in a new tab)CrewFoundry(opens CrewFoundry in a new tab)

The problem

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.

What it costs

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.

How the products work together

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.

How it works — technical detail

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.

The outcome it is designed for

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.

The concepts behind it

Challenge 4 of 6

A suspended rail segment, a bus bridge and riders left guessing

MoveTheWheels(opens MoveTheWheels in a new tab)AssetHandler(opens AssetHandler in a new tab)CrewFoundry(opens CrewFoundry in a new tab)FluidGrids(opens FluidGrids in a new tab)Botlit(opens Botlit in a new tab)

The problem

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.

What it costs

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.

How the products work together

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.

How it works — technical detail

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.

The outcome it is designed for

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.

The concepts behind it

Challenge 5 of 6

Reduced-fare applications stuck on paper and in the queue

GovCitizenHub(opens GovCitizenHub in a new tab)Botlit(opens Botlit in a new tab)FluidGrids(opens FluidGrids in a new tab)

The problem

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.

What it costs

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.

How the products work together

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.

How it works — technical detail

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.

The outcome it is designed for

Fewer counter visits, decisions recorded with reasons, passes an inspector can check on the spot, and recertification reminders that arrive before a pass lapses.

The concepts behind it

Challenge 6 of 6

Board and funder numbers rebuilt by hand every month

FluidGrids(opens FluidGrids in a new tab)BigConsole(opens BigConsole in a new tab)EcoImpactHub(opens EcoImpactHub in a new tab)AssetHandler(opens AssetHandler in a new tab)Botlit(opens Botlit in a new tab)

The problem

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.

What it costs

Days lost to reconciliation each month, figures that disagree between the board packet and funder reports, and questions answered with estimates instead of evidence.

How the products work together

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.

How it works — technical detail

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.

The outcome it is designed for

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.

The concepts behind it

How it fits together

How one service day moves through the products

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.

  1. To MoveTheWheels: which buses are ready and which need swapping

  2. To AssetHandler: each depot's energy and emissions figures

  3. To MoveTheWheels: who is driving each open run

  4. To FluidGrids: where the shuttle buses stop and any change to the plan

  5. To Botlit: the approved notice riders will ask about

  6. To GovCitizenHub: riders who want to apply for a reduced fare

  7. To FluidGrids: approved passes to load onto riders' fare cards

Step 1 of 8: Clear buses for pull-out

How each hand-off works — technical detail

Technical detail

  1. 1. AssetHandler — Clear buses for pull-out: Flags buses held for defects, overdue inspections or low charge against their block, and opens work orders for chargers that faulted overnight.Hands to MoveTheWheels: Available buses, at-risk buses and proposed swaps for the day's blocks.
  2. 2. EcoImpactHub — Account for energy: Turns the night's metered charging energy from AssetHandler and diesel dispensed from the fuel records into Scope 2 and Scope 1 entries, tracked against the electrification target.Hands to AssetHandler: Each depot's energy and emissions metrics, shown back in AssetHandler.
  3. 3. CrewFoundry — Cover open runs: Lists open runs from absences by report time and offers each to the next extraboard operator who is licensed, rested and qualified on the vehicle.Hands to MoveTheWheels: Covered runs with the assigned operator for each block.
  4. 4. MoveTheWheels — Dispatch the day: Holds each block with its bus and operator and, when rail service is suspended, is designed to run the bus bridge with shuttle stops, spare buses and operators.Hands to FluidGrids: The bus bridge stop list and plan, each time the dispatcher publishes it.
  5. 5. FluidGrids — Publish one notice: Waits for customer information to approve one bus bridge notice, then publishes it to the website, app, social channels and stop displays with the same stop wording.Hands to Botlit: The same notice, loaded into Botlit's service alerts knowledge base.
  6. 6. Botlit — Answer riders: Answers riders on web chat and messaging from the current notice, stop guide and fare rules, shows its sources, and hands other cases to staff.Hands to GovCitizenHub: Riders asking for a reduced fare, sent to the online application.
  7. 7. GovCitizenHub — Decide reduced fares: Queues reduced-fare applications for document checks and decisions, and issues approved passes with a verification code and a recertification date.Hands to FluidGrids: Approved passes for fare card loading, and the day's reduced-fare counts.
  8. 8. FluidGrids — Pass on and collect the day: Passes approved passes to the fare card team and gathers trips, missed trips, road calls, charger uptime and reduced-fare counts into BigConsole datasinks daily.Hands to BigConsole: Daily figures for the board and funder console, which managers can also question through Botlit.

Products in this solution

What each product brings

  • MoveTheWheels

    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

    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.

    Visit MoveTheWheelsAll concepts

  • AssetHandler

    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

    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.

    Visit AssetHandlerAll concepts

  • CrewFoundry

    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

    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.

    Visit CrewFoundryAll concepts

  • Botlit

    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

    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.

    Visit BotlitAll concepts

  • GovCitizenHub

    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

    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.

    Visit GovCitizenHubAll concepts

  • EcoImpactHub

    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

    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.

    Visit EcoImpactHubAll concepts

  • FluidGrids

    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

    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.

    Visit FluidGridsAll concepts

  • 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

    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.

    Visit BigConsoleAll concepts

One platform underneath: Burdenoff Workspaces

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

Every concept in this solution

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.

Pitch kit

The Transport & Mobility solution in one minute

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.

  • CrewFoundry is designed to cover open runs with extraboard operators who are licensed, rested and qualified on the bus.
  • AssetHandler is designed to flag short-charged buses and faulted chargers before pull-out and keep inspections on a mileage schedule.
  • MoveTheWheels and FluidGrids are designed to run a bus bridge and publish one notice to every channel, and Botlit to answer riders from it.
  • GovCitizenHub is designed to turn reduced-fare applications into verifiable passes with recertification reminders.
  • FluidGrids, BigConsole and EcoImpactHub are designed to put service, maintenance, charger and emissions figures in one console for boards and funders.
Email it

Questions

Frequently asked

Is this a single transit operations product?

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

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.

Does this replace our scheduling, vehicle location or fare collection systems?

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

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.

Does AssetHandler control our chargers or manage charging to a power limit?

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

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.

Does this fit charging networks, bike share and private fleet operators, not only public agencies?

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

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.

Will this keep us compliant with safety, accessibility or labor rules?

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

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.

Do we have to adopt all eight products at once?

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

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

Where these products also work together

All domains

Want to explore this for your organization?

Tell us about your setup. We will walk you through the products involved and scope a pilot around the challenge that hurts most.

Talk to usBrowse every domain

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.