Post-Purchase Review Journeys With Automatic Ticket Escalation

A one-off review-request send asks the question once and moves on — nobody's watching for a bad answer. Wiring the same Rating block into a pair of always-on journeys closes that loop: the first waits after any purchase and mails the rating request; the second is triggered by that email's own rate interaction, reads the score straight off it, and opens a support ticket automatically the moment it's low enough to need a person.

Subject

How did we do?

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 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.

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:

  1. An update-field step writes the rating onto the contact record.
  2. A branch step checks whether it's 2 stars or below.
  3. 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.

A typical build-and-send sequence

  1. 1

    Trigger the first journey on any purchase

    Set a journey's trigger to purchase with no specific project — it fires off any product-block checkout completing, not just one template.

  2. 2

    Wait, then ask for a rating

    A wait step gives the order a few days to actually arrive before a send step mails the rating request.

  3. 3

    Trigger a second journey off the rating interaction

    Point a second journey's trigger at the rating email's own rate action — it enrolls the moment someone taps a star, carrying that score with it.

  4. 4

    Capture the score and escalate low ones

    An update-field step writes the rating onto the contact record, a branch step checks whether it's 2 stars or below, and a create-ticket step opens a support ticket automatically for the ones that are.

Frequently asked questions

Does the escalation ticket include the actual rating and who left it?

Yes — the create-ticket step's subject and body are templated with merge tags pulled from the run, so the ticket that lands in your queue already names the contact's email and the exact score they gave, ready for a person to follow up.

Why two separate journeys instead of one longer one?

The first journey's trigger is a purchase event; the second's is an interaction on the specific email the first one sends — those are two different trigger kinds firing at two different times, so they're modeled as two linked graphs rather than one. Installing the Post-purchase starter creates both together in one step.

What happens to a rating that isn't low enough to escalate?

Nothing further — the branch step's "no" path simply ends the run. The rating itself still counts toward your CSAT rollup on the Responses dashboard either way; escalation only adds a ticket on top for the scores that need attention.

Can I change the low-score threshold, or who the ticket goes to?

Yes — the branch step's condition is an ordinary rule you can edit (2 stars and below is just the starter's default), and support tickets land in your account-wide Tickets inbox regardless of which project or journey created them.

Does this replace the plain post-purchase review-request send?

It's the always-on version of the same idea — a one-time recurring send still works fine for a periodic review ask, but only a journey's interaction trigger can watch for a low score continuously and escalate it the moment it happens, with no one having to check the Responses dashboard for it.

Build this in the studio

Start on the free plan — every interactive block and the full fallback engine are included on every tier.