Meal prep site subscription: where people quit

A weekly meal plan is a recurring purchase, and most buyers know it. What they do not know is how the site handles the next box. The plan step lists meal counts and a price per meal, but says nothing about when the next delivery is locked in. The delivery day comes from a calendar that offers days the kitchen does not run. The skip button sits in an account area that a buyer cannot open before paying. A careful buyer stops here to find out how to leave, and the page gives no answer before the card form.

• Does the plan step say the plan repeats every week, before any card field?
• Is the deadline to skip or change the next delivery shown before payment?
• Does the delivery day picker offer only days the kitchen actually delivers?
• Can a buyer see the total for one week, not only the price per meal?
• Does the order summary name the plan, the start date and the next charge date?

A meal plan sign-up makes three promises: the meals each week, the price each week, and how to skip or leave. The first two usually sit near the top. The third often sits in the terms, or in an account menu that exists only after payment. Put the leaving rule where the buyer makes the decision. A short line under the plan name, such as repeats every week, skip before the cutoff, does more than a footer paragraph, because buyers read the plan name before anything else.

The order summary is the last place the rule can appear without a new page. Name the plan, the start date, the first charge date and the next charge date, in that order. A buyer who sees a start date two days away and a charge date that matches it can judge the commitment. A buyer who sees only the total for one box thinks they are buying one box.

The delivery day picker is the second source of drop-off. A calendar that offers every weekday in the postcode area is easy to set up, but this kitchen may cook and ship on two days only. The buyer picks a Wednesday, reaches the payment step, and learns the first delivery is the following Monday. Nothing errors. The buyer just feels misled, and that feeling is enough to close the tab.

To separate a plan problem from a calendar problem, pick a day you know is valid and one you know is not. Read the first charge date after each choice. If the calendar accepts a day the kitchen does not deliver, the calendar is wrong. If the first charge date does not match the delivery day, the summary is wrong. If the plan has no clear weekly rule at all, the plan step is the cause.

Send one simulated visitor to your plans page with this task: Start a weekly plan for one and reach the payment step. The visitor is an adult who wants cooked lunches delivered each week and compares plans on a phone. Leave the plan name out of the task so the visitor chooses the way a buyer would, and see which plan carries the weekly rule.

The test stops at the payment step. It cannot pay with a real card, and it cannot receive a code sent by text. A confirmation email does reach the visitor's inbox, so check that the email repeats the next charge date. Use a made-up name and address, and do not type a real customer's delivery details into a test. If the run ends earlier than payment, the step it ended on is the one to fix first.

The first run finds the step where the buyer stops. The fix moves the weekly rule and the skip deadline above the card form, and trims the calendar to real delivery days. Run the same visitor again to see whether they reach payment knowing the first charge date. Repeat the run after every new plan, every change to the cutoff, and before you send paid traffic to the plans page.