A century and a half after the invention of the original telegraph, supply chain visibility remains a 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. But the map is not the territory. The ease with which a locomotive moves down a track belies the complexity of the industry. 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 had no set plan to build a single tool or feature. Rather, 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 all know the rate that needs quoting, the rejected tender, the lost car, the surprise demurrage bill, the overdue linehaul invoice. None of it lived in one place. A lack of clean information 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, rail shippers 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 rail shipper’s problem. We didn’t start Telegraph to help people manage. We started it to help them operate better, no matter where they sit in the industry. And what we found was rail shippers across the industry 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.
A modern rail 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 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. Once that’s true, the software 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 a RMS helps answer “where is this specific railcar and when will it arrive?”, ROS is answering all of that in one place.
The telegraph never moved a single train. It moved what the network needed, and that changed how the industry worked together. We’re building the same thing for an industry that has spent a century able to see farther than it can act. Visibility was just the beginning. Coordination is how we finally put it in motion.