automations.help
Book a teardown

Reviews & UGC

Trigger review requests after delivery

Most stores send their review email a fixed number of days after an order ships — which means it often lands before the customer has the product in hand. Here's how to trigger the ask on the actual delivery event instead, wait a sensible settle-in window, and only ask the people who aren't mid-return.

Difficulty
Intermediate
Time to build
3-5 hrs
Updated
  • Klaviyo
  • Shopify
  • ShipBob

The manual way today

The review request runs on a timer: X days after the order is placed, or X days after it's marked fulfilled. Someone picked that number once, and it's been firing on every order since. Nobody checks whether the box has actually arrived before the 'how do you like it?' email goes out — there's no easy way to, so the timer just keeps running.

Shipping times vary by days, so a fixed timer guarantees a chunk of your asks land before delivery. Asking someone to review a product they're still waiting on reads as tone-deaf at best — and it trains people to ignore your review emails entirely, which drags down the response rate on every future ask, not just the early ones. Fewer reviews means weaker social proof on the exact product pages where it converts, and the asks that do land late (weeks after a customer's moved on) do no better. The timer feels like it's working because emails are going out; the silence is the cost.

What running looks like

A carrier-confirmed 'delivered' status — not a label being printed — is what starts the clock. The order waits a settle-in window you set (short for apparel, longer for things a customer has to actually use), then Klaviyo sends one review request to a customer who has the product, hasn't opened a return, and hasn't already been asked. Returns and refunds opened during the wait suppress the ask automatically.

01The build

