Driver Support &
On-road messaging

Project Overview

The Amazon Flex app is the mobile app used by delivery drivers worldwide to deliver Amazon.com packages. Our goal was to expand the existing in-app chat functionality to enable on-road communication between delivery drivers and our support organizations. The first use case was to facilitate driver rescues planned and executed by Central Operations (CO) associates.

A “rescue” is necessary when one driver falls significantly behind schedule and runs the risk of not completing their route. A second driver—that is finished or close to finishing their route—is sent to pick up packages from the first driver. This “leveling” of packages allows the business to keep our customer promise and increases our delivery success rates.

My role was to lead the overall service design—working backwards from the driver’s experience. I partnered with the Station Product and UX teams (responsible for the CO associate’s experience) to align on the end-to-end ideal workflow and influence Central Ops standard operating procedures (SOP).

Existing Process and Tools

Mission Control is a work-item assignment and load balancing tool used by Central Operations (CO) to proactively support drivers while on-road. It automatically detects anomalies (like a driver behind schedule) and assigns work-items (such as planning and executing a rescue) to an individual CO associate. The CO associate uses a separate tool, Chime, to communicate the rescue details (meeting location, packages to transfer, etc) to both drivers.

Mission Control rescue planning and Chime message to drivers

User Pain points

Manual process involving multiple tools. The lack of a single tool to execute the end-to-end workflow added unnecessary overhead and created a fragmented experience for the CO associate. Likewise, drivers were also required to setup, monitor and use Chime in addition to the Amazon Flex app—leading to a sub-optimal experience.

Difficult to reach drivers. The group messaging format made it difficult for drivers to detect messages targeted to them. As a result, only 0.07% of drivers acknowledged rescue requests.

Impersonal driver experience. If the driver did see the message, it was easier to ignore than to parse the details of the message.


The opportunity

The Amazon Flex app had basic messaging capabilities that allowed drivers to contact customers if they needed help during the delivery workflow. Our goal was to utilize the existing in-app messaging platform and allow CO associates to reach drivers directly in their primary tool. This would simplify the rescue process for both the drivers and CO associates and unlock and new channel for additional Driver Support use cases.

Amazon Flex app messaging feature (summary and thread view)

 

Experience blueprint

I began by using research to dive deep—considering each user’s unique experience during the rescue process. I learned from ride-alongs (shadowing a driver during their day) that driver’s—like most co-workers—know each other and engage in friendly banter throughout the day. In order to increase the rescue acceptance rate, I wanted to lean into this comradery between drivers and bring a humanizing element to the rescue request.

I iterated and tested several options for the order of operations and the specific message content. I needed to understand what information Driver A (driver ahead of schedule) wanted to know in order to accept or decline a rescue request. Additionally, once Driver A accepted—what was the best way to contact Driver B (driver behind schedule) and communicate the plan?

Content and order of operations concepts

Connecting the drivers in a single thread.

 

The solution

Once I had the desired experience mapped out and the messaging language defined, I focused on modifying the existing page designs. The thread summary page was updated to support an additional sender type (Driver Support). Threads were sorted chronologically so drivers could easily see the most recent message. I used titles to identify the topic of the thread and incorporated “sender” icons so that drivers could quickly determine the content of the message

end-to-end Rescue experience

Results

  • Enabled Central Operations (CO) to initiate communication with drivers within the Rabbit App

  • Enhanced in-app messaging feature to support multiple senders and thread types (unlocking future use cases)

  • Achieved a 35% reduction in the unreachable rate in the NA and 47% in the EU.

  • Rescue executions have increased by 5.4% in NA and 7% in EU (In NA, 625,997 packages rescued annually)

  • Mitigated 30.8M annually in OODT and concession spend for NA AMZL network

  • 34% reduction in overall resolution time per rescue exception in EU

  • Post launch surveys with drivers and Central Ops associates did not provide any negative feedback.