Drayage-native driver workflows
Stage 4 · Driver App, Communication & Service Standards
P1Initial MVP
Four-Lane View
Software Function
- ›Port mode: terminal maps, appointment windows, per-diem clock, chassis plan, TWIC/UIIA wallet Chassis-split alerts with paid recovery work orders Terminal turn-time leaderboard (crowdsourced, like Waze for the harbor)
Service Provider / Admin
- ›Port ops sees terminal congestion live from driver telemetry Credential expirations from Stage 1 wallet surface here before they strand a driver
User — Driver / IOO
- ›The only app built for the port day: knows PierPass windows, empty-return rules, dual-transaction plans Dwell automatically becomes detention evidence
Customer — Client / FF / NVOCC
- ›Port friction narrated in plain language — "chassis split resolved, $0 demurrage" instead of silence
Software Function
- ›Port mode: terminal maps, appointment windows, per-diem clock, chassis plan, TWIC/UIIA wallet Chassis-split alerts with paid recovery work orders Terminal turn-time leaderboard (crowdsourced, like Waze for the harbor)
Competitors
None. Motive/Samsara/Trucker Tools are OTR-centric; PortPro’s driver app serves its carrier customers, not a marketplace fleet.
Differentiation
Our beachhead is drayage and every driver app ignores drayage. The port-day workflow is uncontested app territory — and it feeds the loop dispatcher.
Make It Better
Drayage drivers open OUR app at the terminal gate even for non-FreightShift work (turn-times, rules) — daily-active utility that recruits for us.