Safety Incident Reporting
A new system for keeping Dashers safe by hearing out their issues and deploying support agents to address the most serious issues first.
My Role
Lead Product Designer
Collaborated With
Strategy and Ops (S&0), Frontend and Backend eng,
Product manager, T&S Ops team
Duration
5 weeks
Product Type
Zero-to-one
New Feature
Mobile- iOS
What is the problem?
Dashers are independent contractors who are essential to DoorDash's operations. They deliver orders placed on DoorDash to customers.
Dashers encountered difficulties reporting safety concerns during deliveries due to the absence of a dedicated communication channel to address such issues. This led to unresolved safety incidents, diminishing Dashers' trust in DoorDash's commitment to providing a secure working environment. Consequently, Dashers either churned or reduced their working hours on the platform.
How Might We
Enable Dashers to report safety issues and receive support for them in a way that is accessible, timely, and tailored to their immediate needs
How did we know this was a problem?
At DoorDash, we usually have a community of Dashers that serves as a soundboard. They constantly tell us what’s working for them and what’s not. The Dasher community was unhappy with how DoorDash handled safety issues, and we saw a growing trend of safety concerns on this forum.
" When it comes to Dashers' safety, I will not recommend DoorDash to friends - DoorDash doesn't care about its Dashers "
“...I think Doordash needs to pay more for some of the orders, had to deliver at a hotel known for drug, crime, prostitution, from Doordash I got paid 2.50, that’s not worth my life. No way to log that it wasn’t comfortable”
How did Dashers report safety issues previously?
Dashers had no way to inform DoorDash about safety incidents. DoorDash was the only gig platform that lacked an easy reporting method for workers to communicate negative experiences. They had to contact general support to speak with an agent.
Max was threatened by the restaurant staff at pick-up, they want to report this issue so Doordash can help them
For a deeper understanding of the problem, I went beyond the Dasher interface, to track how safety complaints were managed.
For Dashers who persevered through bad experiences and made an effort to contact general support, their struggle didn’t end there. Since general support agents (Tier 1) aren't trained to handle safety issues, they must escalate them to Tier 2 agents. Dashers are left waiting in the process.
The experience was broken in multiple places. There was one very obvious issue, which was a total lack of a reporting system, but there were also other issues with how our support was set up.
01
No way to report issues
Not having a way to tell DoorDash about safety incidents that may have happened besides general chat
03
Lack of helpful data, leading to slower resolutions
Agents didn’t have any information about the incident upfront. They spent a lot of time gathering it and prioritizing the issue. All this took time and slowed down the agents.
02
Too many escalation layers, causing delays
Connecting with the wrong agent who cannot help Dashers in these situations. Tier 1 agents just asses if something needs to escalated to Tier 2 agents
The Solution
To tackle the issues and provide a holistic user experience that goes beyond just interface design, I developed a two-part solution to ensure the entire process was efficient and effective.
The first part optimized how Dasher's reports are handled, making the process more efficient and speeding up resolutions for a better agent experience.
Part I: Updating the agent process for efficiency
Part II: Interface for Dashers to report safety issues
The second part focused on creating an interface for Dashers, which allows them to report issues easily and in great detail. It also lets them track the progress of their cases, ensuring better communication and transparency throughout.
Part I : Optimizing the agent process for efficiency
After I found the problems with this flow, our main goal was to streamline the escalations flow for issues coming in. We wanted Dashers to get fast responses from the safety team. We aimed to connect them with helpful people and make sure safety agents got accurate information right away.
Part II: Interface for Dashers to report safety issues
Once I defined the desired high-level experience for escalation processes, I began designing the details of the safety incident reporting flow. To address the issues in the old flow and to ensure the success of the new one, I divided the reporting issues UX into three key sections. Each key section corresponds to an issue in the old process.
Resolution expectations
Capturing relevant details
Appropriate entry
Safety Incident Reporting
Challenge I
How can Dashers use the appropriate channels for different types of safety issues to reduce noise?
Challenge II
How can we collect data about the incident that’ll help agents understand and prioritize the issues based on urgency?
Challenge III
How can we give Dashers a clear understanding of what the next steps are and when to hear back from an agent?
Challenge I: Appropriate entry
How can dashers use the appropriate channels for different types of safety issues to reduce noise?
When I examined the data, I discovered that Dashers frequently used safety channels and support chat to discuss topics unrelated to safety. This created much noise and overwhelmed our safety agents with irrelevant issues.
Additionally, several safety tools were scattered around the Dasher app. Helpless Dashers would use the most accessible tool rather than the appropriate one for a given situation.
Early Proposal: Starting with locations and time followed by incident details
Challenge II: Capturing relevant details
How can we collect data about the incident that will help agents understand and prioritize the issue based on urgency?
When it came to understanding what we needed to know about safety incidents, I consulted our safety agents who were previously reaching out to Dashers to learn more about what had happened.
After speaking with them, I learned what information they require to initiate an investigation or make a decision for safety incidents. This included
-
When did the incident take place?
-
Who or what made the Dasher feel unsafe?
-
What were the details of the incident?
Early Proposal : Starting with ‘Who and When’
Pros + Cons
In this initial version, I began the flow with the location and time, closely following the model used to communicate delivery information to Dashers. The idea was to leverage the Dashers’ existing mental model. We inferred the location and time from the latest delivery, assuming Dashers would report safety issues promptly. Following this, we requested incident details
Final Date Collection: Focusing on the issue first
In our final version, I started the flow with details about the issue. This approach achieved two things: first, it demonstrated empathy by focusing on the Dasher’s problem immediately, rather than on logistical details. Second, it helped us triage and prioritize these issues right away.
Challenge III: Resolution expectations
How can we give Dashers a clear understanding of what the next steps are and when to hear back from an agent?
At this stage, I identified several scenarios for how resolutions could proceed for Dashers based on factors such as the priority of their issue. If they reported an issue during an active order, we aimed to at least give them the option to unassign and leave the unsafe situation. Additionally, if a customer was involved, we ensured that the Dasher would not be paired with that customer again to prevent future safety issues. I created variations to address all these use cases.
The new reporting experience resulted in a 66% reduction in initial response time for safety reports.
We initially launched this experience as an AB test to 10% of Dashers. When the experiment concluded, our initial response time for a Safety Agent (tier 3) to reach out had decreased from 30+ minutes to less than 10 minutes. And, the overall resolution time dropped from several days to less than 24 hours.
This project started as a solution for Dashers but ultimately improved the experience for both Dashers and agents. It made reporting safety issues easier for Dashers, ensured they felt seen, and provided agents with the necessary information to do their jobs efficiently. This led to a successful and enhanced experience for everyone involved.
Key Takeaway
Navigating the Nuances of Safety
Safety is subjective, and one key takeaway from this project was recognizing the different thresholds for what makes Dashers feel unsafe. For instance, a Dasher with social anxiety might be rattled by a loud restaurant employee, while another Dasher in the same situation might not be affected.
Both responses are very valid. Defining and prioritizing safety issues was a challenge, as not everyone agreed with the priorities we set. Rather than getting stuck in long, difficult discussions, we chose to launch and learn from what we put out. We understood that this list and its priorities would evolve based on real-life feedback from Dashers.