Supporting materials: ↓ Slide Deck (PPTX) ⬡ Dashboard Wireframe ↓ Written Assignment
PM Product Case Study · Blowhorn · 2022–23

Real-Time Order Tracking via Webhook Infrastructure

How a fragmented, polling-based system became a real-time event infrastructure — cutting delivery failures, eliminating WISMO overload, and reducing partner onboarding from 7 days to 1.5.

Role
Product Manager II
Company
Blowhorn
Scale
10,000+ orders/day
Cities
70+
01 — Who Is the Customer / Partner?

A tiered partner ecosystem — three distinct profiles, one platform

Not every merchant has the same technical bandwidth or operational scale. From day one, the product was designed to meet each partner exactly where they were — ensuring 100% coverage, not just coverage for the 10% with dedicated engineering teams.

Tier 1 — SMB
Small & Mid-Size Merchants
D2C brands · Marketplace sellers · Regional retailers
No dedicated tech team. Needed real-time order tracking out-of-the-box, without any engineering overhead or integration effort.
Built-in OMS tracking dashboard — zero integration required
Templated SMS via built-in messaging service — toggle on
No API keys, no engineering involvement needed
~60%
of partners · <200 orders/day
Tier 2 — Growth
Mid-to-Large Merchants
Mid-market e-commerce · In-house tech teams
Wanted to own their end-customer communication stack with their own branding and tooling — not rely on Blowhorn's built-in comms.
Webhook consumers, managing their own comms stack
Configurable endpoints per event type
Self-serve dashboard for integration and monitoring
~30%
of partners · 200–800 orders/day
Tier 3 — Enterprise
Decathlon · Croma · Apollo
Dedicated integration teams · Existing CRM stacks
Required structured, real-time event feeds to trigger downstream CRM and marketing automation workflows at scale.
Full webhook + CRM / marketing automation integration
Rider details + OTP injection per out_for_delivery event
Versioned schema with 12-month backward compatibility
~50%
of GMV · ~10% of partners · 1,000–3,000+ orders/day
02 — Challenge & Business Problem — Quantified

Three compounding pain points, all happening simultaneously

Before webhooks, Blowhorn's OMS relied on a fragmented, semi-manual architecture that introduced 30–90 minutes of lag on every order status change. The pain was not isolated — three separate business problems shared the same root cause, and all three were measurable.

WISMO Overload — "Where Is My Order?"
Merchants polled APIs at intervals — support teams drowned in inbound "Where Is My Order?" calls because status data was always stale. No self-service resolution existed. Partners had zero visibility into live order state without manual lookups.
22%
Delivery Failures Caused by Delayed OTP
Rider name, masked phone number, and OTP reached end-customers only when the rider called — often minutes before arrival, or not at all. Customers weren't ready. Riders couldn't complete delivery. First-attempt success rate suffered directly as a result.
17%
Missed Revenue — Marketing & CX Triggers Firing Too Late
Post-delivery review campaigns fired 6–12 hours after delivery, not minutes. Failed-delivery recovery flows ran the next business day — too late to prevent chargebacks, cancellations, or customer churn. The delay was systematic, not occasional.
₹97K/day
1,500
re-deliveries happening every single day
At 10,000 daily orders with a 15–17% first-attempt failure rate, and ₹45–65 per failed re-delivery attempt — that's ₹67,500–97,500 in direct margin erosion per day. Before accounting for customer churn, negative reviews, and partner relationship damage. This was a problem that compounded daily and was fully measurable in rupees.
03 — Value Proposition of the Solution

Two layers. One architecture. 100% partner coverage from day one.

The core design question was: how do you give every partner real-time tracking — not just the 10% with engineering teams? The answer was a deliberately tiered two-layer product where both layers share the same underlying event infrastructure, exposed differently based on partner capability.

Layer 1 — For SMB Partners (~60% of partners)
Built-in OMS Tracking — Zero Integration
Toggle-on tracking dashboard with automated templated SMS via Blowhorn's built-in messaging service. No API keys, no engineering work, no onboarding overhead. Every SMB partner gets real-time order status updates on day one — completely friction-free. The value proposition here was inclusion: no partner left behind because of their tech capability.
→ 100% SMB partner coverage from launch day · Zero integration cost
Layer 2 — For Growth + Enterprise Partners (~40% of partners, ~50% of GMV)
Webhook Notification Infrastructure — Full Programmatic Control
Event-driven push to registered partner endpoints the moment an order status transitions. Configurable per event type. Exponential backoff retry guarantees. Partners build their own downstream workflows — CRM triggers, delivery comms, failed-order recovery, post-purchase marketing. The value was programmability: enterprise partners get real-time data exactly when they need it, without polling.
→ Programmatic control for partners with engineering capability
Both layers share the same underlying event infrastructure — exposed differently based on partner technical capability. One build. Full coverage across all three tiers.

Five Events Shipped — Every Critical Delivery Moment Covered

✅
order_confirmed
Order accepted by Blowhorn. SLA window set. Partner notified immediately.
→
🛵
out_for_delivery
Rider name + masked phone + OTP injected. Customer ready before rider arrives.
→
📦
delivered
Confirmed timestamp + method. Triggers review campaigns within minutes.
→
❌
delivery_failed
Failure reason code + reschedule window. Recovery flow starts immediately.
→
↩️
return_initiated
Return condition + pickup ETA. Full return lifecycle covered end-to-end.

Key Design Decision: One Payload Schema Across All Events

