read time • 5 mins

Introducing Telegraph’s Rail Operating System: Clarity Was the Input, Coordination Was the Output

Introducing Telegraph’s Rail Operating System: Clarity Was the Input, Coordination Was the Output

Before the telegraph, rail stations only knew what was within line of sight, or what was carried in by horseback. A train meet was a judicious and risky decision, often coordinated by a timetable. The horizon was the edge of the world, and everything past it was merely a guess, or an assumption.

Eventually a line of poles went up beside the track, wires strung between them, connecting operators and dispatchers from station to station. It was here that the first real railroad operational data moved electronically. Then came the news of the day. With that, the speed of movement and the speed of knowing changed overnight, accelerating decision making to a pace previously unknown.

We registered the business as Telegraph System on purpose. Our role was, and remains, connecting the rail industry and driving meaningful outcomes.

A century and a half after the invention of the original telegraph, supply chain visibility still remains an ever-present goal on the horizon. When you strip away the language, transportation is simply the business of inventory in motion. In rail, that inventory happens to be enormous. In North America, it also happens to move across 140,000 miles of track split into roughly 600 private networks, each with its own data and workflows. Drawn on a diagram, everything seems connected. Yet, the map is not the territory. The ease with which a locomotive moves down a track belies the complexity of the industry and the massive orchestration required to simply move a railcar from one location to the next. Visibility, or dots on a map, might tell you where the shipment was, but it says nothing about why the delay happened. Coordination was always the output we were after.

When we started Telegraph, we knew the industry required more than a point solution. When we spent time at shipper facilities, joined 05:00 shortline operations calls, helped 3PLs complete RFPs, and tried to map the litany of manual workflows that keep the industry in motion, we were struck by how many decisions are made on stale operational data. Of course, we all know the rate that needs quoting, the rejected tender, the lost car, the surprise demurrage bill, the overdue linehaul invoice. However, none of it lived in one place. A lack of usable data often delayed the right action. Telegraph’s vision was always to bring clean, enhanced information to rail shippers in one place and enable them to solve their operational work in a single united platform. 

Since our launch, customers have understood and appreciated the vision and the ease of integration and use. But one inevitable question we often got when introducing Telegraph was the name of the product or category. Would we say Telegraph is a transportation management system (TMS)? No. A rail management system (RMS)? Not quite. Asking what kind of management system we were building was, in and of itself, the wrong mindset. It assumed the solution to a railroad’s workflows, or an equipment owner’s process, or a shipper’s specific method. We didn’t start Telegraph to help people just manage. We started it to help them operate better, no matter where they sit in the industry. And what we found was every node of the rail ecosystem needed more. They don’t just need to see the information. They need the tools to do all the operational and executional work after they have the information. And that’s what Telegraph set out to provide. 

Enter the Rail Operating System

Any meaningful industry deserves tooling that does more than watch. When we bring together our data, integrations, applications, and AI, it becomes clear that we’ve built a system of doing. We call it a Rail Operating System (ROS) because it’s inherently designed to get things done.

ROS sits between the connections that tie the industry together. Each of the players — the railroad, the shipper, the lessor, the repair shop, the terminal — all read from and write to the same live record of the same move. Now that this is true, the software — and increasingly, agents — can stop reporting and start acting. It sees a car about to miss its window and reorders the pull before it does. It catches the demurrage clock the moment it starts, and settles the charge before it turns into a fight. When a shipment slips, it tells the customer and opens the inquiry with the carrier on its own.

If a TMS primarily helps answer “which mode or carrier should move this load and what will it cost?”, and an RMS helps answer “where is this specific railcar and when will it arrive?”, ROS is answering all of that in one place.

The truth is, the telegraph never moved a single train. It moved information, which is what the physical network actually needed, and that changed how the industry worked together. We’re giving rail what the telegraph once did: a way to turn what it knows into informed action. Visibility was just the beginning. Coordination is how we finally put it in motion.

Resources

Experience Matters

Linkedin View All
read time • 9 mins

Railroading’s Transition to Telematics (Part Three): Consider the Choreography

read time • 1 mins

UP-NS Merger Concessions, Energy Prices + BNSF’s Barstow Bet

Want to see the Telegraph platform for yourself? Schedule a demo with our team today!

Book a Demo!