Subscription Businesses Selling Food: What You Can Actually Automate

Subscriptions are the nicest kind of revenue in e-commerce. Right up until the product has a best-before date and ships in from another continent.

This client sells an organic food product on subscription. The founder runs the shop with one part-time employee. The subscription rate was high, growth was fine, and the business still stalled, because two people could no longer keep up with operations.

We do not have permission to use names, so the case stays anonymous. The approach transfers, and that is the point.

Why subscriptions plus food is a special combination

A subscription built on shelf-stable goods is manageable. You know how many deliveries are coming and you reorder in time.

Food adds four complications:

Batch records are mandatory. With a food product you have to be able to prove which batch went to which customer. If a lot gets flagged, you need the list of affected orders in minutes, not days.

Shelf life is an expiry date on your capital. Stock you order too early loses value. Stock you order too late costs you subscribers, and a cancelled subscription rarely comes back.

Replenishment comes from abroad. Ocean freight, customs clearance, organic certificates and lab analysis. The time from placing an order to sellable stock ran to roughly three months here, with swings of several weeks.

Support means advice. With food, customers do not only ask about the parcel. They ask about preparation, dosage, storage and tolerance. Some of those questions touch on health, and that is where it gets delicate.

The starting point

As always, we measured before we built anything. Two weeks of tally marks, no tooling. The approach is described in How an automation project actually runs.

The rough distribution, per week, for both people combined:

That last line was the most annoying one. Every reschedule, pause or address change arrived as an email and was keyed into the subscription system by hand. Those are steps with no decision in them, and they ate a full day per week.

Building block 1: subscription changes in the customer's hands

We started with the piece that needs the least judgement.

Customers now manage their own subscription: move a delivery date, pause, change quantity, change address, change interval, cancel. Access through a link in every email, no password.

The important part was cancellation. The founder did not want to make it self-service at first, worried it would drive up churn. We built it anyway, with one step in between: anyone who wants to cancel first sees the alternatives, so a two-month pause or a longer interval.

The result after six months: the cancellation rate did not rise. Roughly one in three cancellation flows ended in a pause or a longer interval. The customer who wants to cancel at two in the morning cancels either way. Forcing him to write an email only annoys him on top.

The same logic applies to returns, see A returns portal instead of a ticket.

The time effect was immediate: of the 4 to 6 hours per week, around 30 minutes remained for edge cases.

Building block 2: recording batches automatically

The batch record used to be a spreadsheet that somebody updated every evening. Spreadsheets like that are incomplete exactly when you need them.

Here is how it works today: every incoming goods quantity gets a batch number with a best-before date. On dispatch, the system records which batch the warehouse actually picked and attaches that to the order.

Traceability is now a query. Which customers received batch X, in what period, with which order numbers. Answer in seconds.

Two details we underestimated:

• The warehouse does not always pick the oldest lot. We initially assumed the "oldest first" rule held and derived the batch from it. That was wrong in roughly one in twenty cases. Since then we only take the warehouse's own confirmation, never our own assumption.
• Mixes of two batches happen. When a lot runs low, an order sometimes contains both. The data structure has to allow several batches per line item, otherwise you fix it later under pressure.

How inventory data comes cleanly from one source is covered in Multichannel inventory management.

Building block 3: shelf life as a control variable

The second use of the same data was remaining shelf life.

A workflow calculates daily, for every batch, how many days it has left and how long the stock lasts at the current rate of sale. Comparing the two produces three signals:

• Green. Stock sells through before the best-before date.
• Yellow. It is getting tight. The workflow proposes an action, usually a bundle or an add-on for subscribers.
• Red. The remainder will not sell in time. Here the founder decides between donation and write-off.

The signals land in a morning message, together with the numbers behind them. Nobody opens a spreadsheet for it.

The effect: write-offs from expired stock dropped noticeably, because the yellow stage kicks in early enough. Before, this only surfaced when a lot was already close to its date.

