Catering and foodservice
Tray plans the event, scales the food to the guests who are coming, prints the allergen sheet your kitchen hands over before service, buys the week’s ingredients, gets it out the door with temperature records, and tells you afterwards whether it made money.
All of it is built and running, and it is switched on per account rather than forced on everyone. The quickest way to judge it is the caterer’s tour, which runs on sample data in three languages.
Shipping today
The manufacturing spine underneath the catering module. It is the part of catering that goes wrong expensively.
Every delivery is scanned in and becomes a lot stamped with its supplier, dates and condition. Not a sticky note on the walk-in door.
Declarations roll up through sub-recipes, so Tuesday’s sauce carries its allergens into Saturday’s dish. The answer names the ingredient it came from. Fifteen types, at SKU and lot level.
A filling built on Tuesday from several lots becomes a lot in its own right, so there is no gap between raw ingredient and finished tray for a recall to slip through.
A plate costed from what actually went into it, through every sub-recipe and yield, at the supplier prices you pay today. You know the margin on 60 covers before the quote goes out.
Buy the case, cook in pieces. A dish needing 2 pieces from a 6-pack draws 0.333 of a pack, costed at that fraction. Unit costs run to four decimals, because a canapé costs a fraction of a cent.
A supplier reports a problem. One trace runs forward through every sub-recipe and production run it touched, to every function it was served at.
All six are in the caterer’s tour, running on sample data, in three languages. There is also a public lot trace with no login and no JavaScript, if you would rather read the output than click through a demo.
Plan and cook
Guest count, service date, venue, service window and the final-count deadline sit at the top of the order. Everything downstream reads from them.
Pick the function and the batch scales to the guests using each recipe’s portion size. A panel compares every ingredient against usable stock and flags the shortfalls.
If a dish already has a production run for that function, Tray says so rather than quietly making a second one.
One printable page per function: every dish, its allergens rolled up through sub-recipes, and a separate “may contain” line for cross-contact. Names print in the reader’s language.
Nut allergy × 2, vegan × 6 with a replacement dish, kids × 12. For each group the sheet shows which dishes they must not get, and how many plates are unsafe.
Ingredients are tagged once; each dish works out its own diet from its recipe and sub-recipes. Dishes carry VG and V badges.
Every function on a day with timing, venue, guests and production status, plus a “short today” box measured against usable stock. Lots on hold do not count.
No guest names are stored. A special meal is a label and a count — “vegan × 6” — never a person. Your guest list stays wherever you keep it.
Win the event
A catering order can start life as a client proposal and only becomes a job when the client accepts it.
Service staff, rentals and delivery as their own lines, with taxes, a deposit and a validity date.
The menu without per-dish prices, the special meals, the total, the deposit, the balance and the final-count deadline. It always says it is a proposal, not an invoice.
Before acceptance it holds no stock, starts no production, and is not counted as demand.
Due, overdue, received. The deposit follows the total until someone sets it by hand, and dates are checked against the event.
After the deadline a change needs a reason, and the kitchen sees it: production was scaled for 180, the function now has 195.
There is no event calendar and no CRM. You book the function wherever you book it today.
Tray does not issue your catering invoices and does not file with any tax authority. It produces proposals and tracks deposits; your accountant invoices. Accounting stays an export, never a sync.
Buy for the week
Pick a week and Tray adds up every ingredient the confirmed events need, through recipes and sub-recipes, including the replacement dishes for special meals.
Usable stock, orders already placed and production already started come off before anything is ordered.
Each line rounds up to the case size of the supplier you chose, not to a number that cannot be bought.
Each quantity points at the event and the dish that asked for it.
One click drafts one purchase order per supplier. Nothing leaves until someone confirms it.
Anything Tray cannot compute appears blocked with the reason attached, rather than silently dropping off the list.
Vehicle, driver, departure time, and an equipment list with quantities out and back. Kit that has not come back is flagged after the event.
Deliver and prove it
Temperature records at loading, arrival and service, against limits set per account.
Defaults are 63 °C hot and 4 °C cold, changed per account.
A reading outside the limit cannot simply be left there.
Enforced in the database, not just the screen. An order that carries temperature readings cannot be deleted either.
Every reading carries its reader and its timestamp.
One step, and a person confirms it.
One page per event in departure order: what to load, the special meals with their diet, the kit, where to go, and the temperature table.
Tray produces the records a HACCP plan asks for. It is not itself certified, and using it does not make your operation certified.
Know whether it made money
Per event and over any date range, exportable to CSV, visible only to people allowed to see costs.
What the event brought in, and what that is per head.
Planned cost from recipe costs including service lines, against the actual cost of what production really used, lot by lot.
What was made and not sold, counted rather than estimated.
If a cost is unknown or the event is not fully produced, Tray says so instead of showing a margin that reads as fact.
Labour comes from the recipes. Tray does not track the hours your staff actually worked, and we are not going to imply that it does.
Any date range, exported for whoever does your books.
The habit underneath all of it
This is the rule the whole system is built on, and it is the one that matters most in a kitchen feeding people with allergies.
Tray suggests scaled batches, purchase orders and nonconformance reports. A person confirms each one. Nothing is sent, ordered or opened automatically.
Where Tray stops
Not built yet
The three screens this page used to list as unbuilt now exist. Keeping the list honest means replacing them rather than deleting the section.
Which dish starts when, and which member of staff is on it. Tray plans the food. It does not plan the shift.
Tray prints the proposal. Emailing it to the client is still your mail program’s job.
The sheet tells the kitchen who must not get what. It does not yet print the label that travels with the plate.
No delivery dates, because we do not have any. There is also still no event calendar and no CRM, and we are not trying to build one.
These screens are built, so there is nothing left to imagine. What is worth doing now is putting your own functions through them — your menus, your guest counts, your special meals — and finding out where they hold and where they do not.
What we ask
What you get