Discovery & Self-Service
01 — Problem
Driver support is built as a series of disconnected transactions. Each contact starts from zero — no history, no context, no memory of what came before — so the same problems repeat and trust erodes.
Every interaction is treated as new. No case record persists and no driver profile carries forward between contacts.
A driver contacts support about the same gated-community access issue for the 8th time — each contact starts with "Can you describe the problem?"
Data the system already holds — GPS, route, delivery history — never crosses to the people and tools handling the issue.
The driver re-explains context already visible in the system on every contact.
Support is measured contact by contact, so repetition is invisible and continuity is never built.
Resolved or not, nothing learned in one contact informs the next.
02 — Scale
Small gaps repeat across millions of contacts — the cost shows up as time, retries, and eroded standing.
03 — Journey
Unable to access delivery location. Checks app for instructions, finds none relevant to the specific situation.
Opens DSLP, searches FAQ, reads generic articles that don't match the live situation on the ground.
Connects to chatbot or CSA. Re-explains context already visible in the system (GPS, route, delivery history).
Back-and-forth with scripted responses. Escalation requires re-explaining from scratch. 1.3x average retries.
48-hour data delay, no status updates, no proactive communication. Driver is the only one tracking the issue.
Turns to WhatsApp groups, station conversations, other drivers. Shares workarounds the system never provided.
Resolved: relief but trust damaged. Unresolved: standing impacted, distrust cemented. Either way, no continuity built.
No proactive alert for known problem addresses on route. System has the data, driver discovers blind.
DSLP content is static, generic, disconnected from the live delivery context the driver is in.
No record of prior encounters at this address carries forward to inform the driver.
Chatbot loops through scripted steps already taken. CSA has no visibility into driver's history or issue patterns.
Issue reporting asks for information the system already has (GPS, delivery history, route data).
Driver must re-explain the full context from scratch on every escalation. No case record persists.
Resolution provided without explanation or follow-up. No status update, no confirmation, no callback.
48-hour data delay: operations sees defects 2 days after drivers absorb the impact. No proactive communication.
If resolution requires a second contact, all context is lost. Starts from zero again.
Peer knowledge is invisible to Amazon. Cannot be quality-controlled, updated, or leveraged by the support system.
Performance impact from issues outside driver control. No connection between support contacts and standing adjustments.
Trust migrated permanently to peer network. Official channels lost credit through repeated failure to remember.
GPS tracking, address database, delivery history, route planning.
Known problem addresses not flagged. Prior delivery failures at same location invisible to driver.
DSLP content library, issue categorization, FAQ database.
Static content. No awareness of driver's current delivery context or history with this issue type.
Chatbot routing, CSA tools, contact queue management.
No persistent case record. No driver profile visible to CSA. Each contact treated as the first.
Resolution workflows, credit processing, escalation paths.
No notification system for the driver. No callback. Resolution happens silently or requires driver to re-initiate.
Defect reporting, operations dashboards, delivery failure data.
48-hour data delay before patterns surface. No proactive communication to affected drivers during the gap.
None. Peer networks are invisible to Amazon infrastructure.
Driver knowledge (route notes, access codes, customer quirks) exists only in personal notebooks and group chats.
Scorecard calculation, deactivation thresholds, performance metrics.
No feedback loop between support interactions and performance system. Issues resolved via support do not inform standing.
Flex App notifications, route view
Flex AppPush notificationDSLP web portal, in-app help
DSLPFAQIn-app searchIn-app chat, chatbot, phone support
ChatbotChatPhoneLive chat with CSA, ticket system
ChatEscalation queueNo surface. Driver left watching.
No proactive commsWhatsApp groups, station desk, peer network
WhatsAppStationPeer DMScorecard app, standing notifications
ScorecardFlex AppDrivers check peer groups before official channels because peers remember specific addresses.
DSLP content is static and generic. No awareness of the driver's live delivery context or prior issue history.
7.3 min average handle time on a use case where the system already has the answer in GPS data.
12% of all SDS contacts are "Unable to Access." Each costs ~$4.50 in re-delivery attempts when unresolved.
48-hour data policy gap creates an anxiety spiral. Driver is the only actor tracking the open issue.
Peer network functions as a shadow support system. Invisible to Amazon, cannot be improved or quality-controlled.
No feedback loop between resolved issues and standing. Drivers absorb standing hits from issues outside their control.
04 — Evidence
Every contact re-establishes context from scratch. The data to do better exists — it simply never crosses the line of visibility into the tools and people supporting the driver.
When official support keeps forgetting, drivers turn to WhatsApp groups and station conversations — a shadow support system Amazon can neither see nor improve.
Each pattern is independently reasonable. Together they make sure the same problems keep recurring — and that trust keeps leaking out of the system.
Every support interaction is treated as new. No case record persists, no driver profile carries forward, no concept of "this driver has contacted us before about this." The system resets at every boundary.
Data the system already holds — GPS, route, delivery history — never reaches the tools and people handling the contact, so the driver re-supplies it every time.
Fixes happen without explanation, confirmation, or callback, so the driver can never tell whether an issue is actually resolved.
A 48-hour data delay leaves the driver as the only actor tracking an open issue, with no proactive communication during the gap.
Issues outside the driver’s control affect performance standing, with no feedback loop between support outcomes and the scorecard.
05 — Takeaway
The whole loop is a memory problem, not a headcount problem. Give the system continuity — a persistent case record, context that carries forward, and proactive communication during the blind spots — and the retries, re-explanation, and trust erosion collapse together.
Persist a case record and profile so no contact starts from zero and prior encounters inform the next.
Proactively communicate during the 48-hour data delay instead of leaving the driver as the only one tracking the issue.
Link support outcomes to the performance system so issues outside a driver's control stop silently damaging their standing.