Building block 4: replenishment with long lead times

With three months of lead time, a short-term alert does nothing for you. So the replenishment workflow here calculates differently from our own reorder setup.

On top of past sales, it factors in the known subscription deliveries of the coming months. That is the big advantage of a subscription business: a substantial part of future demand is already fixed. Only the new-customer share is an estimate.

The proposal contains quantity, target delivery window and the assumption behind it in one sentence. Approval is manual, because an order covering three months of demand is a money decision.

One point we had to correct: the first version used the supplier's promised lead time. The real one averaged a good three weeks longer, with outliers after customs inspections. Today we calculate with the measured value plus a buffer for certificate checks.

Building block 5: support on preparation

The biggest block of time was support, and this is where we were most cautious.

First we sorted several hundred past enquiries. Three groups came out:

• Subscription and shipping. Where is my parcel, when is the next delivery, how do I change something. Across our own brands, the parcel question alone accounts for around 40% of all enquiries, and it was similar here.
• Preparation and storage. Water temperature, amount per serving, how long it keeps after opening, what to store it in.
• Tolerance and health. Pregnancy, medication, intolerances.

The assistant answers the first group in full, because it knows order and subscription data. It answers the second from a curated knowledge base that the founder wrote himself.

It does not answer the third group. Those go straight to a human, with a note to the customer that somebody will get in touch personally. Health claims are legally risky and, in case of doubt, harmful. We set that boundary before the first line of code.

Across our own brands, automation answers around 65% of enquiries. Here the share is lower, because the third group is excluded entirely. The workload still fell from 12 to 15 hours to about 4 hours per week. How a setup like this works in general is in the guide to customer service automation.

What went wrong

Three things did not go to plan. Two of them we rolled back.

The assistant invented knowledge. During testing it produced a preparation recommendation that appeared nowhere. It was plausible and wrong. The cause: we had allowed it to infer from general product copy. Today it answers exclusively from the knowledge base, and when there is nothing there, it says so and hands over. Why this comes up in every project is covered in How to avoid AI hallucinations.

Automatic substitutes for sold-out varieties. We had built in an automatic swap to a similar variety when one was unavailable. With food that is a bad idea. Some customers buy exactly one variety for a specific reason. Today the system asks before swapping, and if no answer comes, it postpones the delivery.

Too many messages around each delivery. We had an announcement, a dispatch notice, a delivery notice and a follow-up after that. Four emails for a process that repeats every month. In a subscription that adds up to advertising pressure. Today it is two messages per delivery.

The result, in rough numbers

I am not naming revenue figures, that is the client's business. What belongs to the approach is measurable:

• Weekly operational workload for both people fell from the order of 23 to 30 hours to 7 to 9 hours.
• The batch record went from a daily task to a query.
• Write-offs from expired stock dropped noticeably, without anyone checking dates every day.
• The cancellation rate stayed stable despite self-service, and part of the cancellations turned into pauses.

The most important effect for the founder: he can launch a new variety without operations tipping over.

Limits that remain

• Quality control stays with a human. Colour, smell, lab report. No automation decides whether a lot goes on sale.
• Supplier contact stays personal. With three months of lead time and a variable harvest, a conversation is worth more than any order email.
• Health questions stay manual. That boundary is not going to move.
• A subscription business under roughly 200 active subscriptions does not need any of this yet. Until then a subscription tool and a tidy inbox will do.

Conclusion

A food subscription can be automated a long way, provided you get the order right. First the steps with no decision in them, so subscription changes. Then the data foundation of batches and shelf life, because everything else builds on it. Then replenishment, which benefits from known subscription deliveries. Support last, with a clear boundary around health questions.

What does not work: judging quality, managing suppliers, advising on health. Leave those three with a human and you can hand over the rest with a clear conscience.

If you run a subscription with perishable goods and you are hitting your operational ceiling, drop us a line at Flowhouse. We will take a look, and we will also tell you if your volume does not justify the effort yet.