Runink FACE

Talking to Drivers Without a Screen

The person who knows a load is late is the one who cannot type. Asking and answering out loud gets the fact onto the record while the truck keeps moving, and the desk still makes the change.

20 May 2024 · 8 min read

Runink FACE · Reactive logistics, driver-facing

This is a Runink FACE scenario, the driver-facing end of it. What follows is what the product is built to do and how it would run against your own fleet records. It is an illustration of the mechanism, not an account of a deployment. What FACE is.

In Short

  • The driver asks out loud and hears the answer. Where the next stop is, what the customer asked for, which door to use. No screen to read and no reason to pull over. Every conversational reply is synthesised inside the FACE process itself, from a voice embedded in the binary, and the speech coming in goes to the model server you already run — the one inference endpoint you point FACE at, carrying an audio-capable model — rather than to a speech API somebody else operates.
  • It is a phone call, so it goes over the phone network. The leg between the cab and the building is carried by a telephony provider, the same as any other call your drivers make. What that provider never gets is the text: the transcription, and the reasoning that produces the answer, happen on your machines, and the spoken reply is encoded there too. The provider carries the audio, as it does for any call.
  • What the call produces is a transcript, on the record. Both sides of the conversation are written to the call log, speaker by speaker, so the hour at the gate is recorded the moment it is said. An urgent word on the call does raise something. The same six words are watched on the phone as on the text side — urgent, asap, emergency, broken, failing, late — and a match both changes how the agent answers and sends the caller's own sentence to the manager number you configured. Somebody named on the desk reads the log and makes the change.

Hands On The Wheel.

A driver who has to read a screen to answer a question will either stop the truck or read it while moving. One costs you the hour. The other costs you much more, one day.

Where It Goes Wrong

A load is running late. The driver knows an hour before anyone else, and the office finds out last. To tell them, the driver has to pull in and type, or type while moving. Most days it just waits until the next stop.

It runs the same way in reverse. The desk has a change and has to ring round to land it, one truck at a time, hoping each one can pick up. Half the calls go to voicemail and get made again twenty minutes later.

The person who knows first is the one who cannot type.

So the day gets written up at the end of it, from memory, if it gets written up at all. The tyre that needed air, the hour lost at a gate, the drop that was refused — after eight hours the detail is thin, and the hour at the gate is the one you never bill for.

What Happens Instead

The driver speaks and FACE answers. Where is my next stop. Which gate. It is asked out loud and it comes back out loud, so the eyes stay on the road and the hands stay where they were. The call itself is an ordinary phone call and rides a telephony provider to get there; the audio socket into the building is authenticated, and everything that happens after it arrives happens on your machines. The speech is turned into text by the model server you run — the same single configurable inference endpoint the rest of FACE reasons through, carrying an audio-capable model, rather than a speech API with its own contract — and every conversational reply is spoken by a synthesiser running in the same process as the rest of FACE, from a voice embedded in the binary. No transcript ends up in somebody else's account.

What the call leaves behind is the conversation itself, written down as it happens: each turn, who said it, against the call it belongs to. The hour at the gate is on the record at the gate rather than reconstructed at six o'clock. Six words are watched on both channels — urgent, asap, emergency, broken, failing, late. On the phone a match changes how the agent answers and sends the caller's own sentence to the manager number you configured. On an inbound WhatsApp or SMS the same match escalates the same way, and there a message that matched but reached nobody is written to the log saying so rather than passing as handled. The call gets the fact onto the record within minutes of it happening, where the desk reads it.

What the call does is get the fact out of the cab and onto the record while it is still accurate. A person on the desk reads it and makes the change.

Who Owns This

Three desks, and what each of them is holding today.

  • The dispatch desk. Today a change means ringing round one truck at a time and hoping each one can pick up, and half the calls go to voicemail and get made again twenty minutes later. What changes is that a driver can ask and be answered out loud, and the call writes itself down. The desk still makes the change; it stops being the only route a fact can travel.
  • The depot manager. Today the day is written up at the end of it, from memory, if it gets written up at all, and the hour lost at a gate is the one you never bill for. What changes is that both sides of the conversation go to the call log as they happen, so the hour at the gate is on the record at the gate.
  • IT and information security. Today a voice product means asking whose account the transcript ends up in. What changes is that the speech is turned into text by the model server you already run, and every conversational reply is spoken inside the FACE process from a voice embedded in the binary. The phone leg is carried by a telephony provider, as any call is.

How You Would Know It Worked

Every figure below is yours, not ours. Write down where you stand today, because the baseline is gone for good the moment anything changes.

  • Time the trucks spend stopped for no delivery. Your vehicles already send back where they are and when the engine is off. Take a week of it, drop the stops that match a drop, and look at what is left.
  • Minutes from a problem happening to the desk knowing. Sample a month of late runs and refused drops. When did it happen, and when did the first message about it reach the office.
  • Waiting time at gates and sites, and how much of it you bill. Out of your own job records and your invoices. In most fleets the hours are real and only some of them are written down.
  • How much of the day's log is written on the road. Count the notes and alerts raised during the shift against the ones raised after it ended. This is the one the rest of it rests on.

Bring one depot and a week of vehicle tracking data.

Questions A Fleet Manager Asks

What comes up before anybody talks about a contract.

What does the driver have to do?
Make an ordinary phone call and ask out loud. Where the next stop is, which gate, what the customer asked for. The answer comes back out loud, so there is no screen to read and no reason to pull over.
Who carries the audio, and who sees the text?
The leg between the cab and the building is carried by a telephony provider, the same as any other call your drivers make, and it carries that audio because it has to. The text is a different matter: the transcription and the reasoning that produces the answer happen on your machines, on the model server you already run, and the spoken reply is encoded there too.
What happens when a driver says something urgent?
Six words are watched, on the phone and on inbound WhatsApp or SMS alike: urgent, asap, emergency, broken, failing and late. A match changes how the agent answers and sends the caller’s own sentence to the manager number you configured. On the text side, a message that matched and reached nobody is written to the log saying so, rather than passing as handled.
What does the call leave behind?
The conversation itself, written down as it happens: each turn, who said it, and the call it belongs to. The hour at the gate is recorded at the gate rather than reconstructed at six o’clock. Somebody named on the desk reads it and makes the change, which is what keeps a spoken sentence and a changed delivery two separate events.
Whose voice does the driver hear first?
The telephony provider’s. The recording notice and the greeting that open the call are read from the call-setup instructions, before the socket into your building is open. Every conversational reply after that is spoken from a voice embedded in the FACE binary, in the same process as the rest of it.
What should we bring to a first conversation?
One depot and a week of vehicle tracking data. Two of your own figures go with it: the minutes between a problem happening and the desk knowing, sampled over a month of late runs, and how much of the waiting time at gates you currently bill.

Runink: Data You Can Trust. Decisions You Can Defend.

Runink FACE reads the logistics records you already hold, compares them against the rules that govern them, and drafts an action for the person who owns the decision. It runs on your own servers or cloud account, or on Runink's shared machines to start, with no outside AI service.