Your store already knows when something happened. An order landed at 2 am. A payment failed. A basket worth nine hundred dollars came from a customer who has never bought before. All of it is sitting in the WooCommerce orders table, waiting for somebody to log in and look.
Email was supposed to solve this. It does not. Order emails land in a promotions tab, admin notifications go to an address nobody monitors on weekends, and the one message that actually needed a human lands between a plugin update notice and a newsletter.
WhatsApp automation for WooCommerce moves those signals to the one app people actually open. A new order, a failed payment, an unpaid basket, a delivery, or a suspicious high-value purchase can each send a message on its own, with the order details already inside it.
WhatsApp automation for WooCommerce means a store event sends a WhatsApp message automatically through the WhatsApp Business Platform. In Bit Flows, you pick a WooCommerce trigger, capture real order data, add logic such as a Condition, Delay, or AI Agent, then connect the WhatsApp action and map order fields into the message.
The seven flows below were built in the Bit Flows canvas. The basic setup is:
Every trigger, action, and tool named here exists in the plugin. There is also a section on the practical limits of these flows, including message costs, timing limits, and the capture problems that break most workflows.
WhatsApp automation for WooCommerce mainly covers two use cases: internal alerts to your team and transactional messages to customers.
The tools that handle this usually fall into two groups. Dedicated WooCommerce WhatsApp plugins map store events directly to messages. Workflow builders such as Bit Flows let you add conditions, delays, data lookups, AI, and branching before a message is sent.
| Trekker | Logica in het midden | Wat landt op WhatsApp |
| Bij nieuwe order aanmaken | None | New order details to your team |
| Bestelstatus ingesteld op mislukt | Condition on order total | High-value payment failure alert |
| Bestelstatus ingesteld op In behandeling | None | Order confirmation to the customer |
| Bestelstatus ingesteld op In afwachting | Delay, Get Order, Condition | Unpaid order reminder, only if still unpaid |
| Bij nieuwe order aanmaken | Get Customer Total Spent, Condition | VIP order alert to your team |
| Bestelstatus ingesteld op Voltooid | Vertraging | Review request after delivery |
| Bij nieuwe order aanmaken | Condition, AI Agent, Conditions | Hold alert to your team or confirmation to the customer |
Every flow below ends with a WhatsApp action, so build the connection once and reuse it in the rest. You need four things ready: Bit Flows geïnstalleerd, a WooCommerce store, a WhatsApp Business app, and a real test order. On that last one, place an actual order rather than editing one in the admin. A real order tells you whether billing_phone is in the captured response and what format it arrived in, which dummy data will not.
Open Bit Flows → Flows, maak een flow aan of open er een, klik op het plus-pictogram, zoek naar WhatsApp en kies ‘Bericht verzenden’. Haal vervolgens drie waarden op uit je WhatsApp Business-app: de Business Account-ID, de telefoonnummer-ID en een toegangstoken.
Most first attempts die on the token. The one Meta gives you during setup is temporary. It lasts 24 hours, then the integration stops.
Stel eerst een permanent token in. Maak een Bedrijfsportfolio, voeg een Systeemgebruiker toe met de rol Admin, wijs uw app toe aan die gebruiker en genereer vervolgens een token waarbij whatsapp_business_messaging en whatsapp_business_management zijn aangevinkt. De WhatsApp-actiegids heeft de huidige schermen als Meta iets heeft verplaatst.
One more thing before flows 3, 4, and 6. These flows message customers. If there is no open 24-hour customer service window, you need an approved Meta message template instead of a free-form message. Get those templates approved before building the customer-facing flows.
These seven ran on a live store with real orders behind them. I work at Bit Apps, which makes Bit Flows, and I have said where it falls short.
The simplest flow in this list is also the one that saves you the most time later. Two nodes, nothing between them. If your WhatsApp credentials are wrong, you find out immediately instead of tearing apart a five-node workflow wondering which step broke.
Pick WooCommerce as your trigger, choose On New Order Create, hit Listen Response, and buy something from your own store. Then type your team’s number straight into the recipient field. Then type your team’s number directly into the recipient field. Because the recipient is fixed and no customer data needs to be mapped, this flow can go live as soon as the WhatsApp connection works.
A failed payment is revenue that almost arrived. Someone got as far as entering payment details and something broke on the way through. A fast alert gives your team a chance to investigate or follow up while the failed order is still recent.
Set WooCommerce as the trigger and pick Bestelstatus ingesteld op mislukt. Notice what you did not have to do there. Bit Flows gives each order status its own trigger, so Pending, Failed, On-hold, Processing, Completed, Refunded and Cancelled are seven separate starting points rather than one generic status change you then filter down. The event has already narrowed itself.
So the Voorwaarde here is doing a different job. Name the branch High Value Failure and set order total greater than 100. That threshold is what stops a nine dollar failure reaching someone’s phone at midnight, and the unmatched orders drop quietly into No Condition Matched, which stays unconnected.
The captured response is worth a look while you are in there. WooCommerce returns more than the basics, including the regel_items array. Depending on your WooCommerce setup, you may also see _wc_order_attribution fields such as device type, traffic source, and session entry page.
This is the first flow that talks to a customer rather than your team, and that changes which action you use. Send Message becomes Send Template Message.
The reason comes from Meta, not Bit Flows. Outside an open 24-hour customer service window, a business-initiated WhatsApp message must use an approved template. Bit Flows can then map the order data into that template when the workflow runs.
Before testing, confirm that the template name and language code in Bit Flows match the approved template in WhatsApp Manager. If you later edit or replace the template in Meta, reopen the Bit Flows action and verify the configuration again before sending.
A customer places an order that remains unpaid, pays shortly afterward, then gets a message telling them the order is still unpaid. A basic delayed reminder can make exactly that mistake because it sends from the original order state.
Five nodes solve it. A Vertraging holds the flow for sixty minutes. Get Order (Single) then pulls the order again using the ID from the trigger, and that second look is the entire trick. You are no longer working from an hour-old snapshot. You are working from the order as it exists right now.
A Condition reads the status off that fresh copy and only continues if it still says pending. Everyone who paid during the hour drops into No Condition Matched, along with anyone who cancelled, and none of them hear from you.
Two things to check on your own store. WooCommerce usually creates orders in pending, so this trigger and On New Order Create may both fire on the same order, which matters if flow 1 is already running. And status values live internally as wc-pending while often surfacing as pending, so use whatever your capture actually shows.
Get Customer Total Spent does look backwards, and in this build it lives inside the Voorwaarden node rather than sitting on the canvas as its own step. The branch evaluates lifetime value directly, so anything above your threshold continues to WhatsApp and everything else stops at No Condition Matched.
That is the line between a workflow builder and a notification plugin. A plugin reads the event it was handed. This reaches for data the event never carried.
One thing to sort out first. Guest checkout creates no customer account, so there is no ID to look up and the branch has nothing to evaluate. If you allow guest orders, either check the customer ID exists before the lookup runs, or use Get Order (By Billing Email Address) and count the history that comes back instead.
A review request that arrives the moment an order is marked Completed asks someone to rate a product still sealed in its box. Set the Delay to seven days and the same message reaches them once they have actually used the thing.
Three nodes, and the shortest flow in this list to build. It is also the most expensive per send. Every template in this article costs money once it goes out to a customer, but marketing templates run several times the utility rate, and a review request will almost certainly be categorised as marketing. Check Meta’s current rates before you scale it. Here you can also add a Condition on order total that keeps you from spending a marketing template chasing feedback on a five-dollar accessory.
The six flows above all react to something that already happened. This one intervenes before it does. The trigger is On New Order Create again, but the first Condition is doing gatekeeping rather than segmentation. Order total above 500 and the order goes to the agent. Everything below it stops there, because every agent run costs tokens and most orders do not need judgement.
What arrives at the AI-agent is an order and four attachments: an OpenAI chat model, Simple Memory, WhatsApp Send Message, and MySQL Execute Query. The MySQL tool is what separates this from a rules engine. A Condition can tell you the order is worth nine hundred dollars. It cannot tell you whether nine hundred dollars is ordinary for this buyer or four times anything they have ever spent. The agent can go and look.
The prompt does three jobs. It fences the tools, it fences the database, and it ends with a word the next node can branch on.
NL 
EN 
DE 
ES 
IT 
PT 
JA Decide whether a human should check this WooCommerce order before it ships.
Use only the order data and what your tools return. Do not invent details.
Do not contact the customer.
MySQL tool: read the customer's order history. Read only, never write.
WhatsApp tool: use once to alert the internal team, and only on HOLD.
First line of your response: HOLD or CLEAR, nothing else.
Second line: one sentence under 25 words explaining why.
HOLD when billing and shipping countries differ, payment settles manually,
the customer note asks for an unusual delivery, or the total is far above
this customer's usual order.
Otherwise CLEAR.A second Conditions node reads that first line. Hold routes to Update Order Status set to On hold. Clear routes to the confirmation template from flow 3. Match with Starts with or Contains, never Equal to, because the explanation sentence follows the keyword on the next line. No such operator in your build? Add a JSON Parser after the agent and ask for JSON.
Then test it properly. A tool attached to an agent is available to the model, not compulsory for it. The model can hold an order and quietly skip the alert, which is the one failure mode that costs you a sale nobody knows about. Place a deliberate HOLD order and watch for the message. If it misses, move WhatsApp off the agent and onto the hold branch as a plain action, where it fires every time.
One more thing, and it is a database setting rather than a Bit Flows one. Give the MySQL connection a read-only user. The prompt tells the model not to write. A prompt is an instruction, not a permission.
Most broken flows are broken captures. A trigger response saved with test data, or saved before you added a field, and the message goes out empty. Recapture with a real order, then reopen the action so the field appears.
De Delay tool counts forward from the trigger. It cannot wait until Friday at 9am. Fine for reminders, useless for anything scheduled.
Meta bills per template message. Your model bills per token. The plugin itself is flat, so the only flows that scale in cost are the ones sending templates and the ones running an agent. Price those two per order before volume arrives.
When something does fail, Logs shows input and output per node. Read backwards. The node that errored is rarely the node that caused it.
The dedicated plugins ship faster. That is a real advantage, and if all you need is an order confirmation going out on status change, take it.
What you get here instead is room to add a decision. A condition on order value, a lookup mid flow, a wait before the message goes out, an agent that checks history before anything ships. Those are the things that stop being possible once the tool only maps statuses to templates.
So start with an internal notification. No Meta approval, no customer risk, and the next order on your store tells you whether the wiring holds. Get the template approval moving the same day, because that queue is the slowest part of every build here.
After that it is habits. Capture with real order data, never test data. Keep fixed rules in Conditions and save the agent for genuine judgement calls. Read the Logs before you switch something on, not after a customer tells you the message never came.
De WooCommerce trigger guide walks through capture, and the Bit Flows users guide has node level setup for everything covered above.
Yes, Bit Flows can trigger a WhatsApp action from any of 22 WooCommerce triggers, including new orders, each order status, product changes, and cart events, without code.
Yes, automated messages require the WhatsApp Business Platform with a Business Account ID, Phone Number ID, and access token, since the standard WhatsApp Business app cannot be automated.
Meta issues a temporary access token that expires after 24 hours, so create a permanent token through a Business Portfolio and System User before relying on the integration.
Yes, free-form messages only send inside a 24-hour window opened by the customer, so any order confirmation or reminder sent outside it needs a pre-approved Meta template.
Bit Flows exposes separate triggers for Pending, Failed, On-hold, Processing, Completed, Refunded, and Cancelled, plus a generic Order Status Changed trigger.
No, there is no cart abandonment trigger, so use the unpaid order reminder in flow 4 or choose a dedicated abandoned cart plugin if that is your main requirement.
Add Get Order (Single) after the Delay and a Condition checking the status is still pending, so the flow refetches the live order instead of trusting the original trigger data.
Yes, the Get Customer Total Spent action returns lifetime value mid-flow, so a Condition can route high-value customers to a different message than first-time buyers.
Guest orders have no customer account, so lifetime value lookups return nothing and you need Get Order (By Billing Email Address) as a fallback for customer history.
Check the phone number format first, since WooCommerce stores whatever the customer typed and Meta expects E.164 with a country code.
Yes, the Update Order Status action sets any of the eight core WooCommerce statuses, so a workflow can hold a suspicious order rather than only reporting it.
WooCommerce is a free trigger, and WhatsApp is a free action, though Meta charges separately for template messages, and any AI model you connect bills its own tokens.
Place a real test order rather than editing one in admin, use Test Run on the action, then run the full flow and check the input and output of every node in Logs.
No, use Conditions for fixed rules like order totals and reserve the AI Agent for judgement calls such as deciding whether an order needs human review before fulfilment.
