Slack Wasn't Built for Trucking. The Centrix Comm Hub Was.
The communication tax on every load
A typical move involves five to nine internal touches: dispatcher to driver, dispatcher to fleet manager, fleet manager to shop, dispatcher to broker, accounting to dispatch on rate, safety to dispatcher on HOS, dispatcher to customer service on detention. Each touch is a message. Each message has context the next touch needs. None of the legacy tools — Slack, email, text, phone — actually carry that context forward.
The communication tax is real and large: 18-25% of dispatcher time on managed fleets goes to communication overhead, not dispatching. A material chunk of that overhead is re-establishing context — looking up the load number, finding the BOL, confirming the truck's last position, checking when the driver's last HOS reset was.
The Centrix comm hub is built around the observation that every operational message is about something — a load, a truck, a driver, a customer. Linking the message to the underlying object eliminates context re- establishment as work the human has to do.
The structure
The comm hub has three layers:
Channels per department
Standard channel structure: #dispatch, #fleet, #safety, #accounting, #hr, #sales, plus carrier-specific channels (#after-hours, #weather, #oversize, #claims). Channel membership is RBAC-aware — your role determines which channels you see.
Direct messages
1:1 and small-group DMs between team members, with auto-translation (EN/ES/RU) so a Spanish-speaking driver and an English-speaking dispatcher both see the conversation in their language. The translation is per-message, not per-thread, so mixed-language conversations work naturally.
Object threads
The differentiator. Every load, truck, driver, and customer record has a thread attached. Messages in that thread are linked to the object — and the object is linked back to the messages. When the dispatcher opens the load, they see the conversation history about it. When they open the driver, they see all the messages relating to that driver across the last 18 months.
This eliminates the "wait, where did we discuss this?" overhead. The answer is always "on the object."
What's automatically linked
Centrix detects object references in messages without asking the user to tag them:
- A load number (`L-128493`) → linked to that load
- A truck number (`Truck 247`) → linked to that truck
- A driver name (full or partial) → linked to that driver
- A customer name → linked to that customer
- A VIN, a license plate, an MC number — all detected and linked
The links are bi-directional: from message to object and from object to message. A user who's looking at a load thread sees every message that mentioned the load, even if the message wasn't posted in that thread.
Search across 18 months in 200 ms
The comm hub is backed by a full-text index plus a vector embedding index (via sqlite-vec) so search supports both exact and semantic queries:
- "L-128493 detention" — exact, returns every message mentioning the load
and detention
- "truck breakdown last week" — semantic, returns messages discussing
recent breakdowns even if they didn't use those exact words
- "driver complaining about home time" — semantic, returns messages
matching the intent
Search returns in 200ms even on 18 months of message history. This single capability changes how teams work — "let me find what we said about that" becomes a 5-second action instead of a 5-minute scroll.
comm_intelligence — thread summarization
Long threads (50+ messages) get a summarization layer. The `comm_intelligence` service generates a thread summary that captures:
- The decision(s) made
- The participants
- The outstanding action items
- The key context (load, truck, customer)
A new team member coming into the conversation reads the summary and is caught up in 60 seconds. The summary regenerates as the thread continues so it stays current.
This is especially valuable for after-hours handoff — the morning dispatcher reads the summary of overnight activity and knows what the night dispatcher (or the AI agents) handled.
Telegram bridge
Drivers don't use Slack. They use Telegram. The comm hub bridges to the driver Telegram bot in their language, so a message from dispatch in the hub appears as a Telegram message to the driver, and a driver's Telegram reply appears in the hub thread. The dispatcher and the driver are talking across two different surfaces, but the conversation is unified for both.
Same bridge applies to SMS for drivers without Telegram, and to voice transcription for phone calls (see also: live call analytics article).
What this changes operationally
On managed Centrix fleets, after 90 days on the comm hub:
- 22-30% reduction in dispatcher time spent on communication overhead
- 35-50% reduction in "wait, what was decided?" follow-up
- 60-70% reduction in time spent searching for past conversations
- 25-40% reduction in cross-shift handoff disputes (because the thread
summary makes overnight context explicit)
For a 100-truck fleet, the dispatcher productivity uplift alone is roughly equivalent to 2-3 dispatcher seats of capacity — at $60K loaded per seat, $120K-$180K of value per year. Plus the qualitative wins of better-coordinated operations.
Compliance and audit trail
The comm hub runs the same DLP scanning, RBAC enforcement, and hash-chain audit log as the rest of Centrix. A claims attorney requesting historical communications about a specific load gets an exportable, tamper-evident package. A safety auditor requesting communications about a specific incident gets the same. This is a meaningful upgrade over Slack export + email export + screenshot collection.
Where to start
If you're 30+ trucks running ad-hoc on Slack / email / SMS / phone:
- Migrate dispatcher-driver communication first. This is the highest-
volume, most-pattern-friendly category. Most carriers see immediate productivity uplift on the dispatch desk.
- Add the cross-department channels next. The hub becomes a place for
fleet, safety, and accounting to coordinate on the same load without re-explaining context.
- Turn on object linking and search after 30 days of message history.
The search becomes useful once there's enough history to search.
Book a comm review — we'll do a side-by-side of your current comm flow vs the hub on a real day's traffic.