How to build it

  1. Decide your settle-in window and who never gets asked

    Needs a human

    Pin two things down before automating anything. First, how long after delivery to wait before asking — a few days is plenty for apparel or accessories, but a consumable or skincare product needs a couple of weeks of actual use before a review means anything, so set this per product type or collection, not as one global number. Second, the exclusions: returns or refunds in progress, orders with an open support ticket, gifts, wholesale, and anyone you've already asked. This is the judgment call; everything after runs on its own.

  2. Get a real delivery signal, not a ship signal

    Runs itself

    The trap is that the obvious trigger — Klaviyo's 'Fulfilled Order' metric, or Shopify marking an order fulfilled — fires when a label is created, which is the day it ships, not the day it lands. You need the carrier-confirmed delivered status. Watch ShipBob's tracking webhook for the shipment status flipping to 'delivered' (or poll the shipment's tracking endpoint on a schedule if you'd rather not run a webhook). That delivered timestamp is the only trigger that means the customer actually has the box.

  3. Match the delivery back to the Shopify order and customer

    Runs itself

    The tracking event tells you what was delivered; you need who to ask. Key off the order name or the 3PL reference ID you set at order creation — not the email, which isn't unique — and look the order up via the Shopify Admin API to pull the customer's email, the line items (so you can ask about the specific products), and the order's current tags. Grab the customer's Klaviyo profile in the same step.

  4. Drop the orders that shouldn't be asked

    Runs itself

    Run the exclusions from step one against the matched order before anything goes further: skip orders tagged for an open return or refund, anything with an open Gorgias/support ticket, gift orders, wholesale on a separate queue, and any order already tagged as asked. Asking a customer who's mid-refund to leave a review is the single fastest way to turn a quiet return into a one-star — this filter is what prevents it.

  5. Tag the order so it can only be asked once

    Runs itself

    The moment an order clears the filter and gets enqueued, write a tag like review-requested plus the date onto the Shopify order. That tag is your idempotency key: a re-run of the flow, a duplicate delivery webhook, or a second tracking poll all see the tag and skip. Dedupe on the tag, not on the email send, so nothing can double-fire a request at the same customer.

  6. Fire an 'Order Delivered' event into Klaviyo

    Runs itself

    Send a custom 'Order Delivered' event to the customer's Klaviyo profile with the properties the email will need: order number, the delivered date, the line items, and the review submission link for each product (the deep link your review platform generates). This event — not a generic 'fulfilled' metric — is what the review flow keys off, so the timing reflects reality.

  7. Let a Klaviyo flow own the wait and the message

    Runs itself

    Build the review request as a Klaviyo flow triggered on the 'Order Delivered' event: a time delay set to your settle-in window from step one, then the email (or SMS, per the customer's consent). Branch the delay on product type so consumables wait longer than apparel. Letting Klaviyo own the send means consent, quiet hours, and unsubscribes are all respected automatically, instead of you firing raw API sends that ignore them.

  8. Re-check for a return right before the email sends

    Runs itself

    A customer can request a return during the settle-in window — and the worst possible review ask is the one that lands the day after someone sends an item back. Add a conditional split at the end of the flow, immediately before the send, that re-checks the order has no return or refund opened since delivery. If one has, the customer exits the flow and never gets the ask. This second check, after the wait, is what the up-front filter alone can't catch.

02The stack

What it’s built on

ShipBob
The delivery signal. Its tracking webhook (or tracking endpoint) reports the carrier-confirmed 'delivered' status that starts the clock — the one event that means the customer actually has the product, not just that a label was printed.Any 3PL or tracking source that exposes a delivered status does this job — the carrier-confirmed delivery event is the point, not the brand. If you fulfill in-house, read delivery status from your carrier's tracking or whatever tracking layer your store already uses; only the source of the 'delivered' field changes.
Shopify
System of record for the order: where you match the delivery to a customer and line items, and where you write the review-requested tag that keeps the ask to exactly one per order.
Klaviyo
Owns the wait and the message. The 'Order Delivered' event triggers a flow that holds for your settle-in window, re-checks for returns, and sends the request while respecting consent, quiet hours, and unsubscribes.Klaviyo's free tier is plenty to build and test this on, and you're likely already running it for email. Any ESP that accepts a custom event and triggers a delayed flow works the same way — only the event API shape differs.
n8n
The glue: receives the ShipBob delivery webhook, matches the Shopify order, runs the exclusion filter, tags the order, and fires the Klaviyo event.n8n is open-source and self-hostable for free; their cloud tier just saves you running it yourself. Zapier can do the same wiring if you'd rather not host anything.

03Questions

Before you build

Why not just send the review ask a fixed number of days after the order ships?

Because delivery time isn't fixed. A two-day order and a nine-day order both ship on day zero, so a 'five days after shipping' timer asks one customer five days after they got the box and the other before it's even arrived. Triggering on the actual delivery event puts everyone at the same point in their experience — product in hand, settled in — which is the only point where a review ask makes sense.

Klaviyo already has a 'Fulfilled Order' trigger — isn't that good enough?

Fulfilled means a label was created, which is the ship date, not the delivery date. That's exactly the signal that fires too early. You want the carrier-confirmed 'delivered' status, which is why this build pulls delivery from ShipBob's tracking (or your carrier) and pushes its own 'Order Delivered' event into Klaviyo rather than leaning on the fulfilled metric.

How long after delivery should I actually wait?

It depends on the product. For apparel or accessories a few days is enough — they've worn it, they have an opinion. For consumables, supplements, or skincare, wait a couple of weeks so the customer has actually used it; a review written the day a box of protein arrives is worthless. Set the delay per product type in the flow rather than picking one number for the whole catalog.

What stops a customer who's returning the item from getting asked?

Two checks. The filter before the flow drops any order already flagged for a return or refund, and a second conditional split at the very end of the flow — right before the email sends — re-checks that no return was opened during the settle-in window. A customer who sends the item back mid-wait exits the flow and never gets the ask.

What if my 3PL doesn't report a delivered status?

Then the delivery signal comes from the carrier's tracking instead of the 3PL. As long as something in your stack knows the tracking number has reached 'delivered' — your carrier, a tracking layer, or the tracking data flowing through Shopify — you can key the same 'Order Delivered' event off it. The principle holds; only the source of the delivered field changes.

Can I build this myself, or should you build it?

Every trigger, field, and check is spelled out above, so if you've got API comfort and a few spare hours, wire it up yourself. If you'd rather not own the delivery-tracking edge cases and the return re-checks, we'll build it on the Klaviyo, Shopify, and ShipBob accounts you already pay for, document it, and hand you the keys — you own the workflow outright, with no monthly retainer. It starts with a free 20-minute teardown, not a contract, and you keep the plan either way.

Reviews & UGC

Reward customers with a discount code for reviews

Asking for a review is asking a customer for free work. A small reward for the people who actually do it lifts your response rate without bribing anyone for a five-star. Here's how to mint a unique, single-use discount code the moment a verified customer leaves a review, deliver it through the email you already send, and do it without the legal and abuse traps that come with paying for reviews.

  • Klaviyo
  • Shopify

Intermediate3-5 hrs

Reviews & UGC

Flag negative reviews for follow-up

A one-star review is a customer telling you something's wrong in the most public place they have. This watches every review as it's submitted, catches the low ones, and drops them in a Slack channel with the rating, the product, what they wrote, and who they are — so someone reaches out while it still matters instead of finding it a week later in the app's dashboard. Build it yourself with the steps below, or we build it, wire the routing, and hand you the keys so you own it with no monthly fee. Free teardown of your current review setup first.

  • Slack
  • Klaviyo

Intermediate1-3 hrs

Reviews & UGC

Collect photo and video UGC in Airtable

Your best content is already being made — customers shoot it and drop it in photo reviews, email replies, and DMs, where it dies. This pulls every photo and video into one Airtable library the moment it lands: the file attached, who sent it, which product, which source, and — the part most teams skip — whether you actually have the right to run it in an ad. Build it yourself with the steps below, or we build it on the accounts you already pay for and hand you the keys, so you own the whole thing with no monthly fee. Free teardown of where your UGC is currently leaking first.

  • Airtable
  • Klaviyo
  • n8n

Intermediate4-6 hrs