The Problem Space
Blinkit operates 526+ dark stores across India, delivering essentials in under 10 minutes. Profitability hinges on contribution margin per order — the difference between order value and fulfillment costs. The 6–10 PM peak window drives up to 50% of daily demand. And it's where everything breaks.
Narrowed Problem Statement
Evidence Base
Research drawn from 392 AmbitionBox reviews, 11 Reddit first-person accounts, an ex-SM open letter, ground journalism from The Print, CNN, BOOM, and Al Jazeera, and a primary interview with dark store manager Rudra. The pattern is consistent across all sources.
"Workload is high with minimum support tools. Have to play the role of a 1 man army on a daily basis."
— Retail Store Manager, 3★, AmbitionBox (Blinkit)
Primary Persona
Discovery research surfaced three candidate personas — the Picker, the Rider, and the Store Manager. The Store Manager was selected through a systematic elimination process grounded in one question: who has both the authority to act and the information gap a product can close?
29-year-old, direct Blinkit employee, ₹18,000–22,000/month. Manages 10–16 pickers across two shifts and tracks 15+ KPIs daily. He is the floor's only decision-maker.
When the 6–10 PM peak begins and order volume surges, I want to see exactly what is breaking on my floor in real time so I can intervene with precision and protect SLA.
Deepak can only see aggregate PPI rising. He cannot see which picker is stuck, why they are stuck, or where on the floor the failure is originating.
Walks the floor shouting "jaldi karo." Logs out the three slowest pickers to improve aggregate PPI, unknowingly removing capacity the store needed.
6:07 PM — aggregate PPI crosses 19 seconds (target: 13 seconds). The only thing his screen shows is that the number is wrong. The intervention clock has started.
Deepak opens StoreOps at 6 PM, identifies Ravi is stuck on a misplaced item, taps Reassign, watches Ravi's card turn green. Peak ends at 91% SLA.
Solution Exploration
Three solutions were considered. The differences are not stylistic — they are temporal. Each intervenes at a different moment in the failure chain.
Post-Peak Analytics Report
Daily summary emailed after 10 PM. Buildable in 2-4 weeks using existing Trino/dbt batch analytics.
Predictive Pre-Peak Staffing
ML-powered staffing recommendation sent 90 minutes before peak. Requires forecasting models not yet built.
Real-Time In-Peak Decision Support
StoreOps module surfacing live picker status, congestion alerts, and one-tap interventions during the 6–10 PM window. Routes existing Kafka and Newland scanner data.
Design Principles
Action-Oriented
Primary alerts must be actionable. Secondary KPIs shown only after all urgent alerts are cleared. No ambient charts during peak.
Stress-Proof Clarity
Zero training at peak. Comprehensible by a stressed SM in under 5 seconds. Traffic-light status (green/yellow/red) replaces numbers.
Zero Context Switching
Extend StoreOps, do not build a separate app. No re-authentication, no new APK sideload. SM stays in one tool.
One-Thumb Operation
390px mobile-first. Oversized touch targets (min 44px). Maximum 3 action buttons per alert card.
Feature Requirements
| Priority | Flow | User Story |
|---|---|---|
| MUST HAVE | Flow 1: Picker Stuck Diagnosis | As a Store Manager, I need to see which specific picker is stuck, where they are, and why — with real-time alerts and live timers — so I can intervene within 2 minutes instead of guessing based on aggregate PPI. |
| MUST HAVE | Flow 2: Inventory Location Failures | As a Store Manager, I need to be alerted when 2+ pickers fail to find the same item within 15 minutes — so I can confirm it's misplaced, update its location, and protect involved pickers' PPI scores. |
| MUST HAVE | Flow 3: Picker-Side Reporting | As a Store Manager, I need my pickers to be able to self-report issues so I receive accurate diagnostic data instead of guessing why they're stuck. |
| SHOULD HAVE | Flow 4: Rider-Picker Coordination | As a Store Manager, I need to see when 3+ orders are sitting packed while 2+ riders are idle in the wrong zones — with drag-and-drop reassignment to reduce dispatch delays from 3–5 min to under 2 min. |
| COULD HAVE | Flow 5: Performance Dashboard | As a Store Manager, I need a real-time "On Track" dashboard showing 5 key KPIs with color-coded health indicators and peak surge alerts. |
| WON'T HAVE | Flow 6: Floor Congestion Heatmap | Requires computer vision infrastructure not yet available at stores. Moved to Phase 2 moonshot. |
Non-Functional Requirements
| Category | Requirement |
|---|---|
| Performance | Alert generation <60s from trigger (P95). Dashboard refresh: 45–60s polling. Action response <500ms. Latency >2 min closes the intervention window. |
| Reliability | 99.5% uptime during shift hours (6 AM–11 PM). SMS backup for critical alerts. Dashboard auto-recovery on crash. |
| Platform | Mobile-first (390px), Android 9+, iOS 14+, web-based (no app install). Picker: existing HDMI handheld device. Requires 4G/WiFi. |
| Scalability | Support 500+ stores, 5,000+ active pickers simultaneously. Alert consolidation when 3+ pickers report same item. |
| Security | Picker device data encrypted in transit. SM actions logged with timestamp and SM ID. Role-based access: SM-only dashboard visibility. |
Critical Dependencies
| Dependency | Team | Status |
|---|---|---|
| Picker Report Event Stream | Data Engineering / Device | CRITICAL — Blocks MVP |
| WMS Real-Time Picker Status API | WMS / Backend | CRITICAL — Blocks MVP |
| Inventory Location Update API | WMS / Inventory | CRITICAL — Not started |
| Data Access Policy for SMs | Legal / Operations | Hard blocker — unresolved |
| Picker Device Report UI | HDMI Device / Frontend | Not started |
| Refund Processing API | Payments | Available |
Success Metrics & Measurement Plan
| Metric | How Measured | Baseline | 8-Week Target | Priority |
|---|---|---|---|---|
| Peak Throughput | Orders processed/hr during 6–10 PM | ~100/hr | 150/hr | P0 |
| Peak SLA Breach Rate | % orders >11 min during 6–10 PM | ~20% | ≤12% | P0 |
| SM Peak Mode Adoption | % target SMs opening Peak Mode ≥3 nights/week | 0% | ≥80% by Wk 4 | P0 |
| Alerts-to-Action Rate | % alerts where SM acts vs dismisses | 0% baseline | ≥60% action | P1 |
| CM1 per Order (Peak) | Contribution margin per order, 6–10 PM | ₹204 | ₹218 | P1 |
Guardrail Metrics
| Guardrail | Breach Threshold | Why It Matters |
|---|---|---|
| Picker Log-Out Events | >3 per peak | If log-outs don't decrease, the tool has not changed SM behavior. Requires immediate usability review. |
| Picker Complaint Rate | Any increase above baseline | Real-time individual picker visibility could be weaponized for punitive log-outs. Monitored via HR records. |
| False Alert Dismiss Rate | >40% dismissal | "Boy who cried wolf" failure mode. Erodes SM trust and renders the system useless. Requires threshold recalibration. |
Risks, Assumptions & Open Questions
| Risk | Impact | Prob. | Mitigation |
|---|---|---|---|
| SM uses picker-level visibility to unfairly target workers | HIGH | MED | Alert cards show behavior context only — never a ranking or score. Log-out actions require a reason tag. Audit trail for every SM action. |
| Event stream latency exceeds 30 sec under production load | HIGH | MED | Load test is a hard gate before beta. If P95 >15 sec, pivot to 30-sec batch refresh with explicit latency label visible to SM. |
| StoreOps sideload friction blocks installation | HIGH | LOW | Coordinate with StoreOps mobile team to ship as in-app update, not separate APK. |
| False alert rate too high — SM begins ignoring alerts | HIGH | LOW | Track dismiss rate in beta. If >40%, thresholds are too sensitive. Build dismiss-reason tagging to accelerate threshold calibration. |
| Legal approval delayed — individual picker visibility policy unclear | MED | MED | Build aggregate-only view (zone/aisle alerts, no individual picker names) as the default from Day 1, with individual visibility behind a feature flag. |
Key Assumptions
Tool adoption without formal training — validate by shadowing 3 SMs on first two beta nights. Fail threshold: adoption <50% in 5 days.
Kafka event stream latency ≤5 sec P95 — Data Engineering's load test is the gate before beta, not before design.
SMs will stop logging out pickers when given better diagnostic data — the guardrail metric monitors this directly.
Individual picker visibility does not create new labour-relations risks — Legal and HR review is a pre-launch requirement.
Timeline & Milestones
PRD Sign-Off
All stakeholders approved. OQ-1 (data policy) and OQ-2 (event schema) resolved.
Infra Validation
Data Eng confirms event schema, load test passed (P95 ≤15 sec). Go/no-go on real-time vs 30-sec batch.
Design Complete
Figma prototype complete. Usability test with 3 SMs: ≥80% identify stuck picker and take action within 30 sec without instruction.
Alpha Build
Happy path functional on staging. Picker grid, stuck alert, one-tap reassignment working end-to-end.
Beta Launch — 5 Stores
5 high-volume COCO stores live. SMs receive 5-min orientation. PM shadows 2 stores during first peak window.
Full Rollout
All ~210 high-volume COCO stores live. North star tracking started across the network.