Messaging & named-human exception ownership
Stage 4 · Driver App, Communication & Service Standards
P1Initial MVP
Four-Lane View
Software Function
- ›Load-threaded chat: driver ↔ dispatch ↔ client ops, context attached automatically Every load shows its named owner — photo, name, direct line Exception workflow: detect → assign → resolve → narrate to client, SLA-clocked EN/ES translation inline
Service Provider / Admin
- ›Exception owners have authority: rebook, pay detention, authorize hotel — resolution powers in the tool Escalation ladder with time triggers; no email black holes
User — Driver / IOO
- ›One tap to a human who can actually fix it — the anti-Uber support promise, in the UI Issue history stays attached to the load, never re-explained
Customer — Client / FF / NVOCC
- ›When something breaks they hear it from us first, with the fix — "3 exceptions, 2 already fixed" as CLIENT/FF/NVOCC the default experience
Software Function
- ›Load-threaded chat: driver ↔ dispatch ↔ client ops, context attached automatically Every load shows its named owner — photo, name, direct line Exception workflow: detect → assign → resolve → narrate to client, SLA-clocked EN/ES translation inline
Competitors
Uber Freight (outsourced desks, email-only escalation — their single most repeated complaint), every TMS (notes fields, not workflows)
Differentiation
Support-with-authority is our #4 pitch vs Uber. This function makes it verifiable: named owner, resolution powers, SLA clock — visible to driver AND client.
Make It Better
Median exception resolution under 30 minutes with the client notified before they noticed. Support becomes a retention weapon with a dashboard.