Subscriber sign-in
Each customer sees their own plan, next delivery and invoices, and nobody else's.
A customer portal website for meal preparation companies gives subscribers and program clients a login to manage plans, pause deliveries, update allergies and download invoices. SIZ Group builds that portal so account changes land before the cutoff without a customer emailing the kitchen.
Meal subscriptions run on a weekly cycle. A customer who wants to skip two weeks, change a plan size or add an allergy has to act before the cutoff. A basic account page often hides those controls, so requests pile up in email right before the deadline, when the kitchen is already prepping. The portal should answer the question a busy manager asks first: what can I change, and by when?
Corporate and clinic clients add another layer. An office manager may look after several employees' plans and need one invoice with a purchase order number, while each employee changes their own delivery address. Those roles need separate views, and the portal has to keep them apart. Program buyers also expect a single point of contact who can answer for every employee on the account, which the portal makes possible.
Most changes arrive by email or a direct message to a support address. The support person edits the subscription in the store platform, adds a note to the packing sheet and replies. Corrections often cross, so a customer who changed a plan on Friday may still receive the old size on Monday. Each time, a second person has to confirm the change, which doubles the work and still leaves room for error.
Program invoices are another drag. Clients ask for a monthly statement with purchase order numbers, and the owner builds it by hand from an export, which costs an afternoon every month that could go to menu work.
The first version should cover sign-in, pause and skip controls with the cutoff visible, allergy and delivery-note updates and invoice downloads. Those are the requests that fill the support inbox each week, so they earn their place first. Each item gets the same care in testing, so the first release works reliably before the team asks for more.
A referral dashboard, streak rewards and a mobile app can wait. They are pleasant additions, but none of them reduces the cutoff rush. A simple roll-out plan, with the support team trained on the portal before the first customers log in, makes the first week calmer for everyone.
Each customer sees their own plan, next delivery and invoices, and nobody else's.
Change a delivery or pause a plan up to the cutoff, with the deadline shown on screen.
Customers update dietary details and drop-off instructions, which flow to the packing sheet.
Program clients download statements with purchase order numbers and date ranges.
An office manager for a 30-person design studio signs in on Thursday morning. The dashboard lists the studio's active plans, the next cutoff and last month's invoice. She notices that one employee starts a diet change next week. Her change is saved with a name and a time, so the kitchen and the account team can see who made it and when.
She opens that employee's plan, edits the allergy note, moves the delivery to the studio's second floor and confirms before Friday's cutoff. The change reaches the packing sheet immediately, and she downloads the invoice with the purchase order number for accounts.
A portal stores names, addresses, dietary data and payment history, so collect only what the service needs and limit who sees allergy notes. Staff accounts should show only the records their role requires. Staff who only pack meals see the allergy note but not the billing history, which keeps the roles clear.
Card details stay with a hosted payment provider. Cold holding and labeling rules still govern what the kitchen does, so the portal must not promise anything the label or the kitchen process cannot back up.
Treat health language with care. A notice that a plan treats a condition needs review before it appears anywhere in the portal.
The most common error is a portal that shows the menu but hides the cutoff. Customers then change plans after the kitchen has committed ingredients, and the owner absorbs the waste.
The second is rebuilding the store platform's subscription controls. Use the platform as the source of truth and let the portal read from it. The third is launching without a rule for who answers when a request does not fit the policy. The worst version of this is a portal that the support team still has to override by hand every week.
Figures run between $300 and $2,200, and a portal with subscriber accounts, program views and invoices sits in the upper half of that band. Account types, the depth of platform integration and invoice formats set the figure. The number goes into a written proposal after the first call.
We connect to the subscription platform your team already runs, such as Shopify with a subscription app or WooCommerce with a subscription plugin, and read plan data from it. If the connection is limited, we agree which changes the portal makes and which stay in the platform.
Yes. A program administrator sees the employees on their account and can edit plans or delivery details within rules you set. Individual employees keep their own logins for personal changes.
The portal blocks the change and shows the next available delivery date. The customer can still message the kitchen, but the site makes clear the order is locked. That prevents late edits from wasting ingredients.
Password resets go through a secure email link, and staff never read passwords out over the phone. You can also enable a one-time sign-in code. We test both routes before launch.
Start with a call about your plans and client types, and we will confirm the terms in writing.