Transfix
Shipment Tracking
Transfix is a digital freight marketplace coordinating thousands of active shipments. The Carrier Experience team was responsible for tracking shipments through their lifecycle and proactively communicating with carriers and shippers when delays risked becoming customer-facing misses.
Background
The Carrier Experience team was unable to keep up. Shippers were frustrated because updates were inconsistent. Carriers were frustrated because they got contacted multiple times with the same question. The breakdown happened during the Track Shipment phase of the lifecycle, the window where proactive communication prevents small delays from compounding into customer-facing misses.
Discovery
Ran user shadowing and interview sessions to understand how reps were currently completing tracking work. A few things stood out: contact needed to be made within specific time frames tied to pickup and delivery events, managers were assigning either individual shipments or carrier-level responsibilities each morning, and reps were manually setting reminders based on when they thought they should reach out. The system was relying on rep memory rather than event-triggered prompts.
Workflow Modeling
Mapped an ideal communication timeline against shipment states (dispatch, pickup, in-transit, multi-day, pre-delivery, delivery, post-transit) so the system could generate the right tracking task at the right moment instead of relying on each rep's recall. Then modeled how shift coverage overlapped with those events, so task generation could account for which reps were actually on shift when each touchpoint came due.
Design
The output was the Carrier Experience Task List, a prioritized queue showing which shipments the rep was assigned to, which had pickup, delivery, or multi-day events coming up, which were flagged high priority, and which already had automatic tracking in place. Tasks were time-bound and urgency-coded so reps could work from the top of the list instead of scanning every shipment.
Iteration
V1 learnings surfaced two needs reps had: visibility into recent activity on a task (so they could tell whether someone had already attempted contact) and the ability to focus on a specific type of task (pickups, deliveries, multi-day, claims, upcoming). V2 folded both in.
Outcome
Tracking work moved from a memory-driven, rep-by-rep process to a shared, event-triggered queue with clear ownership.
The V2 activity record directly addressed one of the original frustrations that had prompted the project, giving reps visibility into whether a carrier had already been contacted so the same question wasn't asked twice.
