How do you connect Shopify or WooCommerce COD orders to a call?

Four moving parts, and only one of them is hard

Every store-to-call integration is the same four pieces, whichever platform you are on:

1. a trigger that fires when a new cash-on-delivery order appears,
2. the fields the agent needs in order to talk about that order,
3. a filter deciding which of those orders is worth a call,
4. a write-back that puts the outcome somewhere your dispatch team will actually see it.

The first three are configuration. The fourth is where most integrations quietly fail, and it is worth doing last-first: decide where the outcome lands before you decide anything else, because an integration that calls customers and files the results somewhere nobody looks has produced work instead of removing it.

The trigger

Nishchit reads orders from five kinds of source, and the choice between them is mostly a choice about how much control you want over the moment a call is queued.

Shopify and WooCommerce are connected as stores. You authorise the connection once and new orders arrive on their own. This is the right option unless you have a reason not to use it: there is nothing to build and nothing to maintain.

A custom API connection is for a store you built yourself, or a platform we do not support. Nishchit polls or receives your orders in the shape defined in the API contract, and you keep control of exactly what you send.

A webhook is for when your system already knows the moment an order becomes callable and you would rather push than be polled. This is the most precise trigger available, because you decide what "new cash-on-delivery order" means — after fraud screening, after stock check, after whatever gate your operation has.

A CSV upload is the honest answer for a merchant whose orders live in a spreadsheet, and for one-off batches: a backlog, a campaign, a re-confirmation run over yesterday's unresolved calls.

There is no ranking here. A store connection is less work; a webhook is more precise. Both are correct.

The fields

An agent cannot have a useful conversation about an order it only half knows. The minimum is smaller than people expect, and the maximum is worth thinking about.

Required, or the call cannot happen: a phone number in a callable format, the customer's name, the items with quantities, and the amount payable at the door. Everything the agent says comes from those.

Required if you want the call to be worth making: the delivery address as the customer wrote it. Confirming an address the agent cannot read back is the single most valuable thing a confirmation call does, and an integration that omits it has thrown away most of the benefit.

Worth sending if you have it: the order number as the customer would recognise it, the channel the order came from, and any note the customer left at checkout. A customer who wrote "please deliver after 6pm" and is then asked what time suits them has been asked a question they already answered.

Two details are easy to get wrong. Phone numbers need to be normalised to a form that can be dialled — a nine-digit local number, a number with a leading zero and a number in +880 form have to end up in the same place, and this is worth fixing at the source rather than in three different systems. And amounts should be sent as integer paisa, not as a decimal. Money in a floating-point field is a bug that shows up as a total the customer does not recognise, which is exactly the moment you cannot afford to sound wrong.

The filter

Not every order deserves a call, and calling all of them is how a confirmation step becomes an annoyance.

The obvious filter is payment method: prepaid orders are already settled, so there is nothing to confirm. Cash on delivery is the whole point. After that, the filters worth having are about value and about repetition — a very low-value order may not justify a call, and a customer whose last four orders all arrived cleanly is not the risk your call is for.

The filter that matters most is time. A confirmation call is only useful before dispatch, so the queue has to run early enough that a confirmed order can still go out today, and late enough that the customer is awake. Those two constraints define a window, and the window is a business decision rather than a technical one. It is also the reason a call queue needs an explicit stop time: an untended queue will keep dialling at an hour you would never dial yourself, which is one of the things an agent must never do.

The write-back

When the call ends, exactly one of six structured outcomes is written onto the order: confirmed, cancelled, modified, callback, human or unresolved. That is the integration's real output, and it goes back three ways.

Onto the order in Nishchit, with the recording, the turn-by-turn transcript, and any structured change the customer asked for — the field, its old value, its new value. This is what makes a confirmation auditable rather than merely recorded.

Onto the order in your store, where the connection supports it, so the person picking and packing sees the confirmation in the tool they already have open. A separate dashboard that nobody on the packing floor looks at is not a write-back.

Onto a signed webhook, if you want to drive your own systems from the outcome. Release stock on a cancellation. Re-print a label on a modification. Push a callback into a human queue. The signature is there so your endpoint can verify the call actually came from us before acting on it — an unauthenticated webhook that mutates orders is a way for anyone who guesses the URL to cancel your business's parcels.

Test it against real orders before you trust it

Two things are worth doing before an integration handles a day's volume.

Run it in demo mode first. Demo mode places no real calls and bills no minutes; it produces realistic scripted conversations against seeded orders so you can see the whole flow — trigger, call, outcome, write-back — without phoning anybody. What you are checking is not the voice. It is whether the outcome lands somewhere your team will act on it.

Then run one real batch small enough to listen to. Pick a handful of orders, let the calls happen, and listen to all of them. You are checking three things: that the agent read the total and the address correctly, that a customer who asked for a change had that change recorded as a structured edit rather than a note, and that a call which should have escalated did.

Features covers what the platform does with an outcome once it has one, and the integrations section lists the five order sources with what each one needs from you.