Ecommerce automation built for how people actually buy

The order confirmation problem nobody plans for

Where cash on delivery is the dominant payment method, an order is not a commitment. It is an expression of interest that costs the buyer nothing to abandon, and the store carries the shipping cost of every one that is refused at the door.

Confirming orders before dispatch is therefore not customer service, it is margin protection. Doing it by phone does not scale and doing it by email does not work, which is why it usually happens on WhatsApp and why it is worth automating properly.

• Confirmation on the channel the customer actually reads, with a real reply expected
• Address clarification before dispatch rather than a failed delivery afterwards
• Escalation to a person for high-value or repeatedly-refused orders
• A record of who confirms and who does not, because that is a segment worth knowing

Support that can read what customers send

Ecommerce support in these markets does not arrive as neatly typed English. It arrives as a voice note, a photograph of the item, or a screenshot of a bank transfer, often in a mix of two languages.

A support automation that only handles typed text will pass most of this straight to a person, which means it did not reduce anything. Handling images and voice is not a refinement here, it is the requirement.

The flows worth building, in order

Ranked by how quickly they pay for themselves rather than by how interesting they are.

• Order confirmation before dispatch, which directly reduces refused deliveries
• Where is my order, which is the single largest category of inbound support
• Delivery exception handling, so a failed attempt triggers contact rather than a return
• Returns and exchanges, with the policy applied consistently instead of case by case
• Reorder prompts timed to actual consumption rather than to a fixed calendar
• Abandoned checkout recovery on the channel the customer used, not only by email

Catalogue work, which is quietly the highest return

Product data is where most stores lose search visibility without noticing. Missing attributes, inconsistent naming across variants, and descriptions copied from a supplier that every competitor also copied.

This is well suited to automation because it is high volume and rule-bound. Generating distinct descriptions, filling missing attributes from images, and normalising naming across a catalogue is work no one has time to do by hand and no one regrets having done.

Scoping and cost, honestly

Store automation is usually a project, sometimes with a small monthly arrangement behind it for the flows that need adjusting whenever a sale is running. The project has an end: the flows built, the messages approved, the catalogue work done, the whole thing tested against real orders rather than sample ones.

What moves the number: order volume, because messaging and support automation carry per conversation charges on some channels and those charges are yours rather than the builder's; whether payment is card, bank transfer or cash on delivery, since the last two produce confirmation and reconciliation work a card-only store never sees; and how big the catalogue is, because description and data work scales with the number of products in a way that flow building does not.

What has to be known before quoting is what your order journey actually looks like, including how customers confirm payment today and how often an order changes after it is placed. A store where orders routinely get edited by message is a different build from one where they do not.

• Monthly order volume, and how much of it arrives through messaging
• Payment methods in use, since bank transfer and cash on delivery add reconciliation work
• Catalogue size, which drives description and data work directly
• How many post-purchase flows are in scope, and in how many languages

When doing it by hand is still cheaper

Below a few hundred orders a month, most of this is cheaper to do manually. Automation earns its cost on repetition, and a store that has not reached repetition is better served by fixing acquisition.

If stock data is unreliable, automating customer communication will confidently tell people things that are not true. Inventory accuracy comes first, because an automated wrong answer travels faster than a manual one.

Timing, ownership, and the orders a machine should not touch

Cash on delivery changes what automation is allowed to do, which is why this belongs on an ecommerce page rather than a generic one. Confirming an order, chasing a missing address, sending a tracking update and answering where is my parcel all run unattended. Cancelling an order, issuing a refund, overriding a price, and anything involving a payment screenshot that does not match the invoice waits for a person. A machine that cancels a genuine order because the customer replied late has cost you the sale and the customer.

Timing follows the catalogue. The audit takes the first week and usually finds the real problem is product data rather than flows. One flow is live inside a fortnight, normally order confirmation or abandoned checkout recovery, and the rest arrive across the second month once the data underneath is trustworthy.

Ibrahim owns build and workflows, and storefront work has the most finished public examples of anything Wobble does: a Shopify storefront built for Moni Honolulu, a theme migration and launch marketing for Oahu Golf Apparel, and a high-end store plus a full funnel engine for Artkaam in Karachi. Those are on the work page with what each produced.

Everything lives in your Shopify account, your payment provider and your own accounts on every connected tool, so ownership never sits with a supplier. If you leave, the flows keep running. Building it in-house is very reasonable on a small catalogue, because the app ecosystem covers most standard flows, and the point where outside help earns its cost is usually the catalogue work and the awkward local payment reality rather than the automation. Wobble stays answerable for the flows it installed.

Common questions

How do you reduce cash-on-delivery refusals?

By confirming the order before dispatch on a channel the customer actually reads, which in most South Asian markets means WhatsApp rather than email or a phone call. Clarifying the address before shipping rather than after a failed attempt, and escalating high-value or repeatedly-refused orders to a person, does most of the remaining work.

Can AI handle ecommerce support on WhatsApp?

Yes, and it has to handle more than text to be useful. Customers send voice notes, photographs of the item and screenshots of payments, frequently mixing two languages. A system that only reads typed English will escalate most of what it receives, which means it reduced nothing.

What ecommerce automation pays back fastest?

Order confirmation before dispatch where cash on delivery is common, because it directly reduces shipping cost on refused orders. After that, answering where is my order, which is usually the largest single category of inbound support, and handling delivery exceptions before they become returns.

Does AI-written product copy hurt search visibility?

Copying a supplier's description hurts far more, because every competitor has the same text. Distinct descriptions generated per product and then checked are an improvement on duplicated copy. Searching an exact sentence from your own description in quotes shows quickly whether the page is competing against identical text.

Does this work with Shopify and WooCommerce?

Yes. Both expose the order, customer and inventory data these flows need. The integration is rarely the difficult part; the difficult part is usually whether inventory data is accurate enough to automate communication against.

How many orders make ecommerce automation worthwhile?

Roughly the point where the same message is being sent by hand several times a day, which for most stores is a few hundred orders a month. Below that the honest recommendation is to keep it manual and spend the money on acquisition instead.