The Problem
Fleet managers were spending half their day just switching between screens. Not doing the actual work—just hunting for information across fragmented systems.
Machine owners couldn't tell if their machines were whispering maintenance suggestions or screaming that something was about to break. Service schedulers saw fault codes all day but had no way to know if yesterday's error was still relevant or if today's emergency was actually an emergency.
Only 48.7% of scheduled maintenance was getting done. The other half vanished into unchecked calendars and notifications that never got sent or got buried in email.
The machines were fine. The humans were drowning.
What We Heard
We interviewed two dealer teams—RDO and Vermeer Texas. What came out wasn't "the interface needs better buttons" or "add more filters." It was way deeper.
Greg from Vermeer Texas told us: "Just my location here at Selma, we might have 160 machines that are throwing some kind of code. Three minutes on a machine, I'm not going to get through that list in a day... especially when you're on top of that trying to find customer contact information." He was jumping between four different systems just to take one action.
Another said: "The winter time, early morning startups hydraulic filter restrictions... almost every machine's going to do it until it's warmed up. And those are, for somebody who doesn't know what that is, I mean, they automatically start calling." False alarms drowning out real emergencies.
A third: "The data should be there at a point and click. For a fault code, why wouldn't there be a hyperlink to go click on the fault code?... Right now the technician's gonna have to navigate to another screen and start searching for that fault code, even though the information is in that system somewhere."
That's when it clicked. The problem wasn't workflows or features. It was that nobody knew what things existed and how they connected.
The Method
We stopped asking "what pages do we need?" and started asking "what actually exists in their world?"
Five core objects emerged from the research.
MACHINE—not just a serial number, but a thing with its own history, quirks, service records. A dealer literally said machines have "attitudes" and technicians needed to document that.
FAULT CODE—these have severity levels, frequency patterns, machine-specific behaviors. We heard that fault codes relate differently to different machine types and conditions. Some codes whisper. Some scream. We needed to know the difference so we could show what mattered.
SERVICE RECORD became the institutional memory they were missing—linking what was planned to what actually got done. It was also a separate system that needed to be factored into how it integrated with the telematics platform. Another product. More data. Another team.
MACHINE GROUP made mental models real. "My Idaho fleet" or "rental equipment" aren't filters, they're how people actually think about their territories. This was lacking, so we got down to brass tacks and moved on.
NOTIFICATION—these couldn't just be alerts. They needed to arrive with enough context to act on, timed to be helpful instead of overwhelming, with controls to quiet the din.
The Solution
Consolidated platform bringing together fleet health, fault codes, service history, and maintenance planning. No more jumping between four systems to take one action.
Fault code intelligence that understands severity, frequency patterns, and machine-specific context. Urgency-aware views that help users triage by signal not noise.
Proactive maintenance system with reminders, scheduling, and connected service history. Shifting from reactive firefighting to planned work.
Flexible views—list, map, saved machine groups—that mirror how people actually think about their territories and fleets.
Notifications timed to be helpful with enough context to act on, not just alerts that create anxiety.
What Changed
The dev team moved 39% faster with this object model in place. Feature output was roughly 8x compared to peer teams working without this kind of structural clarity. Those numbers came from the engineering director comparing sprint velocity and feature throughput across teams.
The maintenance KPI we were targeting—moving from 48.7% completion toward 75%—well, we never actually got the data back. Large organizations are fractured beasts where metrics wander into forgotten spreadsheets and nobody circles back. It happens.
But here's what I think about: somewhere, a fleet manager is going home on time instead of staying late to check if everything's okay. A service tech is triaging work by actual severity instead of just responding to whoever yells the loudest. Operations directors aren't waking up at 3 AM with that gnawing anxiety wondering if something's breaking and they just don't know it yet.
We consolidated their anxiety into confidence. That's harder to measure than a KPI, but it matters just as much.
Lessons for Others
First: Fragmented information creates hidden time waste that's easy to miss in requirements gathering. People accept context-switching as normal until you show them an alternative. Ask "how many systems do you touch to complete one task?"
Second: False positives create as much chaos as missed alerts. When everything seems urgent, nothing is. Building severity and context into notification logic isn't a nice-to-have—it's how you make the system trustworthy.
Third: Mental models aren't just UX polish. "My Idaho fleet" and "rental equipment" are how people actually organize their work in their heads. When your system supports those mental models as first-class objects, adoption goes way up.
Fourth: Object-oriented thinking accelerates delivery. 39% faster, 8x more features. Those aren't aspirational numbers—that's what happens when everyone shares a clear model of what exists.
Fifth: Sometimes the real outcome is emotional. We consolidated anxiety into confidence. That's unmeasurable and invaluable.
Broader Implications
IoT and telematics platforms are everywhere now—agriculture, construction, logistics, manufacturing. They all face the same pattern: machines generate tons of data, but humans can't keep up.
The common response is "add dashboards" or "more alerts." But that just moves the problem around. What these systems need is structural clarity about what exists and how things connect. Object-oriented thinking isn't just for consumer apps—it's how you tame complexity in enterprise IoT.
As more equipment gets connected, the teams that think in objects instead of features will ship faster and build better. The pattern transfers.
The End
Somewhere right now, a service tech is looking at their screen and immediately knowing which machine needs attention. Not guessing. Not panicking. Just knowing.
The machines didn't change. The relationships between the things became visible.
That's all we did, really. Made the invisible visible. Gave the chaos a shape.
Turns out that was enough.
