OrderTiffin
All kitchen guidesOrders & customers

How to take tiffin orders on WhatsApp without losing details

A usable order-message template and a daily routine for confirmations, payments, meal changes and delivery lists.

Before you start

A WhatsApp message is a request until the kitchen accepts it. Keep the confirmed order and payment status in a record you can use while packing.

In this guide

Give customers one clear way to order

Taking tiffin orders on WhatsApp works better when the customer does not have to assemble the details from several conversations. Start with one current menu link, a clear order cutoff and a defined delivery area. Put those details where a new customer can read them before asking for a meal.

Your first message can explain the next step: review the menu, choose lunch or dinner, select the plan and send the requested information. Keep that instruction consistent across a printed leaflet, your social profile and your kitchen website. If one channel advertises a different price or an old menu, the order will need extra clarification before it can be accepted.

Use an order-message template

Ask for the fields that affect cooking, payment and delivery. A clear template is easier to check than a long free-form conversation. Keep the customer’s information in the order conversation rather than asking them to post their address in a public group. Only collect details you need to handle the service.

Hi [Kitchen name],
I would like to request a tiffin.

Meal: Lunch / Dinner / Both
Plan: [number of meals or service days]
Start date: [day, month, year]
Quantity: [boxes per meal]
Name: [customer name]
Phone: [contact number]
Delivery address: [building, street, area]
Delivery notes: [gate or reception details]
Food request: [only if supported]

Please confirm availability, delivery charges and the total amount.

State what quantity means. A plan for lunch and dinner with a quantity of two can mean two boxes at each meal, not two boxes spread across the day. Confirm that interpretation before giving a total. Use full dates rather than only tomorrow when a conversation may be answered after midnight or forwarded to another person.

Confirm availability and the full order

Check that the requested start date is a service day, the address is within your delivery area and the kitchen has capacity. Review any custom food request before accepting it. Then send a short confirmation containing the meal, plan unit, number of boxes, starting date, delivery window and total amount.

Request checked: [reference]
Meal and quantity: [details]
Plan entitlement: [details]
Starts: [date]
Delivery window: [time]
Delivery fee: ₹[amount or included]
Total: ₹[amount]
Payment arrangement: [details]
Status: [awaiting confirmation / accepted]

Please confirm these details are correct.

Do not treat a read receipt as agreement to a changed price or menu. If the customer asks a question or changes the address, update the order record and repeat the affected details. Keep accepted requests distinct from enquiries that have not reached a clear agreement.

Track payment separately from order status

A request can be accepted but still await payment under your arrangement, and a customer may send payment information before you have accepted the meal. Record those states separately. Check receipt in your own payment records before marking an amount paid; a message or screenshot alone is not the same as verifying that you received it.

Use a stable order reference where possible, and record the amount, payment date, relevant transaction reference and any balance. Avoid collecting unnecessary banking information. Keep the history when correcting a mistake so that you can explain how the balance changed. Our pricing guide can help you define a clear total before payment is discussed.

Make a daily packing list from accepted orders

At the cutoff, turn the accepted orders into a list the kitchen can actually pack from. Separate lunch and dinner. Count boxes, standard portions, supported custom requests and paid extras. Check the total against the meals you plan to cook. A customer’s name appearing somewhere in a chat is not enough to establish that today’s box is required.

An example packing-list structure
ReferenceMeal / boxesFood noteDelivery pointStatus
Example ALunch / 1Extra roti confirmedOffice receptionAccepted
Example BDinner / 2Standard mealBuilding gateAccepted
Example CLunch / 1Request still being checkedAddress not confirmedPending: exclude from packing

The rows are fictional examples. Keep the real list private and give each person only the information needed for their task. A packing label may need the reference and food note; the rider may need the address and contact number. Neither needs an exported history of every customer’s conversation.

Write recurring-plan changes into the record

