See Who and what the delay affects.
When a service is raised as late, the console lists the crew on shift, the stops downstream, the freight on board and the customers waiting for it. Nobody has to ring around to build that list.
Operational Decision Intelligence
Your trains, trucks and terminals already report their position every few seconds. We build the layer that turns that data into a decision, so when a service runs late your controllers can see who it affects, compare the options and commit to one, with the reasoning kept.
What we do
Operators know where every train, truck and container is, to the second. Deciding what to do when one runs late still takes hours, and every hour the delay reaches more services, crews and customers.
We build the layer that closes that gap. When a service is raised as late, the controller sees who it affects, compares the responses and commits one, with the reasoning kept.
The proof
This is a working console, built from the live operations tools we have delivered for Australian operators. We configure it to your network, your crew rules and your customers. Book a demo and bring a disruption from last week, and we will run it through.
Book a live demoThe challenge
Your assets report where they are every few seconds. The decisions about them still take hours, and they are made from spreadsheets, phone calls and experience. That leaves controllers choosing between two bad options.
How we help
The four steps run in the order a controller takes them when a service runs late.
When a service is raised as late, the console lists the crew on shift, the stops downstream, the freight on board and the customers waiting for it. Nobody has to ring around to build that list.
You can re-crew at the next depot or hold the service. Each option shows its new arrival times, who has to be told, and whether it breaks a crew or customer rule. Nothing changes in your systems until you choose one.
Once you commit the response, crewing, the terminal and the customer team see the same decision at the same time, instead of hearing about it by phone over the next few hours.
Each decision is stored with what the controller saw, which options were compared and why one was chosen. That record stands up to a customer query, a regulator and your own review.
How it compares
| Our decision console | Tracking dashboards | Spreadsheets and phone calls | |
|---|---|---|---|
| Works with the systems you already run | Yes | Yes | Yes |
| Shows where every asset is, live | Yes | Yes | No |
| Shows who a disruption affects, all at once | Yes | No | No |
| Compares the responses before you commit | Yes | No | No |
| Puts the decision where the whole team can see it | Yes | No | No |
| Keeps a record of what was decided and why | Yes | No | No |
Proof
The console grew out of tools we have built for two Australian operators, one in rail freight and one in transport energy.
An Australian rail and bulk transport provider
One of Australia's largest rail freight operators had rich locomotive telemetry and wanted a product built on it. Digizoo worked with its digital team and its planners to trace the data to the decisions made each shift, then built a live view of trains, locos and crews on the systems it already ran. Internal NPS at release was 86, and the design system we set up cut concept-to-design time in half.
“So much easier than the way I used to do it through a few different screens.”
Planner, internal user
Ampol
Ampol's shift into a broader energy business needed digital products, new billing and market integrations and the team to ship them. Digizoo enabled and scaled the Ampol Digital Team, delivering the integrations with the Australian Energy Market Operator and the apps customers use for the new products.
How we work
This is not a data warehouse and it does not replace your TMS, terminal system or telematics. It reads from them and adds the step they leave out, which is deciding what to do.
We read timetables, rosters, consignments, track possessions and customer service levels from the systems that own them. Nothing is copied or moved.
We join those records into one model of your operation, so a late service shows everything it affects in one view instead of across five systems.
The controller sees the impact, compares the responses, commits to one and the record is kept. The decision then flows back to the systems and the people it affects.
Outcomes
About twenty controllers, assuming a five percent productivity gain, which is our floor.
Based on our internal model. We will rebuild it with your numbers before you commit.
Ship, port, rail, road and customer, as more of your partners join.
FAQ
No. It reads from your data warehouse and your operational systems and works out the decision from what they already hold. It does not copy or move your data.
No. It works from the data your current systems already produce. Replacing an operational system takes years. Adding this on top takes weeks.
We start with one desk. A short first engagement measures what today's disruptions cost that desk in time and phone calls, using your own data, and gives you a business case for your approval process. Then we stand the console up on that desk. Once it is proving itself there, we extend it across the operation.
Today each company in the chain sees only the part that concerns it. As your partners join, the console shows the whole journey from ship to port to rail to road to customer, and a delay at one end is visible at the other before it arrives.
Yes. The console on this page runs today on a prototype network with sample data, and we will walk you through it live. Bring a disruption from last week and we will show you how it would have run.
Get in touch
Tell us what happened, who found out when, and how the call got made. We will show you how it would have run through the console.