Omnitracs integration: hours of service and macros

A driver's hours of service and the macro messages they send from the cab both go through Omnitracs before Roadmark reads either one. Hours of service feed dispatch planning the same way any connected ELD's does: a plan never puts a driver on a load their remaining hours won't cover. The macro messages are the more distinctive half of the connection.

What a macro message is

On the driver's in-cab terminal, Omnitracs calls macros "canned messages," and its own glossary defines a macro as a message "formatted ahead of time so the driver or QTRACS user need only fill in the blanks." A dispatcher composing one picks the macro from a drop-down list instead of typing freeform text, and only the fields that change, a stop number or a status, are filled in and sent. It's a faster, more structured message than a text, built for exactly the short, repeated updates a load generates.

Where it shows up in Roadmark

Hours of service sit on the same unit card as trailer and home time that every connected ELD feeds, so dispatch planning checks one place regardless of which ELD a fleet runs. A macro message a driver sends from an Omnitracs-connected cab lands on that load's own message thread, the same place a message sent from Roadmark's driver app would appear. For a fleet whose drivers stay on Omnitracs' terminal rather than switching to Roadmark's own app, that means dispatch still reads every update on the load, without opening a second screen to see what a driver sent from the truck.

Location and hours of service from a connected ELD are also one of five sources tracking checks for a load's status, alongside the driver app, a carrier's own app or an EDI 214, visibility networks, and a check call when nothing else is reporting.

A Tuesday example

On the carriers board, unit 231 (A. Brandt) is on the board for Tuesday's run. With Omnitracs connected, A. Brandt's hours of service sit on unit 231's card the same way any connected ELD's would, so dispatch planning checks one place before assigning the unit's next load. If A. Brandt sends a macro from the terminal, a delay code at a stop, say, instead of typing it out, it lands on that load's own message thread straight away. Dispatch reads it there, next to any message a driver on Roadmark's own driver app would have sent for a different load, rather than switching to a separate terminal view to see what came in from the cab.

Running Omnitracs alongside the driver app

A carrier doesn't have to move every driver onto Roadmark's driver app at once to get this. A unit whose driver stays on Omnitracs' terminal still shows up with current hours of service and a message thread that fills in from macro messages; a unit switched to Roadmark's driver app gets its messages the same way, just typed on a phone instead of picked from a terminal list. Dispatch works one board either way.

For a fleet already running Omnitracs, the change is mostly what catches up downstream: a plan that respects the hours actually left on a driver's clock, and a macro message that reaches the load's own thread instead of staying on a terminal dispatch has to check separately.