# Bankuet: Giving food banks control over supply requests

> Food banks could set a budget but not choose exact quantities. I led the shift to visible prices and case quantities, reducing weekly request processing from about four hours to one.

Canonical HTML: https://laurence-peberdy.com/w/portal

Project: [Bankuet](https://bankuet.co.uk)

Project date: 9 July 2024

## At a glance

### My role

I set direction, priorities and scope, and worked with our in-house UX Lead in Figma. I directed an external 2–4-person team across business analysis, engineering and QA, bringing in architecture support as needed.

### Decision

Stop optimising an allocation algorithm and let food banks choose exact quantities against visible prices.

### Outcomes

Weekly processing ~4h → 1h · average underspend ~7% → 0%

![Bankuet's request interface, showing products that food banks can request by case quantity.](https://laurence-peberdy.com/images/foodbank-service-request-a-delivery.png)

Choosing products by case quantity in the redesigned request interface.

<a id="summary"></a>

## 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.

<a id="problem"></a>

## 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.

<a id="constraints"></a>

## 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.

<a id="hypothesis"></a>

## 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.

<a id="solution"></a>

## 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.

<a id="comparison"></a>

## What changed

The request model before and after v3:

### Before — describe priorities

- The food bank chooses an overall budget.
- Products receive high, medium or low priorities.
- An algorithm allocates quantities; Bankuet interprets or adjusts the result.

### After — choose quantities

- The food bank sees unit and case prices.
- It chooses exact case quantities in a persistent basket.
- The request expresses the supplies wanted rather than a set of relative preferences.

<a id="outcomes"></a>

## Outcomes

The strongest outcomes were operational:

<a id="bankuet-portal-processing-time"></a>

- Weekly request-processing time fell from approximately **four hours to one hour** — a 75% reduction.

<a id="bankuet-portal-budget-underspend"></a>

- Average budget underspend fell from approximately **7% to 0%**, comparing the three months before launch with the three months after.

<a id="bankuet-portal-support-queries"></a>

- Finance- and request-related support queries fell by approximately **50%** across the wider v2→v3 programme — not v3 alone.

## Showcase

[How Bankuet Works For Food Banks](https://vimeo.com/1012782893)

An animated explanation of how Bankuet turns donations into the supplies food banks need most.

How Bankuet Works For Food Banks · 2:20

Published: 5 August 2026

Updated: 6 September 2026

[JSON source and measurement metadata](https://laurence-peberdy.com/projects/portal.json)