An ops lead's morning, before anything has gone wrong.
The new version of Fleet ships in the next few weeks. Rather than write a release-notes post about it, I want to walk through what a Tuesday looks like for an ops lead with Fleet open in a browser tab and a coffee in their hand. The features come out in the workflow.
This is a composite day, not a single customer. Every moment in it is one we’ve seen.
7:42 AM — the inbox paragraph
Before the ops lead opens the app, the app has already opened an email for them. It’s two short paragraphs about yesterday: which assets ran outside their normal window, which alerts fired and at what time, what CMH accrued across the fleet, and whether any hub changed state overnight.
The paragraph is written by a model. The numbers in it aren’t. The model is reading the same query results the dashboard reads — its job is “say what happened in plain English, exceptions first.” Our job was making sure it can’t make up a number. Every figure in the prose is also visible in the report linked at the bottom.
The first version of this email was a 20-tile dashboard. Nobody read it. The one-paragraph version gets read.
8:15 — the dashboard, walked once
The first thing the ops lead opens is the dashboard. It’s one screen, live: asset count, online/offline split, hub status, the day’s utilization trend, recent alerts.
It’s not a screen they study. It’s a screen they sweep once. The state they care about is in the deltas — what’s red that wasn’t yesterday, what’s spiked off the trend, what the alert badge in the corner just incremented to. Everything updates in place. No refresh, no five-minute polling stagger.
If nothing’s red, they close the tab. Most days, they close the tab.
9:30 — something’s offline
Today the badge says one new alert. A hub at the south yard hasn’t checked in for 45 minutes. They click through.
The hub health page knows what they’re going to ask before they ask it: last-seen timestamp, signal at last check-in, battery, firmware version, and the list of assets that hub was watching when it dropped. The page also offers a one-click cellular-router status check — power, signal, SIM, last APN handshake — without logging into anything else.
In this case, it’s the power feed. The fueling crew bumped a breaker. A site contact gets called. The hub comes back at 9:48. The alert auto-clears, an ack event lands in the audit log, and the ops lead moves on.
11:00 — the CMH that doesn’t look right
An equipment page shows a generator at 14,200 CMH. The maintenance supervisor said yesterday they’d just done the 14,000-hour service. The number should be closer to 14,050.
Two clicks: open the asset, hit “CMH adjustments.” There’s a form — offset, reason, the on-board reading the technician saw, who’s making the change, when. The edit propagates to the ingestion pipeline in milliseconds. Within a few seconds, the dashboard reflects the new number, and the adjustment lands in the audit log with the technician’s name, the previous value, the new value, and the note.
The CMH number is now right. The history of why it changed is preserved. Both matter — for warranty especially, which we wrote about separately.
1:00 — a piece of equipment moved
The site manager at the north yard calls. Excavator E-14 is being transferred to the east project for the rest of the month.
The ops lead doesn’t have to update anything. Within a few minutes of E-14 arriving on site, its BLE tag stops being seen by the north-yard hub and starts being seen by the east-project hub. Fleet records the handoff automatically: timestamp out, timestamp in, hub-to-hub. The move shows up in E-14’s location timeline and in the east project’s site page. Nobody filled in a form.
If the move is wrong — a mis-detection, or a tag in a pickup that’s only passing through — the ops lead can correct it. Most days, they don’t have to.
3:30 — the weekly report
Wednesday is when the regional manager wants their utilization summary. Fleet has already scheduled it to send tomorrow at 6 AM. The ops lead opens the preview to make sure nothing’s broken before the manager sees it.
The report has a paragraph on top — the same kind of prose preamble as the morning email, but specific to this report. “Utilization was 71% across the fleet this week, down 4 points from last week. Two assets at the south yard are pulling the number down: S-09 and S-12 spent 38% and 41% of their available hours idle. S-09 also ran hot three days in a row.” Then the tables.
The preamble flags the rows worth looking at. The regional manager reads the paragraph, glances at the table, signs off. The five-minute PDF-scroll became a thirty-second skim.
4:50 — the audit trail
Before logging off, the ops lead opens the audit page. Every CMH adjustment from the day, every alert acked, every report delivered, every login. They scan it the way some people scan their inbox before closing the laptop.
It’s not a feature people demo well. Customers ask for it after their first warranty dispute or their first compliance audit, and then they ask for it always. We treat it as load-bearing.
What we didn’t build
Things the new Fleet specifically doesn’t do, on purpose:
- It doesn’t predict failures with a model. CMH thresholds and trend deltas catch what matters; a model would add latency and a number nobody can audit. We wrote about why.
- It doesn’t let you write rules in natural language. Routing logic that pages the night-shift supervisor needs to be readable, testable, and unsurprising. We type the rules.
- It doesn’t surface every event. The dashboard exists to make exceptions visible — the rest is in the report or the audit log, where it should be.
The thing that makes Fleet work isn’t a feature. It’s that an ops lead can keep it open for eight hours and learn things, not click around looking for them. Everything in this version went through that filter.