Transit Service Alert Publishing Workflow

This concept is a FluidGrids workflow for the service alerts of a transit agency. When part of a rail line stops running and buses replace the trains, riders look for news on the website, the rider app, social channels, stop displays and an assistant. The design envisions one run that drafts a single notice, has it approved and publishes that same text to every channel, so stop names and times never differ from one place to the next.

In transportation and mobility, disruption notices are often written several times over by different people under time pressure. The website names one stop, the social post another, and the signs still show an earlier version after dispatch has changed the plan. Riders end up comparing channels, and the customer information team spends the disruption correcting its own messages.

The illustration shows the run detail for a bus bridge notice between two stations, badged as published, with a note that a webhook from a rail control request started it; the design also allows a dispatcher to start the run by hand. A node timeline marks each step complete: the webhook trigger, fetching the bus bridge plan from MoveTheWheels, drafting the notice from a service alert template, approval by a named approver from customer information, and publishing with five of five channels sent. A last step waits for a plan change. The Approved notice panel holds the text riders read: which section is closed, where the shuttle buses stop and how often they run, that the shuttles are accessible and that passes and tickets are accepted, with a chip confirming that the stop names match the plan version the run fetched. Channel previews show the same opening line for the website banner, the rider app, a social post, stop displays across a set of signs and the Botlit service alerts knowledge base, each with a sent or updated time. A Next update card explains that the run republishes when dispatch changes the plan and counts today's revisions, and the header offers Republish from latest plan and Publish all-clear.

Two other Burdenoff products take part by design. MoveTheWheels is designed to supply the bus bridge plan and its stop list, so the notice is built from the same plan dispatch is running. Botlit is designed to receive the approved text in its service alerts knowledge base, so an assistant answering riders gives the same stops and times as the signs. FluidGrids holds the sequence, the approval and the delivery status for each channel. When dispatch republishes the plan, a new run is designed to update the notice everywhere, and ending the bus bridge publishes the all-clear.