Bankuet: Giving food banks control over supply requests

Context

Before v3, a food bank did not tell Bankuet exactly how many cases of each product it wanted. It set a total budget and marked products high, medium or low priority. An algorithm chose the quantities, and our team often had to interpret or adjust the result.

I replaced that model with visible prices and exact case quantities. Food banks could see the cost of their choices and submit the request they actually wanted; Bankuet spent less time fixing the output.

Problems

• Food banks could express priorities, not quantities. They could say what mattered most, but not how many cases they wanted.
• They could not see the cost of each choice. Without unit and case prices, users could not tell how a product affected their budget.
• Bankuet had to repair the algorithm's output. Allocations could underspend the budget or need manual adjustment before ordering.
• Precise requests needed better financial context. Food banks had limited information about previous requests, spending and their available balance.

The evidence came from food bank feedback and my own experience processing Bankuet's supply orders each week.

Constraints

The request form is not an isolated interface; it feeds Bankuet's weekly ordering operation. Three constraints shape it:

• Requests feed a live weekly workflow. Food bank requests flow directly into Bankuet's supply-ordering process, so errors in the request flow can create operational work as well as user confusion.
• Exact quantities depend on trustworthy financial context. Food banks need reliable balances and visible prices before more granular control is useful.
• Prices can change before fulfilment. The design needs a workable tolerance for changes between request and fulfilment rather than implying every displayed price is fixed.

Working hypothesis

If food banks can choose exact quantities against visible prices, requests should become more accurate and understandable, reducing manual intervention and algorithmic budget underspend.

Decisions and delivery

I did not jump straight to exact quantities. First I made balances, request history and spending clearer, because precise choices only help if the user can trust the budget they are spending.

With those foundations in place, v3.0 — Volumes and Values launched on 9 July 2024, with:

• unit and case prices alongside each product;
• exact case quantities rather than none/low/medium/high preferences;
• a persistent basket that could be continued across sessions and accounts;
• an additional-supplies route for needs outside Bankuet's normal range.

I kept v3.0 focused on request creation, leaving better search, further request-history improvements and help content for later releases.

I ran research with food banks to test what price changes between request and fulfilment they would accept. We also released v3 to a small group before wider rollout to reduce operational risk.

What changed

The request model before and after v3:

Outcomes

The strongest outcomes were operational:

• Weekly request-processing time fell from approximately four hours to one hour — a 75% reduction.
• Average budget underspend fell from approximately 7% to 0%, comparing the three months before launch with the three months after.
• Finance- and request-related support queries fell by approximately 50% across the wider v2→v3 programme — not v3 alone.