For regular plans, track the remaining entitlement and the next expected service meal. Decide how far in advance a customer must request a pause and publish that rule before accepting the plan. Make the unit clear: remaining meals, service days and calendar days are not interchangeable.

When a customer asks to skip, acknowledge whether the change has been accepted and which dates it affects. Update the record before the next packing list is made. If your plan permits carry-forward meals, state the resulting entitlement; if it does not, communicate the applicable policy clearly. Do not rely on remembering a message while preparing the next morning’s food.

Have a short routine for delivery problems

Agree on a reception or handover point when delivering to offices, hostels or buildings with controlled entry. Ask for directions that help the delivery rather than collecting unrelated personal information. If someone else will receive a group order, confirm that arrangement with the customer.

If a delivery is delayed or an item is missing, check the order and contact the affected customer promptly. Record the resolution, such as a replacement or an agreed adjustment, instead of leaving it in an unlabelled voice note. A repeat problem should feed back into the route, portion standard or packing checklist rather than producing the same apology every day.

Keep service messages useful and permission-based

Order confirmations and delivery updates should be easy to distinguish from promotional messages. Ask before adding customers to a marketing group or sending recurring offers. A group can reveal participants’ contact details to others, so do not use one as a public order book containing names, addresses and payment references.

Use short, descriptive service messages: what changed, which order it affects and what the customer needs to do. Respect requests to stop promotional updates. If someone else helps answer your kitchen’s messages, define what they can access and how order changes are recorded. Keep account access and customer records under the kitchen owner’s control.

Let the website collect choices and WhatsApp carry the conversation

An OrderTiffin website lets customers browse a weekly menu, select meal plans and delivery options, and review an order request before continuing to WhatsApp. The prepared message makes the request easier to read. The kitchen still confirms availability and fulfils the order; the website is not a promise that every request has been accepted.

Use the owner dashboard to keep the menu, prices, orders and active-plan records organised as your process allows. Do not advertise automatic WhatsApp replies, automatic payment verification or guaranteed delivery just because a website link opens a chat. Explore the sample customer flow before sharing your real kitchen page.

Plan who answers messages during the busy hour

A kitchen owner may be cooking or dispatching when new messages arrive. Decide in advance whether a helper can acknowledge an enquiry, confirm an order or approve a change. These are different responsibilities. A short acknowledgement can say when the customer should expect a reply without promising a meal that has not been checked.

Give the person answering a current menu, service-area list, cutoff and clear limits on what they can promise. If a request needs the owner’s decision, mark it pending in the shared operating record. Avoid having two people independently accept the same change or quote different totals in the same conversation.

For a change after confirmation, record the order reference, the original detail, the requested replacement, whether it was accepted and which packing list needs updating. A customer moving an address can affect both the delivery fee and the route. Reconfirm those effects before treating the change as complete.

Test the handover with a fictional enquiry before a busy service. Can the helper find the current price, identify an address outside the route and explain the difference between a request and an accepted order? Fix the missing instruction and keep account access limited to the people who need it. This gives the customer a consistent answer even when the owner cannot immediately pick up the phone.

Close the day with a short check

  • Reconcile accepted orders with the meals packed and delivered.
  • Check payments received and unresolved balances.
  • Record any accepted pause, address change or service adjustment.
  • Resolve pending requests before promising the next meal.
  • Update tomorrow’s menu, availability and cutoff information.
  • Keep the packing and delivery list private and accurate.

A reliable routine does not need to begin with a complicated system. Start with clear fields, explicit confirmations and one record that the kitchen trusts. Combine the weekly menu plan and home-business launch checklist with this process, then create your ordering page when your kitchen is ready to receive requests.

Official resources

Published by OrderTiffin

Practical guides for independent tiffin kitchens, with labelled examples and links to official resources where needed. About the platform · Suggest a correction

Your menu. Your own kitchen page.

See the website and ordering tools before you get started.

See how OrderTiffin works