If you walk into a fleet maintenance shop, you will usually notice it within 20 minutes.
There is a Monday.com or Trello board up on a screen showing who is working on what. An Excel file open on a monitor on the floor, tracking PMs. There is a bright red Google Sheet that started as a workaround for core returns a few years ago that never went away and has changed hands 12 times. And there are the constant text threads, sticky notes, WhatsApp messages, and conversations happening across the floor all day.
Fleets and service shops will pay six figures a year for maintenance software and still run the bulk of their operations somewhere else. This is not because they want to. If anything, running a shadow system is often making their lives a lot harder.
What has happened, almost without exception, is that they have had to build a second system alongside the one they bought: a set of tools and processes that actually reflect how the shop has to run day to day. The official system still exists but it is just not where the work actually happens.
Hello Trello
A few months ago, we first walked into a for-hire trucking fleet shop with a few hundred power units and a small, but growing external repair operation. On paper, they had a full (and very expensive) maintenance software implemented. In practice, the shop was running the day to day almost entirely through Trello, Excel and text.
We were surprised to learn there was not one clear, single reason they ended up there. It was the slow accumulation of small frustrations: UI that was tough to wrangle, views that were hard to trust, workflows that took too many steps, updates that lagged what was actually happening on the floor. At some point, it simply became easier to run the shop somewhere else and update the system of record later.
What this looks like in practice
The clearest signal of the problem showed up almost in the repair orders. We found ROs were closed in the maintenance software that were still active cards in Trello, and jobs marked complete on the board that still appeared open in the system of record. Two versions of the same work existed at the same time, both partially accurate, neither reliable on its own.
The people running the shop had adapted. They knew which system to check depending on the question they were trying to answer. If you wanted to know what was actually happening right now, you looked at the board and if you needed something for reporting or audit, you went into the legacy software. They were doing the reconciliation in their heads.
Why shops build a second system
This pattern shows up for the same reasons, over and over again.
First, the shop needs to operate in real time. Trucks arrive early, PMs pop up or slip, parts get backordered, drivers call asking for status. The system that runs the shop has to reflect what is happening now, not what was true at the end of the last shift. The boards update instantly. The CMMS is really hard to update and it tends to lag, sometimes by hours, and even at times, by days.
Second, everyone in the shop needs access to the same view. A foreman is walking the floor, a technician is under a truck, a service writer is on the phone, and a driver is standing at the counter. A shared board on a screen works for all of them at once. A system that requires logging in at a workstation does not.
Third, the work itself is not always clean. A driver mentions a soft brake pedal in passing. A foreman wants to take a look at a unit the next time it comes in. A warranty question is waiting on a callback. None of that fits neatly into a repair order or a PM schedule, but it is still real work that needs to live somewhere. The shadow system gives it a place to exist.
Fourth, there is usually no infrastructure to support anything more complex. Most fleets in the 50 to 500 unit range, or service shops with 1-2 shops, do not have dedicated IT teams. Tools that require implementation, configuration, or ongoing administration tend to lose to tools that can be set up in minutes. “We’ll just track it here for now” is how most of these systems start, and for now quietly becomes permanent.
Finally, and most importantly, shops lose trust in the system of record. When repair notes are incomplete, parts are not linked correctly, and reports do not match what actually happened, people stop relying on what they see in the system. The shadow system is not only easier to use; it becomes the version of reality the team believes. Once that happens, it is very difficult to reverse.
What the existing systems still do well
It is worth acknowledging that legacy software systems are not without value. They handle the structured side of maintenance. They can be used to produce cost reports, manage PM schedules across multiple meters, track inventory against repair orders, and generate the documentation required for accounting or audits. The problem is not that those capabilities are missing. It is that they exist separately from the way the work actually gets done.
So shops end up running both. The shadow system to operate, and the system of record to document. The assumption is that the two will more or less stay aligned when in reality, they usually do not.
Why this breaks down in maintenance
In many industries, a shadow spreadsheet is an inconvenience but in fleet maintenance, it creates a deeper issue because the data compounds over time.
The way a repair is documented today affects whether a warranty claim can be filed months later. The completeness of repair orders over the course of a year affects decisions about when to retire or replace equipment. Inspection records need to match reality not just for today, but for audits that may happen years down the line.
When the system of record is only capturing a partial version of what actually happened, several things begin to break. The first is that the data becomes an undercount. In many of the shops we work with, the CMMS is capturing only a portion of the actual work performed. That means every report, cost per mile, reliability trends, shop productivity, is based on an incomplete picture.
The second is that warranty recovery suffers. Warranty claims depend on accurate and complete documentation: the correct part, the correct failure code, the correct labor, and the correct timing. When the real work is captured informally and only summarized later, claims are missed or denied. For fleets of this size, that can amount to hundreds of thousands of dollars a year.
The third is that preventive maintenance becomes less reliable than it appears. When the real tracker is a spreadsheet or a secondary system, compliance depends heavily on the person maintaining it. When that breaks down, intervals slip, defects go unaddressed, and out-of-service events become more likely.
Finally, institutional knowledge becomes fragile. The details of how the shop actually operates often live in individual tools or in individual people’s heads. When those people leave, or those tools disappear, the underlying system disappears with them.
At that point, the shadow system is no longer a workaround. It is the actual operating system of the shop, even if the official system suggests otherwise.
What a good, real-time system should look like
The gap here is not hard to describe. In many ways, shops have already defined the requirements themselves through how they have chosen to work.
The system that runs the shop needs to be the same system that records it. The board cannot just be a view into the data; it has to be the source of truth. When a job moves, the status of the repair order should move with it. When work is performed, the documentation should be created as a byproduct of that work, not as a separate task at the end of the day.
At the same time, the system has to accommodate the reality that not all work starts as a clean, structured record. There needs to be space for the early signals; the driver comments, the informal checks, the customer call, the “take a look at this next time” notes to live alongside the formal repair orders and schedules.
And critically, the simplicity that makes boards usable needs to coexist with the depth that makes a system of record valuable. Every item on the board has to map to a real, complete record underneath, even if the user does not have to think about that structure explicitly. This is not a new idea. It is what shops have been trying to build for themselves for years.
Where this leads
When the system that runs the work is also the system that records it, a few things change in a meaningful way.
Repair orders tend to be more complete, because they are generated from the work itself rather than reconstructed after the fact. Warranty claims are easier to file and more likely to be accepted, because the underlying data is consistent. Preventive maintenance becomes more reliable, because it is tied directly to the flow of work rather than maintained separately. And the amount of administrative overhead required to keep the system accurate starts to decline instead of grow.
Most importantly, the need for a second system disappears. The shop no longer has to choose between something that is usable and something that is auditable.
Why we built it
We started Axle from the observation that the industry has been trying to solve this problem in the same way for a long time, usually by asking shops to use existing systems more rigorously or by adding additional layers on top.
What seemed more straightforward was to take the way shops already operate and treat that as the starting point. If the board is where the work happens, then the board should be the system of record. If the work is messy at the beginning, the system should be able to handle that mess without losing structure downstream. If the goal is complete, usable data, that data should be created as part of doing the work, not as a separate process.
The intent is not to replace how shops operate, but to make the way they already operate produce the outcomes they need: accurate records, reliable reporting, and less administrative overhead to hold it all together.
Axle Mobility is the system of execution for fleet repair and maintenance, so techs, fleet managers and fleet executives can focus on rolling trucks and making money, not mindless admin.