HB Partner Dashboard
HB Partner Dashboard
Giving vendor partners a window into their own business
Giving vendor partners a window into their own business
The Brief
The Brief
Built an end-to-end vendor platform focused on payment visibility and trust, enabling partners to track invoices, understand payment status, and manage their business independently.
The Challenge
The Challenge
Vendors had zero visibility into payments, leading to high anxiety, constant follow-ups, and a large volume of support queries, breaking trust in the platform.
The Impact
The Impact
Positioned HungerBox as a trusted financial partner, not just an ops platform. Driving:
33% decrease in invoice settlement time
63% decrease in payment related support tickets
27% increase in avg counters/vendors
Positioned HungerBox as a trusted financial partner, not just an ops platform. Driving:
33% decrease in invoice settlement time
63% decrease in payment related support tickets
27% increase in avg counters/vendors
A little about
HungerBox
A little about
HungerBox
HungerBox is India's largest institutional food-tech platform managing cafeteria operations for Fortune-500 companies like Infosys, Wipro, and Accenture.
Think of it as the Swiggy/Zomato. for corporate cafeterias, but with a full operations layers: vendor management, food safety, SaaS tooling, and an ordering app used by over 3.8 lakh employees daily.
The business runs on a network of food vendor partners, small to mid-sized catering businesses who operate the kitchens inside these campuses. Without them, there's no food. Without trust, there's no them.
HungerBox is India's largest institutional food-tech platform managing cafeteria operations for Fortune-500 companies like Infosys, Wipro, and Accenture.
Think of it as the Swiggy/Zomato. for corporate cafeterias, but with a full operations layers: vendor management, food safety, SaaS tooling, and an ordering app used by over 3.8 lakh employees daily.
The business runs on a network of food vendor partners, small to mid-sized catering businesses who operate the kitchens inside these campuses. Without them, there's no food. Without trust, there's no them.
Problem
Problem
Imagine running a business where your biggest client never tells you when they'll pay you.
That was the reality for HungerBox's vendor partners. They served thousands of meals a day, raised invoices, and then waited. No visibility. No updates. No way to know if the invoice was even received.
~38% of all vendor support tickets were payment status queries. The fix wasn't just a feature. It was a relationship.
Imagine running a business where your biggest client never tells you when they'll pay you.
That was the reality for HungerBox's vendor partners. They served thousands of meals a day, raised invoices, and then waited. No visibility. No updates. No way to know if the invoice was even received.
~38% of all vendor support tickets were payment status queries. The fix wasn't just a feature. It was a relationship.
Research
Research
How we learned what vendors actually needed:
How we learned what vendors actually needed:
Method
What it Revealed
Contextual interviews
(140+ vendors, in their kitchens)
Contextual interviews
(140+ vendors, in their kitchens)
Vendors navigating WhatsApp threads to find PO numbers mid-service
Vendors navigating WhatsApp threads to find PO numbers mid-service
Support ticket analysis
(500+ tickets tagged & clustered)
Support ticket analysis
(500+ tickets tagged & clustered)
Payment status was the #1 topic by a wide margin
Payment status was the #1 topic by a wide margin
Diary studies
(40+ vendors, 2 weeks)
Diary studies
(40+ vendors, 2 weeks)
Vendors checking email compulsively, hoping for invoice updates that rarely came
Vendors checking email compulsively, hoping for invoice updates that rarely came
Stakeholder interviews
(Finance, Ops, RM teams)
Stakeholder interviews
(Finance, Ops, RM teams)
The internal payment workflow was invisible to vendors at every step
The internal payment workflow was invisible to vendors at every step
The one quote that shaped everything:
I don't know where my money is. I've raised the invoice. I've followed up. Nobody tells me what's happening.
I don't know where my money is. I've raised the invoice. I've followed up. Nobody tells me what's happening.
Who We Were Designing For
Who We Were Designing For
Three types of people use this platform with very different jobs to do.
Three types of people use this platform with very different jobs to do.
Business Owner
Big Picture first
Big Picture first
Goal
Revenue, Payment Timelines, Business Health
Checks In
Once a Day
"I have no idea how my business is doing this month."
Account Lead
Invoice Control
Invoice Control
Goal
Track invoices, access documents, audit trails
Checks In
Multiple times a Day
"Did anyone even see my invoice?"
Ops Manager
Fast Task Completion
Fast Task Completion
Goal
Menu, inventory, workforce, fast flows
Checks In
As needed
"Why do I have to call someone for basic info?"
Prioritization
Prioritization
With a broad scope payments, business analytics, growth tools, support we ran an Effort vs. Impact workshop with PMs, engineering, and finance to pick a starting point.
With a broad scope payments, business analytics, growth tools, support we ran an Effort vs. Impact workshop with PMs, engineering, and finance to pick a starting point.
Payment visibility landed top-left, high impact, low effort. Not because it was the easiest thing to build, but because it was where vendor trust was breaking down the most. Everything else only matters once that trust exists.
Payment visibility landed top-left, high impact, low effort. Not because it was the easiest thing to build, but because it was where vendor trust was breaking down the most. Everything else only matters once that trust exists.
The Phased Plan:
The Phased Plan:
Phase 1a → Payments dashboard + invoice tracking (trust baseline)
Phase 1b → Expanded payments + notifications (communication layer)
Phase 2 → Business metrics + support + profile (business partner)
Phase 3 → Growth: onboarding, lead gen, promotions (expansion)
Phase 1a → Payments dashboard + invoice tracking (trust baseline)
Phase 1b → Expanded payments + notifications (communication layer)
Phase 2 → Business metrics + support + profile (business partner)
Phase 3 → Growth: onboarding, lead gen, promotions (expansion)
The Dashboard
The Dashboard
The first screen vendors see after login. Designed around one question: "How's my business right now?"
Top half - Invoice & Settlement Summary:
Four tiles: Uploaded · Settled · Ongoing · Pending. Each clickable, each scoped to the last 3 months. Below it, the last 10 transactions in a scannable table.
Bottom half - Business Summary:
Total Sales · Orders Delivered · Avg. Order Value · Avg. Rating benchmarked against the previous period with trend indicators. Filterable by city, company, counter, and vendor for partners running multiple locations.
This single screen replaced the spreadsheets, the RM calls, and the guesswork.
The first screen vendors see after login. Designed around one question: "How's my business right now?"
Top half - Invoice & Settlement Summary:
Four tiles: Uploaded · Settled · Ongoing · Pending. Each clickable, each scoped to the last 3 months. Below it, the last 10 transactions in a scannable table.
Bottom half - Business Summary:
Total Sales · Orders Delivered · Avg. Order Value · Avg. Rating benchmarked against the previous period with trend indicators. Filterable by city, company, counter, and vendor for partners running multiple locations.
This single screen replaced the spreadsheets, the RM calls, and the guesswork.
The Payment Detail Page
The Payment Detail Page
Think of this like a courier tracking page but for money.
Just like you track a package from "Shipped" → "Out for delivery" → "Delivered," vendors can now track their invoice from upload to payment at every step.
Think of this like a courier tracking page but for money.
Just like you track a package from "Shipped" → "Out for delivery" → "Delivered," vendors can now track their invoice from upload to payment at every step.
The page was state-driven - every state showed different content, different actions, and a different contextual message:
The page was state-driven - every state showed different content, different actions, and a different contextual message:
Supporting Documents
Supporting Documents
Every document - Purchase Order, Invoice, Vendor Bill accessible at the bottom with Comments, Share on Email, and Download. Before this, vendors had to request documents from their RM. Making this self-serve removed a significant friction point.
Every document - Purchase Order, Invoice, Vendor Bill accessible at the bottom with Comments, Share on Email, and Download. Before this, vendors had to request documents from their RM. Making this self-serve removed a significant friction point.
expandable supporting document card, user can add comments, view doc etc.
Usability Testing - Round 1
Usability Testing - Round 1
Method: Moderated task-based testing · think-aloud protocol · 60 vendors · 45 min each
Method: Moderated task-based testing · think-aloud protocol · 60 vendors · 45 min each
Finding
Severity
What we changed
Vendors entered invoice amount higher than PO value
Vendors entered invoice amount higher than PO value
HIGH
HIGH
Real-time validation + helper text
Real-time validation + helper text
Ongoing / Settled" confused non-English vendors
Ongoing / Settled" confused non-English vendors
MEDIUM
MEDIUM
Relabelled "Active / Paid" tested better
Relabelled "Active / Paid" tested better
Progress tracker wasn't seen without expanding the row
Progress tracker wasn't seen without expanding the row
HIGH
HIGH
Auto-expanded on page load for active invoices
Auto-expanded on page load for active invoices
Share button was missed vendors used it frequently
Share button was missed vendors used it frequently
MEDIUM
MEDIUM
Moved to primary action row
Moved to primary action row
Filter UI felt like a code block vendors hesitated
Filter UI felt like a code block vendors hesitated
MEDIUM
MEDIUM
Replaced with pill-based quick filters
Replaced with pill-based quick filters
Handling Mixed States
Handling Mixed States
A single PO can have multiple invoices some in early payment, some in regular payment, some already paid. Each row's CTA had to accurately reflect its own state while living inside the same view. Making four different states coexist in one list without creating confusion was one of the harder interaction problems in the product.
A single PO can have multiple invoices some in early payment, some in regular payment, some already paid. Each row's CTA had to accurately reflect its own state while living inside the same view. Making four different states coexist in one list without creating confusion was one of the harder interaction problems in the product.
The Problem Behind the Problem
The Problem Behind the Problem
Corporate payment terms are long. A vendor delivers food in January, they might not see that money until March. For a business paying weekly wages and daily ingredient costs, that 60-day gap isn't just uncomfortable. It's a working capital crisis.
Most vendors were bridging it with personal credit or informal borrowing.
HungerBox had something banks didn't: deep knowledge of these vendors, their payment history, their client relationships, their monthly volume. That data could be turned into a financial product.
Corporate payment terms are long. A vendor delivers food in January, they might not see that money until March. For a business paying weekly wages and daily ingredient costs, that 60-day gap isn't just uncomfortable. It's a working capital crisis.
Most vendors were bridging it with personal credit or informal borrowing.
HungerBox had something banks didn't: deep knowledge of these vendors, their payment history, their client relationships, their monthly volume. That data could be turned into a financial product.
detailed confirmation & authentication before initiating payment
Think of it like an advance on your salary
but for a business, with full transparency on the discount you're accepting.
but for a business, with full transparency on the discount you're accepting.
Usability Testing - Round 2
Usability Testing - Round 2
Method: Prototype walkthrough · 60 eligible vendors · focused on consent and state clarity
Method: Prototype walkthrough · 60 eligible vendors · focused on consent and state clarity
Finding
What we changed
Vendors focused on net payable, scanned past discount amount
Increased visual weight of discount row; added colour
OTP felt unexpected, "why do I need this?"
Added line above field: "An OTP confirms this financial commitment."
"Early Pay Status" was tapped expecting an action
Changed from a button treatment to a status label
Early payment signal wasn't noticed on the listing row
Added inline icon + "Early Payment Available" tooltip
Mixed-state rows felt visually overwhelming
Added clear visual separation between early payment and regular invoice rows
Impact
Impact
50%
18% higher engagement
Vendor adoption (month 1)
Vendor adoption (month 1)
33% decrease
18% higher engagement
in invoice settlement time
in invoice settlement time
~63% decrease
18% higher engagement
in Payment-related support tickets
in Payment-related support tickets
18% decrease
18% higher engagement
in RM calls on payment status
in RM calls on payment status
27% increase
18% higher engagement
in avg. counters/ vendors (more signups)
in avg. counters/ vendors (more signups)
20%
20%
Early payment adoption (eligible vendors)
Early payment adoption (eligible vendors)
~₹75 lakhs
18% higher engagement
Invoice value via early payment (first 3 months)
Invoice value via early payment (first 3 months)
Reflection:
Reflection:
Designing beyond Orders
Sequencing is strategy. Payments first wasn't the obvious choice, it was the right one. The platform couldn't earn the right to talk about growth until it solved trust.
Appropriate friction is a feature. The OTP wasn't a security checkbox. It was a design statement: this decision has financial weight. Most of our job is removing friction, knowing when to add it is the harder skill.
State management is a design problem. When one view has to handle invoices in 5 different states simultaneously, the logic is as important as the layout.
Words are design. Every status message was written, tested, and iterated like a UI component. Getting the words right reduced support calls as much as any layout change.
Sequencing is strategy. Payments first wasn't the obvious choice, it was the right one. The platform couldn't earn the right to talk about growth until it solved trust.
Appropriate friction is a feature. The OTP wasn't a security checkbox. It was a design statement: this decision has financial weight. Most of our job is removing friction, knowing when to add it is the harder skill.
State management is a design problem. When one view has to handle invoices in 5 different states simultaneously, the logic is as important as the layout.
Words are design. Every status message was written, tested, and iterated like a UI component. Getting the words right reduced support calls as much as any layout change.
thank you!
keep exploring
thank you!
keep exploring
Bringing ideas
to life,
one product
at a time
Made with 🔥
Bringing ideas to life,
one product at a time
Made with 🔥