Process your orders from a WhatsApp chat
Ask, choose the scope, confirm. The run that starts is the same one the Orders page starts, with the same permission check and the same refusals. Here is every step, and what stops a stray message becoming a live run.
Send process my orders. Robnu replies with your accounts as buttons, you pick one or all, it tells you how many orders are waiting, and you tap confirm. That enqueues the same run the Orders page enqueues, so it accepts, mints labels and closes the manifest exactly as it would on the web.
- It is a real run, not a notification. The chat calls the same enqueue the Process button on the Orders page calls.
- Four gates stand in front of it: a resolved sender, the orders:process permission, a four step confirmation, and the enqueue's own refusals.
- The assistant is not one of the gates and cannot start a run. Every branch in this path is code, so a model cannot decide to process your orders.
- A warehouse phone can ask for order counts and handover OTPs without being able to start a run. That is a permission, not a setting on the phone.
- Past the pickup cutoff it refuses rather than offering a yes anyway button, because a late mint is not a decision to take on a small screen.
Running order processing from a chat sounds casual, and the reason it is not is worth understanding before you use it. A message is easy to send by accident, easy to forward, and impossible to take back. So the path from a sentence in a chat to a live run that touches a marketplace is deliberately not one step, and the model that answers your questions has no part in it at all.
The four steps, as they appear on your phone
You send process my orders. Any close variant works, and you can say it as a voice note in Hindi, Gujarati or English rather than typing it.
Robnu replies with your marketplace accounts as tappable buttons, plus an option covering all of them. You tap the scope you want. It then tells you what it found, how many orders are waiting on that account right now, and offers a confirm button.
You tap confirm, and the run starts. From that point it is an ordinary Robnu run: it appears in your Jobs list, you can watch it from the chat, and it accepts, mints labels and closes the manifest in the same order it always does.
The whole sequence lives on a ten minute deadline. If you wander off mid-way and come back later, it has expired and you start again, which is the intended behaviour rather than an inconvenience: a half-finished confirmation should not be sitting live on your phone an hour after you put it down.
The four gates, and why a tap is not enough on its own
The first gate is identity. The number that sent the message is already a verified user on your account or an approved link, or the message never reaches this path at all. An unknown number gets a different route entirely.
The second is permission. Robnu reads the orders:process permission from that user's real roles, using the same source the Process button on the web checks. This is the gate that makes a shared warehouse phone safe: it can ask how many orders are pending and it can fetch a handover OTP, and it cannot start a run, because the person holding it does not have that permission. You change that by changing their role, not by changing anything about WhatsApp.
The third is the sequence itself. Ask, scope, pick, confirm, each step a tap on a message Robnu sent seconds earlier, held together by stored flow state. A forwarded message cannot walk a state machine. Neither can a stray sentence that happens to contain the word process.
The fourth is the enqueue. Robnu hands the run to the same function the web button hands it to, which already refuses when the processing hold is on, when a run is already active on that account, and when the day's pickup cutoff has passed. Those refusals were not rewritten for WhatsApp, which is the point: there is one set of rules about when a run may start, and the chat is subject to all of them.
The assistant cannot process your orders, deliberately
Robnu's WhatsApp assistant answers questions. It can tell you how many orders you had last week, what a deduction was for, why a return was rejected. It is read-only, and that is enforced rather than promised: it runs with an empty permission set.
Order processing does not go through it. The words route straight to the flow described above, and every branch in that flow is ordinary code. There is no point in the path where a model decides that you meant to process, or which account you meant, or that your confirmation was close enough.
This matters more than it sounds. A conversational system that can both chat and act will eventually act on something it misread, and on a marketplace that costs real money and real orders. Separating the two means the worst a misread question can do is give you an unhelpful answer.
What happens after you confirm
The run behaves exactly like one started from the Orders page, because it is one. It accepts the pending orders, requests labels, and closes the manifest, and it writes the same job history.
You can watch it from the chat rather than switching to the app. Robnu reports as it goes, and you can ask it where the run has got to in plain language at any point.
If something goes wrong, it says so in the chat rather than leaving you to discover it. A refusal from the marketplace, an account that needs a login, a run that found nothing to do: each of those comes back as a sentence rather than a silence.
Nothing about the result is WhatsApp-specific. The orders, the labels and the manifest are the same records, in the same places, as if you had never opened a chat.
The same orders, a different surface
A run started from a chat writes the records a run started from the screen writes
When to use the chat and when to use the screen
The chat wins when you are not at a desk. A pickup is coming, you are at the bench, and the question is simply whether today's orders are through. Tapping four buttons on a phone you already have open beats finding a laptop.
The screen wins when you need to see the run before you commit to it. The Orders page can show you which orders are in scope, let you select a subset, and tell you the day a late batch will actually ship. Three lines on a phone cannot do that, which is exactly why Robnu refuses a late run from the chat instead of asking you to decide blind.
Most sellers end up using both, and nothing is lost by switching: the chat and the screen are reading and writing the same thing.
The part of this Robnu does for you
Robnu reads your Amazon account and reconciles every settlement line back to the order that caused it, so a wrong deduction is visible the day it lands.
- Orders, returns, payouts and inventory synced
- Every settlement line matched to its order
- FBA units Amazon has not made good, listed
Where this sits in the rest of your Amazon operation
On Amazon, Robnu syncs your orders, returns, payouts and inventory, reconciles every settlement line back to the order that caused it, lists the FBA units Amazon's own ledger has not made good, flags a return that never came back before the SAFE-T window closes, and scans returns in at your dock. It reads your Amazon account rather than writing to it, so accepting orders and making labels run on AJIO and Meesho today. Related reading:
Sources & further reading
- Robnu, the product the behaviour described here is the product's own. The WhatsApp surface calls the same endpoints the screens do, with the same permissions, so anything you can check on a screen is the same fact. Read 2 November 2026.
- Meta, WhatsApp Business Platform onboarding Meta's own page. It states that the 24 hour customer service window applies to messages sent through the Cloud API, and that a window opens when a person messages a business already onboarded to it. That rule is why a reply can arrive as a template rather than as free text. Read 2 November 2026.
Not legal or tax advice. Amazon changes fees, windows and policies without notice, and the detailed style guides and account-health thresholds sit behind a Seller Central login, so any figure quoted here as convention is not Amazon-published. Check anything you plan to act on against your own Seller Central account first.
Questions sellers ask
Yes. The chat calls the same enqueue the Process button on the Orders page calls, so it accepts the pending orders, mints the labels and closes the manifest in the usual order, and the run appears in your Jobs list like any other. It is not a notification or a request for someone else to do it.
No. Four things have to line up: the number must already be a verified user on your account, that user must hold the orders:process permission, and the confirmation is a four step sequence of taps on messages Robnu sent seconds earlier, with a ten minute deadline. A forwarded message cannot walk that sequence.
No, and it is not a matter of instruction. The assistant is read-only and runs with an empty permission set. Order processing routes straight to a code path the model is not part of, so there is no step where it decides that you meant to process, or which account you meant.
Yes, and that is the usual setup. Order counts and handover OTPs need no special permission, while starting a run needs orders:process. Give the warehouse phone a role without it and that phone can ask anything and change nothing. You control it through the user's role, not through a WhatsApp setting.
It refuses and tells you why. It deliberately does not offer a yes anyway button, because a late mint changes the day your parcels ship and that decision needs the order list in front of you. Do it from the Orders page, which can show you the size of the run and the shipping day it moves to.
Yes. A voice note is turned into text and handed to the same router a typed message goes through, so a spoken request walks the identical confirmation buttons. Robnu reads English, Hindi and Gujarati, including Hindi and Gujarati typed in Roman letters.
Related seller guides
More on the operations, money and claims that decide whether a marketplace catalogue actually makes money.
Bulk Order Processing on Meesho: Ship Many Fast (2026)
How to process Meesho orders in bulk: bulk accept, bulk label, and bulk manifest as one workflow. The time math as volume grows, the error risk at scale, and how to keep the whole run correct.
Scan, label, manifest: the Meesho dispatch chain end to end
Dispatch is not four separate jobs, it is one chain: scan, label, pack, manifest, hand over. Run as a routine, it flows; broken up, it leaks time and triggers penalties. The full chain, in order, and where each link fails.
Download A Shipping Label From WhatsApp In One Message
Send an order number, an AWB or a time window and the label PDF arrives in the chat, built to your own label settings. This path only re-downloads a label you already own. It never accepts an order and never mints a new one.
Receive Returns By Sending Codes In A WhatsApp Chat
Say return scan, then send AWB after AWB as the parcels come off the van. Each one is marked received the moment it lands, and shows up everywhere a scan from the web dock does, reports included.
What A WhatsApp Chat Can And Cannot Change In Your Shop
Running a shop from a chat is only sensible if a chat cannot do something you did not intend. Here is the whole safety model: who the sender must be, which permission each action needs, and why the assistant cannot act at all.
Amazon pricing error made your listing inactive
A pricing error deactivates the listing silently and the stock is untouched. Which of the four pricing gates caught you, and the order to check them in.
Meesho Order Processing: From Order to Handover (2026)
Meesho order processing explained end to end: new order, accept, label and invoice, pack, ready to ship, manifest, courier pickup, delivery or RTO, and settlement. Learn each SLA stage and where sellers lose time and money.
Meesho manifest and handover mistakes that trigger penalties
Closing the manifest, the handover scan, and the gap between them is where Meesho penalties hide. The mistakes that trigger them, manifested-but-not-handed-over, missing scans, wrong counts, and how to close cleanly.