Get your lost sales back.

No. That is the whole point. Every one of the seven arrives written, timed and configured. On your first day an AI pass reads your categories, your best sellers and your price range, then drafts every email in your store’s own language, ready for you to edit. Timings, coupon rules and cancellation rules are already set to sensible values. There is no blank canvas anywhere in the product, and AI never touches the HTML.

No, and you should not start that way. Everything ships switched off except the popup coupon delivery, so a fresh install sends nothing until you decide it should. Start with cart abandonment, which is the one that pays for the rest, and add the others once you have read what they say. Every flow has a live preview of each email, and every message BrikMentor prepares is stored in a log you can open. You always know exactly what your store is sending.

Every flow has a live preview button per email, and every message BrikMentor prepares is stored in a log you can open and read. You will never wonder what your customers are receiving.

No, and there is no way to have to. There is no per-product setting, because the form is not placed product by product. It attaches to the stock line WooCommerce itself renders, so it turns up on every out-of-stock product the moment you switch the flow on, including the ones you add next year. Two extra fallbacks catch page builders such as Elementor that replace the whole product template and never fire WooCommerce’s normal hooks. It was measured across seventeen themes and dozens of product-page plugins before it shipped.

Yes, and that is the part most tools skip. Each request is stored against the exact variation, so someone waiting on a medium is not emailed when the large comes back. If a shopper is waiting on several sizes of the same thing they still get one email, not one per size. It also handles products with more than thirty options, where WooCommerce stops sending variation data with the page and fetches it later instead.

Within minutes. BrikMentor listens for the moment a product becomes sellable again, so an ordinary restock in WooCommerce is picked up straight away. On top of that a reconciliation pass runs every fifteen minutes, which is what catches stock written into the database by an ERP or an import that fires no hook at all. The messages are then spread over half an hour rather than fired in one burst, because a few hundred identical emails leaving in the same second is exactly what mailbox providers treat as a spam signal.

After a while, one honest email says so and offers alternatives from the same category, linking to your store rather than to the sold-out page. The wait is measured in weeks and BrikMentor picks the length from how deeply your store actually stocks things, so a made-to-order store and a warehouse are not held to the same clock. You can change it, or set it to zero and never send that email. Availability is checked again first, so nobody is told an item never returned when it is back on the shelf.

Yes. Your dashboard shows how many people are waiting, on how many products, and the queues in order of size. The contacts screen lists every product and option somebody is waiting for, busiest first, with the date of the first request and whether the item is back yet. The counting is deliberately honest: one shopper waiting on five sizes appears as one person, not five.

Only what the shopper agreed to. Asking to be told about one product is exactly that, and it is the narrowest permission in the product: it names a single item. There is an optional marketing tick next to it, never pre-checked, and no setting anywhere to pre-check it. If they leave it alone they hear about that product and nothing else. If somebody unsubscribes, every request they were still waiting on is cancelled the same moment. Requests are forgotten after a period you set, whether or not the flow is switched on.

Because a free plugin solves the easy half. Writing the reminder and timing it is the easy half; getting it into an inbox is the hard one, and the free plugins hand that back to you. They call WordPress’s wp_mail(), which posts through whatever your web host provides, from a server with no reputation as a bulk sender and no relationship with Gmail. To fix that properly you would buy an SMTP or ESP account, verify a sending domain, publish DKIM, SPF and DMARC records, then keep a bounce list and a complaint list so dead addresses stop being retried. That is a real job, and it is the job most store owners have no reason to know how to do. So the mail goes out, a good part of it lands in spam, and the flow quietly earns a fraction of what it should while every dashboard still reports it as sent. BrikMentor’s answer is that sending is not an add-on here: it runs on Amazon SES, from your own verified domain, inside the $15.

Three things. First, where the mail comes from: your own verified domain, signed with 2048-bit DKIM, on Amazon SES rather than your web host, which is the difference between the inbox and the spam folder for most stores. Second, what happens to bad addresses: bounces and complaints are counted and suppressed for you, and every message carries the one-click List-Unsubscribe header Gmail and Yahoo have required from bulk senders since 2024. Third, what else you get: carts are one of seven flows here, and back in stock, winbacks and payment recovery have nowhere to live in a cart plugin. Keep the free plugin if it is doing what you need. If you are not sure it is landing, that is exactly the thing it cannot tell you.

We do, and no. Sending is part of the product, not something you bolt on afterwards. Messages leave through our own managed infrastructure on Amazon SES in the EU (Stockholm) region, so there is no SMTP host to configure, no API keys to paste, no second subscription to renew, and no wrestling with what your hosting company allows wp_mail() to do. Queueing, rate limiting, retries, bounce handling and complaint handling are all on our side. What stays on yours is the part that should: the triggers, the templates and the data.

You publish five DNS records once, and that is the whole job. From then on every message is signed with 2048-bit DKIM on your domain, bounces return through a subdomain of yours, and SPF and DMARC line up, so a mailbox provider sees your store sending its own mail rather than a stranger sending on your behalf. There is deliberately no shared “just use our domain” fallback: we measured that model against real inboxes and it did not hold up, and without a verified domain BrikMentor refuses to send at all. It is the one setup step we will not let you skip, and it is the reason the emails land.

Sending runs through our managed infrastructure on Amazon SES (EU region, Stockholm), so you never set up SMTP, API keys or an ESP account. Every store sends from its own domain: you publish five DNS records once, and from then on your mail is signed with 2048-bit DKIM as your store, with SPF and DMARC aligned and bounces returning through your own subdomain. There is deliberately no shared “sender” domain to fall back on, because a From address your customers don’t recognize is exactly what gets filtered, and without a verified domain BrikMentor refuses to send at all. Bounces and complaints are tracked per store, and if a store’s rates cross safe thresholds, sending pauses automatically before any real damage is done. One store’s bad list can’t burn the neighborhood down. On top of that, the popup-coupon flow gives new subscribers an immediate reason to open and click, which is the strongest inbox-placement signal there is.

No, and that is by design. Because every store sends from its own verified domain rather than a shared one, the reputation being built or burned is always the sender’s own. On top of that, bounces and complaints are counted per store, and a store whose rates cross safe thresholds is paused automatically before real damage is done. Suppression is checked before every single send, with no exceptions. One careless neighbour cannot drag your domain down with theirs.

Every email carries a visible unsubscribe link and the one-click List-Unsubscribe headers (RFC 8058) that Gmail and Yahoo require. The link leads to a confirmation page, so an overzealous corporate link-scanner can’t unsubscribe someone by accident, but a human is out in two clicks, and one click from inside Gmail itself. The suppression list is checked before every single send, no exceptions.

It’s built for it. Cart recovery and post-purchase emails go to people with an existing customer relationship (soft opt-in). Winback and campaigns only go to contacts with explicit marketing consent by default. You can loosen that, but you make that call, per your local rules, and the setting says so in plain words. Every contact record stores where and when consent was given. Personal data never ends up in log files. The one-time AI pass that writes your flow emails sees only an aggregate picture of your catalogue (categories, best sellers, price range), never a customer record.

The engine (triggers, flows, templates, the revenue counter) runs inside your WordPress. Only what's needed to deliver an email leaves your server. Cancel anytime; everything stays in your database.

Yes. There is a CSV import for contacts, and it asks you where each address came from and when they agreed, because a contact record without a consent source is not one you should be mailing. If you are moving from another tool, you can also import that tool's unsubscribe and bounce list, so the people who already opted out stay opted out. That import is the first thing to run, before you switch any flow on.