Operations control room software for fleets and sites
An operations control room is one real-time system that reads telematics, dispatch, planning, maintenance and ERP data, rebuilds what is actually happening (which assets are available, which tours are late, which trips lose money) and routes each exception to the person who can act on it. Mirage builds it around the systems a fleet, mine, port or quarry already runs, and operates it with the client's team; one such control room runs across two port terminals at Mass Céréales Al Maghreb.
The problem
Operations get tracked across separate tools: GPS, TMS, ERP, planning, spreadsheets, maintenance, delivery notes, customers and drivers. Each tool tells part of the story. None of them, on its own, tells management what is actually happening across the operation.
Teams cannot easily see which vehicles are available, which are down, which tours are running late, which trips are profitable, where the bottlenecks are, and whether the real operation still matches the plan. The answer usually exists, spread across five screens and a WhatsApp group, and reaches the manager the next morning.
What we deploy
A centralised system for tracking operational execution: fleet availability, vehicle and tour tracking, planned versus actual, activity by site, customer and job tracking, profitability per trip or operation, alerts and exceptions, and a direct link to maintenance and asset downtime, all consolidated from TMS, telematics, planning, ERP and field data.
It is not a BI dashboard, not a GPS map and not a generic TMS. It is an operational layer built around the client's real flows, connecting the tools already in place instead of replacing them, so teams see what is happening on the ground, not a visualisation of raw data. At Mass Céréales Al Maghreb, one AI control room runs across two port terminals and no core system was replaced.
Inputs, outputs, systems
What the control room reads, what it writes and where it connects. The exact list is set at the first meeting, from the systems your operation already runs.
| Reads | Produces | Connected through |
|---|---|---|
| GPS positions and engine data from the telematics provider, every few seconds | Reconstructed tours: departure, loading, transit, unloading, return, with idle and waiting time | Telematics API or scheduled export (Geotab, Teltonika, Webfleet and others) |
| Planned tours, orders and assignments from the TMS or dispatch tool | Planned versus actual per tour: late, early, skipped, re-routed, with the cause where it can be read | TMS API, database view or file drop |
| Vehicle status, work orders and downtime from the maintenance system | Fleet availability by hour: available, on mission, down, in workshop, with the next planned intervention | CMMS API or export |
| Customers, rates, invoices and costs from the ERP | Profitability by tour, client or vehicle, from revenue and the costs that can be attributed | ERP connector (SAP, Oracle, Microsoft Dynamics, Sage and others) |
| Fuel transactions, weighbridge tickets, production counts where relevant | Consumption per vehicle, tonnage per tour, exceptions when the three disagree | Fuel and weighbridge systems, or the Mirage fuel and weighbridge modules |
| Driver and field reports, delivery notes, photos | Events attached to the right tour and vehicle, exceptions raised from them | Mobile app, email or WhatsApp export, as the team already works |
Outputs are written back where they are needed: an exception to the dispatcher's queue, a downtime record to the CMMS, a tour cost to the ERP. Nothing is migrated; each existing system stays the record for its own data.
How it works
Mirage engineers connect directly to telematics and GPS, TMS, planning, customer, fleet, driver and maintenance systems, and, where relevant, fuel, weighbridge or production data, then normalise all of it into one operational model: assets, sites, tours, orders, people, events.
Raw signals become operational events. A GPS trace, a planned tour, a customer and a vehicle status combine into a reconstructed real tour, a delay, an availability gap, an exception or a profitability figure. Rules written with your dispatchers decide which events matter (a truck idling more than twenty minutes at a loading point, a tour starting more than an hour late, a vehicle out of its sector) and who is told. Each exception carries its evidence: the positions, the plan and the record that disagreed.
Operational interface
This is an operational system used to run the site, not a report reviewed after the fact.
- Operational map with vehicles and sites
- Fleet status: available, on mission, down, in maintenance
- Planned vs actual execution
- Active tours
- Alerts and exceptions, each with its evidence
- Activity timeline
- Profitability by tour, client or vehicle
- Maintenance and downtime
- Management view with operational KPIs
- Operator view with actions to take
How do you choose between a BI dashboard, a TMS module and a control room?
Three products answer the same wish, to see the operation in one place, and they are not interchangeable.
| BI dashboard | TMS tracking module | Operations control room | |
|---|---|---|---|
| Data | Yesterday's extracts, refreshed on a schedule | The TMS's own tours and vehicles | Every connected system, in near real time |
| Reconciliation | None: shows each source as it is | Within the TMS only | Plan against GPS against ERP against maintenance, event by event |
| Exceptions | A chart someone has to read | Alerts on TMS events | Routed to the person who can act, with the evidence, and logged |
| Writes back | No | Into the TMS | Into the TMS, the CMMS and the ERP, as agreed |
| Fits when | Management wants monthly trends | One TMS runs the whole operation | Several systems, several sites, and decisions that cannot wait for the morning report |
If your whole operation runs inside one TMS and the questions are about last month, you do not need a control room. If dispatch, maintenance, fuel and finance live in different systems and the questions are about now, you do, and the first one to build is usually planned versus actual for the fleet.
How it is deployed
Forward-deployed: Mirage's engineers work on your site, with your dispatchers and fleet managers, from the first meeting to production and after. The clocks below are the published ones for every Mirage deployment.
- First reply
- Within two business hours, from an engineer.
- Proof of concept
- On your own data (a telematics export, a transaction log, weighbridge tickets, dispatch records), one week after the first meeting.
- Pilot
- Fixed price, on one site or one fleet, with Mirage engineers deployed with your team. You can stop after it.
- Production
- The first workflow runs in 4 to 6 weeks. A system that spans several sites or a lot of field equipment is scoped at the first meeting and can take longer.
- After go-live
- Mirage operates, monitors and improves the system in production; your team keeps the decision on every exception. More than 200 systems have been connected so far.
- Price
- An annual subscription priced by volume after the pilot, from $10,000 to launch and $1,000 a month, quoted in the first conversation.
Transwin, a Moroccan logistics operator with 550 trucks and more than 100 machines, started with one document workflow and now runs five systems in production, a control room among them. The method is set out on the forward-deployed engineering page.
FAQ
See what Mirage can run in your operations
Get a custom automation plan
Tell us where your operations lose time. We send back a written plan: which workflows are worth automating, what a deployment looks like on your systems, and the shortest path to production. No commitment.
Prefer to talk it through? Book a call