out_for_delivery · v2 ● consistent shape
"schema_version": "v2", "event": "out_for_delivery", "order_id": "ORD-4820193", "rider": { "name": "Rajesh Kumar", "phone_masked": "+91 98xxx xx214" }, "delivery": { "otp": "8821", "delivered_at": null // not yet — always present }, "failure": { "reason_code": null, // not applicable here "rescheduled_for": null }, "returns": { "initiated": null, // not applicable here "reason_code": null }
Integrate once. Never re-integrate.
The schema shape is identical across all event types. Fields irrelevant to a specific event return null — they are never omitted. Partners integrate once and automatically receive every new event type without any re-integration effort. This directly enabled our 1.5-day median partner onboarding, down from 7 business days.
Field coverage across events
Field groupOFDDELFAILRET
Core order✓✓✓✓
Rider details✓✓✓null
OTP✓nullnullnull
Failure reasonnullnull✓null
Return detailsnullnullnull✓
Delivery confirmnull✓nullnull
12-month backward compatibility guaranteed
Schema versioned v1 → v2. Enterprise clients like Decathlon and Apollo build integrations with confidence — no breaking changes without 12 months advance notice. New fields are always additive.
04 — Top 3 User Stories

The three jobs to be done — as a / I want / so that

Each story represents a distinct user need across the partner ecosystem. Written in the standard format — user intent, not feature description — with acceptance criteria and measured outcomes.

Story 01 / 03
Merchant Partner · 500–2,000 daily shipments · Growth / Enterprise Tier
Automated End-Customer Delivery Communication
"As a merchant partner, I want to receive a real-time push notification the moment an order moves to 'Out for Delivery' — with rider details and OTP — so that I can immediately relay this to my end-customer via SMS, without any manual intervention from my operations team."
Acceptance Criteria
out_for_delivery webhook fires within 60 seconds of dispatch system update — not on a polling schedule
Payload includes rider_name, rider_phone_masked, delivery_otp, eta_window, and order_id in every call
3-attempt exponential backoff retry (30s → 2min → 8min) if partner endpoint returns a non-200 response
Merchant configures which endpoint receives each event type independently via self-serve dashboard
📈 First-attempt delivery: 83% → 91% (+9.6%) · ~120 fewer re-deliveries/day at pilot scale
Story 02 / 03
Technical Integration Lead · Merchant / Enterprise · Growth / Enterprise Tier
Self-Serve Webhook Integration & Observability
"As a technical integration lead at a merchant partner, I want to register, test, and monitor my webhook endpoints from a self-serve dashboard — so that I can go live with real-time order tracking in under 2 hours, without raising a support ticket to Blowhorn's integration team."
Acceptance Criteria
Register up to 5 endpoint URLs per account, each mapped to specific event types independently
'Send Test Event' fires a synthetic payload to the registered endpoint and shows HTTP response code in real time
Event Log shows last 500 events, filterable by event type, delivery status, and timestamp
Failed events can be manually retried directly from the dashboard with full retry history visible
📈 Integration time: 7 days → 1.5 days (−79%) · Setup support tickets: −68% in 6 weeks
Story 03 / 03
CX / Marketing Manager · Enterprise Client · Decathlon / Croma / Apollo
CRM & Marketing Automation on Delivery Events
"As a CX manager at an enterprise merchant, I want to receive structured webhook events the moment an order is 'Delivered' or 'Delivery Failed' — so that I can trigger post-purchase CRM workflows within minutes of the delivery outcome, not 6–12 hours later."
Acceptance Criteria
delivered and delivery_failed events fire within 90 seconds of rider app update — no batching, no delays
Payload includes order_id, delivery_timestamp, failure_reason_code, and customer_id for downstream CRM routing
Separate endpoint URLs configurable per event type for independent CRM workflow routing without overlap
Versioned schema (v1, v2) with 12-month backward compatibility — no re-integration required when new events are added
📈 Post-delivery reviews: +22% · Failed-delivery support contacts: −31% · within 8 weeks
05 — Measurable Business Impact

Specific, measurable, time-bound outcomes

Measured over 12 weeks post-launch · 4 enterprise clients + 15 merchant partners in pilot cohort

Metric Before After Change
First-attempt delivery success rate ~83% ~91% +9.6%
WISMO calls as % of support volume ~22% ~9% −59%
Partner integration lead time 7 days 1.5 days −79%
Status propagation latency 30–90 min <90 sec 60× faster
Webhook event delivery reliability N/A (polling) >99.5% New capability
Post-delivery review rate (enterprise pilot) Baseline +22% +22%
Daily re-delivery cost savings — ₹60–80K/day Network-wide
06 — Technical Aspects of the Solution

Built for scale. Decoupled by design.

An event-driven microservice layer on top of Blowhorn's existing OMS — completely decoupled from core write paths, ensuring zero latency impact on order processing. Each component was a deliberate product decision, not just an engineering one.

🔄
CDC + Event Streaming
Order status changes captured at the database level via Change Data Capture — completely decoupled from the OMS write path. No performance risk to core order processing, regardless of event volume.
🚀
Event Dispatcher Service
Consumes the event stream, enriches payloads with rider name, masked phone, and OTP via internal service calls, then delivers over HTTPS to each partner's registered endpoint.
♻️
In-Memory Retry Queue
Exponential backoff retry: 30s → 2min → 8min, 3 attempts total. Failed events surfaced in the partner dashboard for manual retry. No silent failures — every undelivered event is visible and actionable.
📊
Log Search + Dashboarding
Every dispatch attempt logged with status, latency, and retry count. Powers both the partner-facing Event Log UI and internal SLA observability dashboards — key to our >99.5% delivery reliability.
☁️
Managed Container Infrastructure
Auto-scaling to handle 3× volume spikes during high-growth sale events. Maintained 99.9% service uptime throughout the pilot and network-wide rollout.
🖥️
Self-Serve Partner Dashboard
Partners register endpoints, test events with live HTTP responses, view logs, and retry failures — no Blowhorn integration engineer required at any point. This was the key unlock for the 1.5-day onboarding time.