Two linked journeys close a loop a one-off review request never does. The first waits a few days after any purchase and mails a Rating block. The second is triggered by that email's own rate interaction, reads the score off it, and opens a support ticket automatically when it's low — no one has to notice a bad review to act on it.
A single post-purchase review send asks the question once and stops there. Nobody's watching for a bad answer, and a rating of 1 or 2 stars sits in the Responses dashboard until someone happens to check it. Chaining the same Rating block into two always-on journeys instead means the low score itself is what triggers the next action.
Journey one: ask, on a delay
The first journey's trigger is purchase, set with no specific project so it fires off any Product block checkout MailInApp itself processed completing — not just one template. A wait step gives the order a few days to actually arrive, then a send step mails the rating request: a single Rating block, optionally paired with a short Form question for anyone who wants to add context.
This only covers Product blocks left on MailInApp checkout (Stripe) mode — MailInApp is the one processing the payment there, so it's the one that knows a purchase happened. A Product block set to Link to external store checkout sends the buyer to complete the sale entirely on your Shopify or WooCommerce store instead; MailInApp never sees that purchase, so it can't fire this trigger for it. If you're using external checkout, build a post-purchase review off a purchase-history segment instead — see win back past buyers with purchase-history segments for the same store-side signal used a different way.
Journey two: watch the answer, escalate the bad ones
The second journey's trigger is an interaction — specifically the rate action on the first journey's own review project. The moment someone taps a star, this run enrolls carrying that score with it. From there:
- An update-field step writes the rating onto the contact record.
- A branch step checks whether it's 2 stars or below.
- A create-ticket step — reached only on the low-score branch — opens a support ticket automatically, its subject and body templated with the contact's email and the exact score they gave.
A high rating simply ends the run on the "no" branch; it still counts toward your CSAT average on the Responses dashboard, just without triggering a ticket.
Why two journeys, not one
The two triggers fire at genuinely different times off genuinely different events — a purchase completing, then (days later, maybe) a specific email's rate interaction. Modeling that as two linked graphs rather than one long one keeps each journey's trigger unambiguous. Installing the Post-purchase starter creates both together in a single step, along with the review-request project itself.
What the escalation ticket actually contains
Because the create-ticket step is templated with merge tags from the run, the ticket that lands in your account-wide Tickets inbox already names who left the review and the score they gave. A person can act on it immediately, instead of digging through the Responses dashboard to find the context first.
Tuning it
The 2-stars-or-below threshold on the branch step is just the starter's default — it's an ordinary condition you can edit like any other. The same pattern extends past ratings, too. Any interaction a journey can trigger on (a form submission, an RSVP, a poll vote) can feed the same update-field → branch → create-ticket shape for a different kind of "notice this automatically" workflow.
Getting started
Install Post-purchase from the Journeys list page for both linked journeys and the Rating email built together. Or wire it up yourself: a purchase-triggered journey that waits and sends a rating request, plus a second journey triggered on that email's rate interaction with an update-field, branch, and create-ticket step. See Journeys for the full step reference and support tickets for what happens after one's created.