A company would send what it wanted, in what quantity and for which date, by chat, PDF, email, spreadsheet or online sheet. Each had its own headers, its own column order and its own names for the products. A person took each one and re-typed it into the format the company’s systems accepted, then ran the checks.
The order arrives in any format and the recipe finally has a cost
A healthy-food manufacturer replaced hand-converting business orders that arrived as messages, PDFs, emails and spreadsheets in every layout, and a stopwatch that measured cooking time without turning it into information, with a system that reads any order file into the production plan and logs the time each recipe takes on each shift.
The recorded interview is undated and the transcript is machine-generated. The business line it describes was reported publicly in 2024, which suggests the interview is from that period or later; that is an inference, not a date. Company-scale figures (tonnes per month, employees, kitchen size) are from business press between October 2024 and April 2026 and describe the operation, not results of the system. The speaker is not named in the transcript and is not named here.
A healthy-food manufacturer whose cost is the time people spend on each recipe.
Liv Up makes frozen healthy meals and sells them direct to consumers, through marketplaces and retail, and to businesses under a dedicated line. Consumer demand is forecast and produced to stock. Business demand arrives as orders. Both feed the same kitchen.
Frozen healthy meals
2016Founded
300+Tonnes of meals produced per month, company figure in 2024
10,000 m²Central kitchen
500+Employees, company figure in 2026
5Name variants a single product could have across customer order files, by the team’s accountRecorded interview.
300+ tonnesMeals produced per monthThe company, as reported by business press in October 2024. Company scale, not a result attributed to the system.
500+EmployeesThe company, as reported by business press in April 2026. Company scale, not a result attributed to the system.
10,000 m²Central kitchenThe company, as reported by business press in April 2026. Company scale, not a result attributed to the system.
“A big bottleneck was knowing what it costs, in fact. How long is that person spending on that rice, and which process are they doing? We could see that when we made a dish in the morning it was cheaper, and in the afternoon more expensive. Why the difference? With so many recipes and so many people preparing them, we couldn’t get what a recipe was costing day to day. We could go down and time it with a stopwatch, but not turn that into information.”
Liv UpOperations team member, in the recorded interview
BeforeAfter
- Reading each order and re-typing it into the system’s layoutAn importer that reads any spreadsheet layout, locates the rows and columns it needs and loads the order
- Fixing product names by hand, variant by variantA translation from each customer’s names to the internal catalogue, applied on import
- Checking each order after conversionChecks carried on the order record and read as a status
- Production priorities communicated to the floor by handA production plan by campaign, with a prioritised list of recipes the floor sees
- A stopwatch on the floorTime logged per recipe, per product, per shift, in the system
- Recipe cost as an unexplained averageRecipe cost from measured time, comparable across shifts and over time
- Efficiency projects too small to justify an in-house buildProjects the team can take on because implementation is fast
What was not replaced. The company’s own systems for stock, forecasting and fulfilment stayed; the importer feeds them. Customers were not asked to change how they send orders. The recipes and the kitchen are the same; they are now measured. The team that owns recipe cost stayed and now has data to work with.
The bottleneck was operational, not commercial
Liv Up makes frozen healthy meals and sells them direct to consumers, through marketplaces and retail, and to businesses under a dedicated line. The company was founded in 2016, runs its own operation from raw material to the courier’s hands, and by the company’s own figures produced more than 300 tonnes of meals a month in 2024 from a 10,000 square metre central kitchen, with more than 500 employees and delivery in about 200 cities. Its business line supplies meals to companies and restaurant chains, with deliveries adapted to each customer.
A meal factory that also sells to businesses runs two operations that meet in the kitchen. Consumer demand is forecast and produced to stock. Business demand arrives as orders, each company sending what it wants, how much, and when, in whatever format it uses internally. Both feed the same production plan, the same recipes, the same shifts. The cost of the company’s product is, in the end, the time its people spend on each recipe.
That is why the bottleneck was operational and not commercial. Orders were coming in. The team’s own description of the problem was organisational: how to bring efficiency to the operation without building every tool in-house, which the company had tried and found hard to sustain, and how to find out what a recipe cost when the only instrument was a stopwatch.
A clean order in and a measured cost out each required a person doing conversion work
“A big bottleneck was knowing what it costs, in fact. How long is that person spending on that rice, and which process are they doing? We could see that when we made a dish in the morning it was cheaper, and in the afternoon more expensive. Why the difference? With so many recipes and so many people preparing them, we couldn’t get what a recipe was costing day to day. We could go down and time it with a stopwatch, but not turn that into information.”
Customers could call a product whatever they liked on their side. The team saw products with five name variants across files. In a spreadsheet, a space before the weight is enough to break a match, so every one of those had to be found and fixed by hand.
The company had a team dedicated to understanding and reducing the cost of its recipes. It knew a dish cost more on one shift than another and could not say why, because there was no record of how long each person spent on each step of each recipe. A stopwatch produced a number; it did not produce a comparison.
Early on, the company developed its operational tools itself. The team’s own account is that this was hard to give enough attention to, and hard to use for all the efficiency projects it needed. Projects that were not large enough to justify a build were not looked at.
The pattern: the operation was well run and under-measured. Nothing was broken. But the two things that would let it improve, a clean order in and a measured cost out, each required a person doing conversion work, and there was never enough of that person.
Item by item, what did each job before and what does it today
| What did this before | What does it today |
|---|---|
| Reading each order and re-typing it into the system’s layout | An importer that reads any spreadsheet layout, locates the rows and columns it needs and loads the order |
| Fixing product names by hand, variant by variant | A translation from each customer’s names to the internal catalogue, applied on import |
| Checking each order after conversion | Checks carried on the order record and read as a status |
| Production priorities communicated to the floor by hand | A production plan by campaign, with a prioritised list of recipes the floor sees |
| A stopwatch on the floor | Time logged per recipe, per product, per shift, in the system |
| Recipe cost as an unexplained average | Recipe cost from measured time, comparable across shifts and over time |
| Efficiency projects too small to justify an in-house build | Projects the team can take on because implementation is fast |
What was not replaced. The company’s own systems for stock, forecasting and fulfilment stayed; the importer feeds them. Customers were not asked to change how they send orders. The recipes and the kitchen are the same; they are now measured. The team that owns recipe cost stayed and now has data to work with.
The chain, end to end, for one business order
- 1The customer sends its order in whatever format it usesExternal
Chat, PDF, email, spreadsheet or online sheet; the habit stays.
- 2The importer reads the file, finds the rows and columns, translates the customer’s product names to the internal catalogue and creates the order recordAutomatic
Any spreadsheet layout; headers and column order do not have to match.
- 3Anything the importer could not match is shown to a person, who resolves it once so it matches next timePerson
A one-time action rather than a monthly one.
- 4The order record carries its checks: quantities, delivery date, feasibility against the planAutomatic
Evaluating an order is reading a status.
- 5The order enters the production plan for its campaign; the floor receives the prioritised recipe listAutomatic
Which recipes to make, in which order.
- 6Cooks prepare recipes and log the time per recipe and per shift as they goPerson
The mark sits inside the recipe the cook is already following.
- 7Recipe cost is computed from logged time and compared across shifts and datesAutomatic
A measured number, not an unexplained average.
- 8The order is picked, packed and handed to the courier through the company’s fulfilment systemsAutomatic, then External
Those systems stayed; the importer feeds them.
The hard links are 3 and 6. The importer can only translate names it has seen, so a person has to resolve each new variant; the design makes that a one-time action rather than a monthly one. And the time log is only as true as the cook who marks it; the design accepts that and puts the mark inside the recipe the cook is already following. Everything the cost team does downstream depends on those two human steps being cheap enough to happen every time.
“Things we used to say weren’t worth even looking at, because they weren’t a super structured project, today we can look at, take on and get efficiency from, because we have fast ways to implement them.”
What changed, and what the source does not measure
| Indicator | Result | Where it comes from |
|---|---|---|
| Order intake | From manual conversion of every order file to import from any layout with name translation | Recorded interview |
| Product name matching | From five variants fixed by hand to a translation applied on import | Recorded interview |
| Recipe cost | From an unexplained average to time measured per recipe and per shift | Recorded interview; no cost figure before or after is given |
| Floor priorities | From communicated by hand to a prioritised list from the production plan | Recorded interview |
| Efficiency projects | From “not worth looking at” to taken on, by the team’s account | Recorded interview |
No measured time, cost or error figure exists in the source. The interview describes what was converted by hand and what is now measured. It does not give hours saved on order conversion, the error rate before and after, or any recipe cost figure. The team now has the measurement; the source does not report what it found.
“Any format” means any spreadsheet layout. The importer reads files with unfamiliar headers and out-of-order columns. Orders that arrive as chat messages or PDFs are not described as imported automatically; the interview lists them as formats that used to arrive, not as formats the importer reads.
Measurement is not improvement. The system logs time per recipe per shift. Whether the afternoon shift got cheaper is not in the source. What the interview supports is that the company can now see the difference and work on it, which it could not before.
The company-scale figures are not results. Tonnes per month, employees, kitchen size and revenue describe the operation the system runs inside. Nothing attributes any of them to the system, and this case does not either.
What this case does not measure
Worth naming, because it is usually what gets inflated.
All descriptions and both quotes come from one member of the operations team in a recorded interview whose transcript does not carry a name. No process was independently observed.
Orders per month, hours per order before and after, recipe cost per shift, error rate: none appear in the source.
Several passages were reconstructed from context. The business line it describes was reported publicly in 2024, which suggests the interview is from that period or later; that is an inference, not a date.
The team’s account of developing tools itself is used only to explain why it looked for another way. Which parts of the current system were built by the team and which by Jestor is not stated and not claimed.
The company’s own stock, forecasting and fulfilment systems are named as the destination of the imported order; how they are connected is not described.
They are used to describe the company, not the system.
In a business whose cost is labour per recipe, the recipe is the unit that has to be measured
| Indicator | Number | Source |
|---|---|---|
| Labour productivity in food manufacturing, output per hour, index 2017 = 100 | 93.7 in 2024, down from 108.3 in 2005 | U.S. Bureau of Labor Statistics, Industry Productivity, via FRED, updated April 2025 |
| Change in that index in 2024 | Down 4.6% in one year | Same series |
| Change in that index over the decade to 2024 | Down about 10% from 2014 | Same series |
The series above is for the largest food-manufacturing economy with published data, and it shows a sector producing less per hour of labour in 2024 than in 1997. Prepared meals sit at the labour-intensive end of that sector: every dish is made by people, and there is no machine that turns rice and vegetables into a home-style meal.
An average cost per kilo hides the difference between two shifts making the same dish. The company in this case could see that difference in its numbers and could not act on it until the time was logged where it happened.
Estimates of the frozen or healthy-meal market circulate widely and are vendor figures. They describe demand. The productivity series describes what it costs to meet it, which is the number this company was missing.
The system is built to fit, and responsibility for it stays with us
Liv Up had tried the two obvious routes. Building in-house gave it tools it could not maintain at the pace it needed. Doing nothing left order conversion to a person and recipe cost to a stopwatch. The question a bespoke system has to answer is what happens in year two: an importer nobody can update when a customer changes its file, or a time log nobody can extend to a new recipe, is the new spreadsheet in three years, with a login.
One builder owns each request from start to finish, and one is always in execution.
A new customer layout, a new recipe field or a new report comes in through the same channel, without becoming a new project.
If what was built is not right, it is rebuilt. Unlimited revisions within the subscription.
Seats are never the billing unit, which matters when planners, the cost team, order intake and every cook logging time all touch the same records.
People learn to use their app the way they learn any app, by opening it. Building, configuring and maintaining stays on our side.
Full export at any time, by CSV and API. SOC 2 compliant, no exit fee. Pause in one click and the systems keep running.
Methodology and sources
The before-and-after descriptions and both quotes come from a recorded interview with a member of the company’s operations team, used through its machine-generated transcript, which does not identify the speaker. Quotes were cleaned of transcription noise without changing their content. The account is the company’s own and was not audited.
Founding year, production volume, kitchen size, headcount, city coverage and the business line from the company’s statements to business press between October 2024 and April 2026.
U.S. Bureau of Labor Statistics, Labor Productivity for Food Manufacturing (NAICS 311), annual index and year-over-year change, retrieved from FRED.
No hours saved, cost reduced, error rate or recipe cost figure is claimed, because none was measured in the source. No revenue figure appears in this version.