Each morning a new Excel file was created and fed with opening stock, customer orders and sales projections. The output was a list of what to buy. Then someone typed each supplier's order into WhatsApp by hand.
The warehouse stopped waiting for the end of the day
A fresh-produce distributor replaced a daily purchasing spreadsheet, hand-typed supplier messages and printed picking lists with a warehouse system that updates stock from the floor, in real time, from a phone.
A fresh-produce distributor running its own supply chain from the field to the door.
It connects small and mid-sized farmers directly to restaurants and households. Buy too much and the surplus is thrown away; buy too little and the order is short. Both errors start from the stock number.
Fresh produce distribution
2019Founded
500+Restaurants served, at the time of the case (2022)
USD 100k+Monthly recurring revenue, company figure at the time of the case
2025Merged with another fresh-produce platform
500+Restaurants servedThe company's own published figure in the case header, at the time of the case (2022). A company-scale figure, not a result attributed to the system.
USD 100k+Monthly recurring revenueSame source, same date. It describes the size of the operation the system was built for, and nothing in the source attributes it to the system.
3Manual routines named as replacedThe daily spreadsheet, the data entry on the base computer and the printed lists. The count is the published case's own list in its "Before" section, not an estimate.
1 per dayNew spreadsheet files the purchase routine requiredThe published case's description of the old routine: a new Excel file every morning, fed by hand, to produce the day's purchase list.
“Jestor brought a new level of efficiency to our operation. By automating purchases and giving data autonomy to every team member, we now have true real-time data. The warehouse is now as tech-driven as the office, and time that would be spent dealing with spreadsheets is now used for planning and improving our core business.”
Eduardo PietraroiaCo-founder, in the 2022 published case
BeforeAfter
- A new Excel file each morning, filled by hand with stock, orders and projectionsA daily purchase list generated automatically, sorted by supplier
- Supplier orders typed one by one into WhatsAppA generated WhatsApp message per supplier, each order marked Placed and then Received
- Stock estimate updated by hand after orderingMarking an order Placed creates the estimate; Received updates the stock number
- Periodic data entry on a base computer, from paper countsEach warehouse member registers quantity changes from a phone, with filtered access
- End-of-day counting to reconcile stockNo reconciliation session: quantities are registered on the spot
- Printed picking lists, re-checked against new ordersA picking list that updates whenever demand exceeds the initial forecast
- Emails, messages, spreadsheets and workflow tools for internal suppliesOne request-and-approval flow for internal items, with purchase and price history
The ecommerce platform stayed as the customer-facing order channel. WhatsApp stayed as the supplier channel. The sales projection stayed as an external input. Pre-existing databases stayed and were being connected. The system sits between the order channel and the warehouse floor; it does not replace either end.
The bottleneck was operational, not commercial
The company connects small and mid-sized farmers directly to restaurants and households, running its own supply chain from the field to the customer's door. It was founded in 2019 and, at the time of this case, served more than 500 restaurants and had passed USD 100,000 in monthly recurring revenue, by its own published figures. In 2025 it merged with another fresh-produce platform serving food service and retail.
Fresh produce is a perishable, high-turnover business. Buy too much and the surplus is thrown away; buy too little and the customer's order is short. The company's model depends on predicting demand well enough to keep both errors small, and prediction is only as good as the stock number it starts from. A crate that spoils, a shipment that comes back, a pallet counted wrong: each one moves the number the forecast is built on.
That is why the bottleneck was operational and not commercial. The company already had customers and a way to forecast demand. What it did not have was a way for the warehouse floor to tell the office what had happened as it happened. Until it did, every forecast started from data that was already a day old.
The physical work was real-time and the data was batch
“Jestor brought a new level of efficiency to our operation. By automating purchases and giving data autonomy to every team member, we now have true real-time data. The warehouse is now as tech-driven as the office, and time that would be spent dealing with spreadsheets is now used for planning and improving our core business.”
Warehouse staff counted on paper and, at intervals, keyed their counts into a computer at the base. That step existed only to digitize what had already been collected manually. Between updates, the office worked from numbers that were already stale.
The team separated produce against a printed list of expected quantities, then kept checking incoming orders to see whether the list was already short.
The pattern behind all three: the physical work was real-time and the data was batch. Nothing in the process was broken yet. But a growing catalogue and growing sales meant the gap between what was on the floor and what was in the spreadsheet would widen until something did break.
Item by item, what did each job before and what does it today
“Jestor brought efficiency to just about every step of the process. Not having to manually type orders is a godsend, and being able to do everything through a smartphone makes sure things only need to be done once. It's easy too: some processes are as simple as marking a checkbox.”
| What did this before | What does it today |
|---|---|
| A new Excel file each morning, filled by hand with stock, orders and projections | A daily purchase list generated automatically from current stock, customer orders, sales projections and supplier delivery estimates, sorted by supplier |
| Supplier orders typed one by one into WhatsApp | A generated WhatsApp message per supplier; each order marked Placed and then Received |
| Stock estimate updated by hand after ordering | Marking an order Placed creates the stock estimate; marking it Received updates the stock number |
| Periodic data entry on a base computer, from paper counts | Each warehouse member sees stock and registers quantity changes from a phone, with access filtered to what they need |
| End-of-day counting to reconcile stock | No reconciliation session: quantities are registered on the spot, so the number is current |
| Printed picking lists, re-checked against new orders | A picking list generated automatically and updated whenever demand exceeds the initial forecast |
| Emails, text messages, spreadsheets and workflow tools for internal supplies | One request-and-approval flow for internal items, with purchase and price history |
What was not replaced. The ecommerce platform stayed as the customer-facing order channel. WhatsApp stayed as the supplier channel. The sales projection stayed as an external input. Pre-existing databases stayed and were being connected. The system sits between the order channel and the warehouse floor; it does not replace either end.
The purchase and picking cycle, end to end
- 1Customer orders arriveAutomated
They come in from the ecommerce platform.
- 2The day's purchase list is assembledAutomated
Current stock, orders, sales projections and supplier delivery estimates are combined into one list, sorted by supplier.
- 3The buyer reviews and sendsPerson
The buyer checks the list and sends each supplier the generated WhatsApp message.
- 4The supplier confirms and deliversExternal
Outside the system, on the channel the suppliers already use.
- 5The order is marked Placed, then ReceivedPerson marks, system updates
Placed creates the stock estimate; Received updates the stock number.
- 6The picking list is generatedAutomated
Built from orders and stock, and updated when demand exceeds the forecast.
- 7The floor registers what it seesPerson
Warehouse staff separate produce and register quantity changes, spoilage or returns from their phones as they go.
- 8The updated number feeds tomorrowAutomated
The current stock number goes into the next day's purchase list.
The hard links are 5 and 7. A system cannot see that a crate arrived short or that a box spoiled overnight; a person has to say so. The design accepts that and makes saying so as cheap as possible: a checkbox on a phone, at the moment it is noticed, instead of a paper note carried to a computer hours later. Everything automatic in the chain depends on those two human links staying easy.
Every change, with the basis beside it
| Indicator | Result | Where it comes from |
|---|---|---|
| Purchase list preparation | From a daily hand-built spreadsheet to an automatically generated list sorted by supplier | Published case, "Before" and "After" sections |
| Supplier ordering | From orders typed one by one to one generated message per supplier | Published case; the team's own description |
| Stock data latency | From periodic base-computer updates and end-of-day counting to registration on the floor as it happens | Published case; no measured latency figure exists |
| Picking list | From a printed list re-checked by hand to a live list that updates when demand exceeds forecast | Published case |
| Internal supplies | From scattered emails, messages, spreadsheets and tools to one request-and-approval flow with price history | Procurement manager's account in the published case |
No time or cost figure is claimed here because none was measured. The published case describes what was replaced and how, and quotes the team on the effect. It does not report hours saved, headcount avoided or error rates before and after. A reader who wants those numbers should treat their absence as information, not as an oversight in this write-up.
"Real-time" means registered at the moment of the event, by the person who saw it. It does not mean sensors or automatic detection. The stock number is as current as the last checkbox someone marked on the floor. That is a large improvement over end-of-day counting; it is not a claim of zero lag.
The company-scale figures are not results. 500+ restaurants and USD 100,000+ MRR describe the size of the operation the system was built for. Nothing in the source attributes either figure to the system, and this case does not either.
The loss rate the company stated to the press is not used as a result. In 2021 the co-founder told the business press that product loss at the company did not exceed 2%, against about 30% across the fresh-produce chain. The figure is self-reported, predates this case and is not attributable to the system described here. It belongs in the industry context section, not in the results.
What this case does not measure
Worth naming, because it is usually what gets inflated.
Every description of the before and after comes from the company's team as published. No process was independently timed or observed.
The case does not report cost per order, hours per purchase cycle, staff on the warehouse floor, or waste rates before and after. Those are the numbers a buyer would most want, and they are not here.
The case was published in April 2022. The company's size, catalogue and processes have changed since; in 2025 it merged with another platform. Whether the system described here runs unchanged inside the merged group is not known to us.
The original case includes a quote about developers building fast on the platform. Jestor now builds and maintains the system on the customer's behalf, so that quote describes a working model the company no longer sells and is not used as evidence here.
At the time of writing, the company was connecting the system to its ecommerce platform's stock numbers and to older databases. The case describes intent, not a completed integration.
The restaurant count and MRR appear in the case header without a measurement date. They are treated here as "at the time of the case" and nothing more precise.
The original case attributes a quote to an IT specialist whose printed surname does not match the name of the photo file. The quote was omitted for another reason (see above), and the name is not used.
Produce loses more than anything else in the chain, and the loss is rising
| Indicator | Number | Source |
|---|---|---|
| Share of fruit and vegetables lost between harvest and retail, globally | 25.4% in 2023, up from 23.2% in 2015; the highest of any commodity group | FAO, SDG indicator 12.3.1 data portal, updated June 2026 |
| Share of all food lost between harvest and retail, globally | 13.2% | FAO Food Loss and Waste Database, citing UNEP 2024 figures |
| Share of food wasted at retail, food service and household level, globally | 19% | UNEP Food Waste Index Report 2024, as cited by FAO |
| Estimated value of food lost before retail, globally | About USD 400 billion per year | FAO Food Loss and Waste Database, undated on the page |
FAO's own index puts fruit and vegetable loss above every other commodity group and moving in the wrong direction over eight years. The reason FAO gives is the one this case is about: high perishability and handling requirements. A distributor whose stock number lags reality by a day is buying and picking against a picture that perishable goods have already changed.
The 13.2% figure covers everything from farm to the retail door, which is exactly the stretch this company operates. Some of that loss is physical: bruising, heat, time. Some of it is informational: ordering more than will sell because the number that said how much was on hand was already wrong. This system addresses the second kind.
"One third of all food is wasted" traces to a 2011 FAO estimate that the organization has since replaced with the two separate indices above. It remains everywhere in industry material. Anyone building a business case on food loss should use the current index for their stage of the chain, not the 2011 headline.
The system is built to fit, and responsibility for it stays with us
This company's old process was not badly designed. It was a spreadsheet, a messaging app and a printer, doing a job they were never built for, and doing it well enough until the catalogue grew. The question a bespoke system has to answer is what happens in year two: a warehouse app that nobody can change becomes 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 flow, a new automation 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 buyers, warehouse staff, drivers and office staff all touch the same operation.
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 process descriptions and all four quotes come from the case study Jestor published in April 2022, written from interviews with the company's team. They are the team's own account and were not audited. One quote from the original case was omitted because it describes a working model Jestor no longer offers.
The restaurant count, MRR figure, founding year and 2025 merger come from the company's own published material and from business press coverage of the merger. The restaurant count and MRR are as of the case's publication and may not reflect the company today.
FAO SDG indicator 12.3.1 data portal (updated June 2026); FAO Food Loss and Waste Database (page dated February 2025), citing the UNEP Food Waste Index Report 2024.
No time saved, cost saved, headcount, error rate or waste rate is claimed, because none was measured in the source. The company has stated a product loss rate to the press; it predates this case, is self-reported, and is not attributable to this system, so it is not used here.