Case Study, Dec 2025
Case Study, Dec 2025
Reducing marketplace downtime by ~40% for multi-store restaurant brands
Designing Voosh’s Downtime Controller and activation strategy to protect revenue on UberEats & DoorDash
Designing Voosh’s Downtime Controller and activation strategy to protect revenue on UberEats & DoorDash
TL;DR
• Redesigned Voosh’s Downtime Controller + activation funnel for multi-store restaurant brands.
• Shifted the story from “uptime %” to “orders and revenue at risk”.
• Made the module visible on the dashboard and safe to try via a guided trial.
• Result: ~40% reduction in non-genuine downtime minutes/store and 2.4× more accounts unlocking the module in 6 weeks.
• Redesigned Voosh’s Downtime Controller + activation funnel for multi-store restaurant brands.
• Shifted the story from “uptime %” to “orders and revenue at risk”.
• Made the module visible on the dashboard and safe to try via a guided trial.
• Result: ~40% reduction in non-genuine downtime minutes/store and 2.4× more accounts unlocking the module in 6 weeks.
Role
Sole Product Designer
Sole Product Designer
Product
Downtime Controller
Downtime Controller
Team
Founder, 3+ Techies, Sales
Founder, 3+ Techies, Sales
00
Key Outcomes
Key Outcomes
40%
40%
reduction in non-genuine downtime minutes per store
2.4x
2.4x
increase in accounts that unlock the Downtime Controller module
3.1x
3.1x
increase in accounts that set up at least one auto-reopen rule
01
Context
Context
Voosh is a control tower for multi-store restaurant brands on UberEats, DoorDash and other marketplaces, used to monitor performance, reconcile revenue, and manage operations across dozens of outlets.
In this environment, uptime is revenue: if a store is offline, it simply cannot receive orders. Marketplaces sometimes turn stores off without clearly notifying brands. Some reasons are genuine (stock-outs, safety, planned maintenance), but many are non-genuine (temporary capacity flags, integration issues, delivery partner gaps, internal throttling).
For brands with 50+ outlets, this becomes a silent, hard-to-detect revenue leak. Individual stores go dark on specific marketplaces; ops teams usually notice only after an order drop or a manual dashboard check—often after peak-time is already gone.
Voosh already aggregated marketplace status and performance data. The next step was to turn that into a product that could surface, fix, and ultimately prevent unnecessary downtime at scale.
Voosh is a control tower for multi-store restaurant brands on UberEats, DoorDash and other marketplaces, used to monitor performance, reconcile revenue, and manage operations across dozens of outlets.
In this environment, uptime is revenue: if a store is offline, it simply cannot receive orders. Marketplaces sometimes turn stores off without clearly notifying brands. Some reasons are genuine (stock-outs, safety, planned maintenance), but many are non-genuine (temporary capacity flags, integrations issues, delivery partner gaps, internal throttling).
For brands with 50+ outlets, this becomes a silent, hard-to-detect revenue leak. Individual stores go dark on specific marketplaces; ops teams usually notice only after an order drop or a manual dashboard check—often after peak-time is already gone.
Voosh already aggregated marketplace status and performance data. The next step was to turn that into a product that could surface, fix, and ultimately prevent unnecessary downtime at scale.
02
Problem
Problem
For restaurant brands
No single place to see which stores are offline, on which marketplace, and why
No single place to see which stores are offline, on which marketplace, and why
Ops & regional managers often discover issues only after an order drop or internal escalation
Ops & regional managers often discover issues only after an order drop or internal escalation
Manual monitoring doesn’t scale beyond a handful of stores
Manual monitoring doesn’t scale beyond a handful of stores
For Voosh (v1 reality)
In Mar 2025 we shipped v1 of Downtime Controller, which polled store status every 5 minutes on UberEats/DoorDash and could trigger alerts or auto-reopen stores.
But in practice:
But in practice:
The module was buried in the product and looked like a niche settings page
The module was buried in the product and looked like a niche settings page
Story focused on uptime % instead of lost orders or revenue saved
Story focused on uptime % instead of lost orders or revenue saved
Auto-reopen felt risky and opaque to users
Auto-reopen felt risky and opaque to users
Unlocking required a sales call, adding friction and delay
Unlocking required a sales call, adding friction and delay
Result
very few accounts activated the module, and even fewer used auto-reopen – impact was negligible.
very few accounts activated the module, and even fewer used auto-reopen – impact was negligible.
Problem Statement:
We had a technically strong Downtime Controller that could prevent silent revenue loss, but brands weren’t discovering, understanding, or activating it – and our sales-led unlock flow made it even harder to try.
We had a technically strong Downtime Controller that could prevent silent revenue loss, but brands weren’t discovering, understanding, or activating it – and our sales-led unlock flow made it even harder to try.
03
Goals & Constraints
Goals & Constraints
User goals – Ops & leaders
01
Ops teams:
See, at a glance, which stores are down, where, and why
Trust that non-genuine downtime is fixed automatically
Stay in control for genuine downtime (stock-outs, maintenance, safety)
See, at a glance, which stores are down, where, and why
Trust that non-genuine downtime is fixed automatically
Stay in control for genuine downtime (stock-outs, maintenance, safety)
02
CXOs / owners:
Understand downtime in terms of orders and revenue at risk
Treat Voosh as an “always-on safety net” against silent losses
Understand downtime in terms of orders and revenue at risk
Treat Voosh as an “always-on safety net” against silent losses
Business goals
Voosh
Increase module unlocks for Downtime Controller
Increase completion of auto-reopen setup
Reduce non-genuine downtime minutes per store
Turn Downtime Controller into a flagship upsell in sales conversations
Increase module unlocks for Downtime Controller
Increase completion of auto-reopen setup
Reduce non-genuine downtime minutes per store
Turn Downtime Controller into a flagship upsell in sales conversations
Constraints
Incremental redesign: v1 live; changes couldn’t disrupt existing users
Incremental redesign: v1 live; changes couldn’t disrupt existing users
Sales-led pricing: custom pricing per account; no generic “$X/month"
Sales-led pricing: custom pricing per account; no generic “$X/month"
04
Approach
Approach
Diagnosing v1
01
Amplitude – visits, funnel drop-offs, setup completion
Amplitude – visits, funnel drop-offs, setup completion
02
Hotjar – navigation patterns, confusion, abandonment
Hotjar – navigation patterns, confusion, abandonment
03
Sales/CS – how they pitched the module, and what confused customers
Sales/CS – how they pitched the module, and what confused customers
Key Findings
01
01
Low discoverability – buried nav, looked like a setting, not a “protect revenue” tool
Low discoverability – buried nav, looked like a setting, not a “protect revenue” tool
02
02
Weak story– uptime jargon instead of money and risk
Weak story– uptime jargon instead of money and risk
03
03
Scary automation – unclear logic, fear of reopening genuinely closed stores
Scary automation – unclear logic, fear of reopening genuinely closed stores
04
04
Sales-only unlock – no way for users to safely try it on their own
Sales-only unlock – no way for users to safely try it on their own
Reframing the problem
Instead of “How do we improve this UI?”, we moved to:
“How might we help multi-store brands feel ‘always on’ for the right reasons – and trust Voosh to guard against silent, non-genuine downtime, in a way that’s easy to try and adopt?”
“How might we help multi-store brands feel ‘always on’ for the right reasons – and trust Voosh to guard against silent, non-genuine downtime, in a way that’s easy to try and adopt?”
05
The Solution
The Solution
01
Promoting Downtime Controller to a core module
Promoting Downtime Controller to a core module
From hidden sub-page to a first-class module in the navigation.
From hidden sub-page to a first-class module in the navigation.
02
Surfacing downtime risk on the Home dashboard
Surfacing downtime risk on the Home dashboard
Bring the problem and the trial CTA to where users already work.
Bring the problem and the trial CTA to where users already work.
This change alone drove a large part of the 2.4× increase in accounts unlocking the module by bringing the problem + CTA into the daily workflow.
03
Coverage & risk band (0% Protected state)
Coverage & risk band (0% Protected state)
Make “you’re unprotected” impossible to ignore.
Make “you’re unprotected” impossible to ignore.
04
Impact band once Auto-Reopen is enabled
Impact band once Auto-Reopen is enabled
Reuse the same layout to tell a “revenue saved” story.
Reuse the same layout to tell a “revenue saved” story.
05
Store-wise downtime table as ops cockpit
Store-wise downtime table as ops cockpit
Give regional managers one table to prioritise, act and track impact.
Give regional managers one table to prioritise, act and track impact.
06
Trial popup & dummy view for safe exploration
Trial popup & dummy view for safe exploration
Reduce fear of automation with education and a no-risk sandbox.
Reduce fear of automation with education and a no-risk sandbox.
Helped reduce fear of auto-reopen and contributed to 3.1× more accounts configuring at least one rule.
07
Product-led free trial inside a sales-led motion
Product-led free trial inside a sales-led motion
Let users experience value before they ever talk to sales.
Let users experience value before they ever talk to sales.
06
Validation & Impact
Validation & Impact
Pilot & iteration
We first enabled v2 + free trial for selected multi-store brands and tracked:
Visits to the module
Trials started
Rules configured
Alerts received & clicked
Auto-reopen incidents
Visits to the module
Trials started
Rules configured
Alerts received & clicked
Auto-reopen incidents
We then ran feedback calls with power users and ops heads, and iterated on:
Copy in banners/emails (stronger revenue framing)
Friction points in the guided setup
Clarity of Overview and History
Copy in banners/emails (stronger revenue framing)
Friction points in the guided setup
Clarity of Overview and History
After this, we rolled out to all eligible accounts.
After this, we rolled out to all eligible accounts.
Adoption & activation
Within the first 6 weeks:
2.4× more accounts unlocked Downtime Controller
3.1× more accounts configured at least one auto-reopen rule
Uptime Overview became part of daily ops routines for regional managers
2.4× more accounts unlocked Downtime Controller
3.1× more accounts configured at least one auto-reopen rule
Uptime Overview became part of daily ops routines for regional managers
Operational outcomes
40% reduction in non-genuine downtime minutes per store across pilot brands
Fewer “Why did this outlet suddenly stop getting orders?” escalations
Regional managers started their day with Uptime Overview, not fire-fighting threads
40% reduction in non-genuine downtime minutes per store across pilot brands
Fewer “Why did this outlet suddenly stop getting orders?” escalations
Regional managers started their day with Uptime Overview, not fire-fighting threads
Business impact for Voosh
Downtime Controller became a flagship upsell in conversations with multi-store brands
Trial usage gave sales a concrete, quantified story:
“In your 14-day trial, Voosh auto-reopened X incidents and protected ~₹Y in potential orders.”
Accounts using Downtime Controller showed stronger expansion MRR trends than similar accounts without it
Downtime Controller became a flagship upsell in conversations with multi-store brands
Trial usage gave sales a concrete, quantified story:
“In your 14-day trial, Voosh auto-reopened X incidents and protected ~₹Y in potential orders.”
Accounts using Downtime Controller showed stronger expansion MRR trends than similar accounts without it
07
My Role
My Role
As the sole Product Designer, I owned the end-to-end experience across product and activation:
Co-framed the problem with the founder across user, ops, and revenue dimensions
Analysed v1 using Amplitude, Hotjar, and sales/CS conversations
Redefined IA and flows for:
Dashboard uptime card
Uptime Overview, Rules, History
Auto-reopen guided setup
Store-level controls & activity log
Designed:
In-product announcements & notification patterns
Launch and lifecycle email templates
Free-trial unlock and trial → sales handoff flows
Collaborated with engineering on edge cases and system states
Worked with Sales/CS to align product narrative with their pitch
Defined success metrics and instrumentation for rollout
As the sole Product Designer, I owned the end-to-end experience across product and activation:
Co-framed the problem with the founder across user, ops, and revenue dimensions
Analysed v1 using Amplitude, Hotjar, and sales/CS conversations
Redefined IA and flows for:
Dashboard uptime card
Uptime Overview, Rules, History
Auto-reopen guided setup
Store-level controls & activity log
Designed:
In-product announcements & notification patterns
Launch and lifecycle email templates
Free-trial unlock and trial → sales handoff flows
Collaborated with engineering on edge cases and system states
Worked with Sales/CS to align product narrative with their pitch
Defined success metrics and instrumentation for rollout
08
Key Learnings
Key Learnings
Shipping ≠ adoption – v1 solved the technical problem but failed on discovery and story
Users think in money and risk, not uptime – reframing around orders & revenue saved changed engagement
Automation needs visible boundaries – showing where auto-reopen will and won’t act builds trust
Sales-led SaaS still needs strong product-led experiences – a low-friction trial plus clear value storytelling made sales cycles faster and more concrete
Shipping ≠ adoption – v1 solved the technical problem but failed on discovery and story
Users think in money and risk, not uptime – reframing around orders & revenue saved changed engagement
Automation needs visible boundaries – showing where auto-reopen will and won’t act builds trust
Sales-led SaaS still needs strong product-led experiences – a low-friction trial plus clear value storytelling made sales cycles faster and more concrete