Drivers/Track · The Chemistry Was the Spec (2016-2017)

Ready-mix concrete has a clock. Miss the handling window and the product is garbage, so every screen, alert and route decision in this thing was designed backwards from one number: the minutes left before the load dies. Everyone in the room saw a delivery-tracking app. I saw that the chemistry was the real spec.

A ready-mix truck rolls out of the plant with a drum full of a product that is already busy expiring. Cement and water started reacting the moment they met, and from there you have a window, a couple of hours if the weather is kind and a lot less if it isn't, before the whole load turns into an expensive rock that nobody can pour and nobody wants to pay for. That is the business, spinning inside a drum, sitting in traffic.

Read the product, not the brief

The justification I was handed had four bullets on it. Assist the drivers, track deliveries in real time for the operation and the customer, close some technological gaps with mobile, and collect data to streamline the process. All perfectly reasonable, all describing a map with trucks on it.

Do I think that brief was wrong? No. I think it was a description of the artifact instead of a description of the problem, and those two things get confused constantly. So before drawing a single screen I went at the product itself, the actual grey stuff in the drum, and the first layer of insight in the whole project came out of its inherent characteristics rather than out of any user interview. Ready-mix concrete has a maximum handling time. Past it, you discard the load entirely. That is the worst case scenario for the company and for the customer at once, which is a rare thing in business, and it means the clock isn't a constraint on the experience. The clock is the experience.

Once you accept that, the feature list stops being a debate and starts being arithmetic. Show the point of delivery precisely, because a driver circling a jobsite is burning the product. Plan the routes around traffic and roadblocks, because minutes are literally the product. Know which trucks are coming back and when, because availability is the only way to keep the next load from waiting. And digitize every document around the delivery, from the truck inspection to the proof of delivery, because paper is slow and slow is the enemy.

The team

Uber never had to worry about the cargo dying

We started where everybody starts, with the desk. Uber and Google Maps for the interaction patterns, because by 2016 those two had already taught the entire planet what a moving dot on a map means, and there is no reason to re-teach a grammar people already speak. Titan GPS and Command Alkon for the competitive read, because fleet telematics was a solved industry and we needed to know exactly which parts were solved.

Here is what that exercise gave us, and it wasn't a feature list. It was a very clear line between what we could borrow and what nobody had built. Uber tracks a car whose passenger is merely impatient. Telematics tracks an asset whose owner wants a fuel report at the end of the month. Neither of them has ever tracked a cargo that is quietly dying on the way over.

Everybody who touches a load

A delivery is not a driver and a customer. It is a plant, a dispatcher, a driver, a jobsite crew, a person authorized to sign, and a salesperson who will hear about it if any of them has a bad day. We mapped the whole chain first, because every one of those profiles owns a slice of that countdown and can lose it for everyone else.

What the operation actually needed

The company wanted the delivery process streamlined, and to streamline anything you first have to collect everything, so data capture was the price of admission. But field observation turned up a set of needs that no dashboard was going to satisfy on its own. Drivers had to be told the schedule for the next shift and to confirm it back, the operation had to locate any truck in the fleet at any moment and hear about the irregular events along a delivery, availability had to be calculated from the units already on their way back, the delivery documents had to append themselves without a human touching them, and any past delivery had to come back up on demand for the forensic conversation that always comes later.

That last one deserves a note. When a pour goes wrong on a jobsite, everybody has a story, and the stories rarely agree. A trip record with timestamps ends that argument in about ten seconds, and I have watched it happen.

Then we went and watched the drivers

Observing the delivery process directly is where the tidy diagram meets the parking lot, and the pain points came out plain. A driver may not know the delivery schedule or when the shift even starts, because that information travels by phone call and phone calls get missed. The location of the delivery point may be a mystery, since a jobsite is not an address in any sense a mapping service understands. Drivers wait to unload, sometimes far longer than anyone planned, for reasons entirely outside their control, and their productivity takes the hit. And at the end of it all they have to find the one person authorized to sign a proof of delivery, who is somewhere on a construction site, possibly wearing the same helmet as everyone else.

None of that is a technology gap. It is a communication gap that had been living inside a telephone for forty years.

Time is the master for our customers too

On the other side of the gate, the customer wants exactly one thing after ordering: the delivery lands when they were told it would land. And this is not about politeness. A construction crew is a small army standing around waiting for concrete, paid by the hour, and every minute the truck is late is a minute of people leaning on shovels. Giving them visibility into the transportation process is what lets them synchronize their own crews, and that turned out to be the part customers valued most, more than any screen we drew for them.

One process, many profiles, many applications

A driver holding a phone in a truck cab and a dispatcher sitting in front of three monitors do not want the same software, and pretending otherwise is how you end up with an application that serves nobody. So the process got broken into the applications the diverse profiles actually needed.

There's an app for that!

Recording delivery data and fixing the drivers' pain points landed in the same place, which is the happy accident you always hope for. Both wanted a phone in the cab.

The trick was that the operation saw the app as a tracking device, and the driver had to see it as something that made his day better, otherwise it never gets opened and you have a very expensive GPS beacon. So it tells him his shift and lets him confirm it, points him at the exact delivery point, walks him through the steps of the process, hands him the ticket, and turns proof of delivery into a signature on glass instead of a hunt for paper. The tracking rides along for free, because the driver is already carrying it.

A delivery happy path

The office half of the countdown

Put a phone in every cab and you have just handed the operation a problem it didn't have yesterday, because now there is a river of live data pouring in and the existing systems have no idea what to do with it. The console was the other half of the build, and it had to cover what the app had made possible: retire the phone call and schedule the shifts with push notifications instead, track the trucks live on a map, find a specific unit by the trip meta-data a person actually remembers, the driver, the order number, the associated plant, draw geofences that fire automated events along the journey so the timeline writes itself, and pull any trip back up after the fact.

Geofencing is the quiet hero of that lot. A driver focused on driving is not going to tap "I have arrived", and honestly he shouldn't have to, so the plant gate and the jobsite report the event themselves and the paperwork stops depending on anybody remembering it.

Tying it all together

The driver app and the console didn't stay a project. They became a layer, and the rest of the ecosystem grew on top of it: apps for the jobsite field personnel, and eventually the tracking section inside the Cemex Go suite, where a customer opens a screen and simply sees the truck. That is the reason I keep telling this one. The map everybody wanted at the start did get built, it just got built last, on top of a model that understood what it was counting.

The payoff was engagement from customers who no longer had to call anyone to find out where their concrete was, less friction across every profile that touches a load, and a brand that the industry started reading as the pioneer rather than the incumbent. Which is a nice thing to put on a slide, though what I actually took from it is smaller and more useful: when a brief describes an artifact, go find the constraint the artifact is really made of. In this case it was sitting in the drum the whole time, hardening.