The automations that matter do not start from an email

Ask an online store which automations it has running and you almost always hear the same three: abandoned cart, welcome series, post-purchase email. They are useful, they are the bare minimum, and they share one trait: they start from a behaviour in the inbox or on the site, and they end in an email.

Meanwhile the store generates dozens of events a day that nobody is listening to.

The events nobody is listening to

A product drops below its stock threshold. A competitor cuts the price on an item where you have margin. A page has been live for six months without a sale. A customer who bought every month has not bought for three. A return exposes a sizing problem on one specific item. A product comes back into stock while somebody was waiting for it.

Each of those is a fact that should make something happen, and in almost every store it makes nothing happen until a person notices it in a report. Usually too late, and in any case only for the products that person has time to look at.

Why those automations almost never exist

It is not laziness. It is that those events cross different tools.

"A competitor's price went below mine" starts in the repricer. Doing something useful with it needs the margin (in the back office), the availability (in Shopify) and then a campaign or a price change (somewhere else again). An automation like that has to be built by hand, with integrations, and kept alive while the tools change versions.

So in practice it does not get built: not because it is not useful, but because keeping it standing costs too much. And the only automations that survive are the ones living inside a single tool, which is to say the three above.

What changes when events and actions share a place

When catalogue, pricing, content, campaigns and conversations read the same data, an automation stops being an integration and becomes a rule.

A product comes back into stock and whoever was waiting hears about it, on the channel where they asked. A page gets enriched and the feed, the content and the ad creatives follow, without anybody re-exporting anything. A product falls below threshold and the ad spend on that product stops, instead of paying for clicks to something you cannot sell.

That last example is the most concrete of all: paying to send traffic to a product you cannot sell is a loss that appears nowhere, because the spend looks normal and the missing revenue is never measured.

One place to look, instead of six

There is a second half to the problem, less visible. Even where alerts exist, each sits in its own tool: repricer notifications, feed warnings, unanswered tickets, campaign errors. Six places to check, and nobody checks all of them every day.

A single list of things needing attention is not a dashboard flourish: it is the only shape in which alerts actually get read. An alert living somewhere you open once a week is not an alert, it is an archive.

Which ones to start with

Not the sophisticated ones. The first three that almost always pay back, in order.

Stop spending on what you cannot sell. Free to set up, immediate and measurable saving.

Tell the people who were waiting that a product is back. That is a sale already about to happen, lost only to bad timing.

Let content follow catalogue enrichment. It does not save hours: it removes the mismatch between what the page says and what ads and social say, which is one of the silent causes of disapproved ads.

Frequently asked questions

How is this different from connecting tools with Zapier?

A connector moves data between separate boxes, and works until the boxes change. The limit is not the technology: it is that every hop is a point that can break, and that neither side knows the other's context. When the data is already shared, the hop does not exist and cannot break.

Do I need to know how to code?

No, but you need to be able to say precisely what should happen and when. The hard part of an automation is not building it: it is deciding the rule, and above all deciding the cases where it must not fire.

How many automations should I have?

Few and understood, rather than many and forgotten. An automation nobody remembers switching on is a problem waiting to happen: when it goes wrong, nobody knows why. A good rule is to keep only the ones whose behaviour you could explain out loud.

What if an automation gets it wrong?

You have to be able to see it and stop it. Anything touching prices, ad spend and messages to customers wants a human step or at least a limit: a threshold past which it stops and asks. The automation with no brake is the one that does damage quietly.

From how many products is it worth it?

It depends less on the number of products than on how often things change. A small catalogue with prices and stock moving constantly benefits more than a large, static one.