How it works
This is the current ChefSathi flow. Regular customer orders now move through the storefront first, while WhatsApp remains the business entry point, notification channel, and operator control surface.
Customer path
Operating layer
Step 1
ChefSathi still starts from the business number the kitchen already owns. A customer asks for the menu, repeat tiffins, or today’s order link on WhatsApp. That keeps discovery, trust, and repeat demand on the business’s own channel instead of moving the customer into a marketplace relationship.
Customer says
Menu for tonight? Need 2 paneer rolls and 1 cold coffee.
ChefSathi replies
Sends the storefront link, not a messy free-form ordering thread.
Step 2
For normal food ordering, the storefront is now the main capture surface. Customers browse the real menu, choose accompaniments, review the total, and place the order directly. WhatsApp remains the entry channel and the follow-up channel, but it no longer has to carry the whole regular-order composition burden.
Customer experience
Open storefront → choose items → review order → place order.
Why it matters
Fewer mistakes, cleaner item capture, better payment posture, and a far more usable mobile flow.
Step 3
ChefSathi does not hardcode one confirmation model. A kitchen can keep manual confirmation, auto-confirm instantly, or require payment before confirmation. The storefront follows the tenant’s operating policy instead of forcing every business into the same checkout behavior.
Possible policies
Manual confirm, auto-confirm, prepaid-only, pay later, or pay after confirmation.
Product behavior
CTA, payment path, and messaging adapt to the merchant’s chosen policy.
Step 4
Not every order should depend on the customer storefront. Owners and operators can still step in through assist mode, create orders for a customer, or use catalog items that are not part of today’s public menu. That keeps the business flexible instead of making the storefront the only path.
When this matters
Phone order, repeat customer, custom request, or a catalog item not published for customers today.
Safe fallback
Operator opens assist mode, reviews the order, confirms it, and ChefSathi still keeps the ticket, prep, ledger, and customer messaging aligned.
Step 5
Storefront ordering is only useful if operations stay coherent afterwards. ChefSathi keeps tickets, prep detail, payment status, dues, invoice state, and collections tied to the same order flow. That matters for daily kitchens, recurring tiffins, and larger catering-heavy businesses alike.
Owner concern
Was this paid? What still needs prep? Which customer still owes money?
ChefSathi view
Ledger-backed payment visibility, modifier-aware prep detail, and owner-first summaries instead of chat memory.
Step 6
The storefront does not remove the need for operational discipline. Meta status, catalog review, payment readiness, validation, and launch mode still matter. New tenants should still move through shadow, operator-confirmation, and only then into fuller automation when the business is genuinely ready.
Launch modes
Shadow → Operator confirmation → Fully automated
Why it matters
The system can be useful early without pretending the tenant is ready for full automation on day one.
Step 1
WhatsApp entry stays intact
Step 2
Storefront captures regular orders
Step 3
Checkout follows tenant policy
Step 4
Operator fallback stays available
Step 5
Prep and finance remain connected
Cloud kitchens
Best for operators who already get demand on WhatsApp but need a cleaner ordering surface, clearer checkout rules, and less chaos between order capture and kitchen execution.
Tiffins
Useful where repeat customers, dues, weekly plans, and operator-led exceptions need more structure than a chat thread can safely handle.
Catering and manual fallback
Helpful when the order is too custom, too large, or too unusual for customer self-serve flow alone. The storefront helps, but operator control still stays part of the system.