Post-Purchase Review and Reorder

The order ships and the relationship stops. A tracking email goes out, the parcel arrives, and then nothing until the customer appears in the next broadcast alongside everyone who has never bought anything. The most expensive customer a store will ever acquire is the first-time buyer, and the period immediately after their first delivery is when that acquisition cost either gets repaid or written off. Most stores spend that window silent.

Two specific things go missing. The first is reviews. Everyone knows social proof sells, and most stores collect it by sending one request a week after dispatch, to everyone, at the same interval, regardless of whether the item was a pair of socks or a mattress that needs a month of sleeping on. A request that arrives before the customer has formed an opinion produces no review; one that arrives six weeks late produces a vague one. Worse, an undifferentiated request sent to an unhappy customer invites them to publish that unhappiness, when a private route would have fixed the problem and kept the customer.

The second is the reorder. Consumables run out on a schedule that the store can calculate better than the customer can remember. Coffee, filters, supplements, pet food, skincare, printer ink, blades. Every one of them has a consumption window, and a message that arrives three days before the jar is empty converts at a rate that no generic promotion approaches. Almost nobody does this per product, because it requires deciding a replenishment interval for each SKU and then honouring it. This build does both: it routes satisfaction before it asks for publicity, and it times the reorder prompt to the product rather than the calendar.

Pipeline and stages

Pipeline: Post-Purchase Lifecycle. One card per order, not per contact, because a customer can be at different points on two different orders.

• Order Placed: paid, not yet dispatched.
• In Transit: dispatched, tracking live.
• Delivered: carrier confirmed delivery. Every clock in this build starts here, not at dispatch, because a review request that arrives before the parcel does damages trust.
• Settling In: the deliberate quiet period while the customer actually uses the thing.
• Satisfaction Checked: the private rating is in.
• Review Requested: happy customer, public review invited.
• Issue Raised: unhappy response, routed to a human, review request suppressed.
• Replenishment Window: approaching the product's calculated reorder date.
• Reordered: a repeat order attributed to this cycle.
• Lapsed: past the replenishment window plus a grace period, no reorder. Hands off to a win-back program rather than looping here.

Custom fields

On the contact, with per-order fields on the opportunity.

• Last Order ID, Last Order Date, Last Order Value, Last Order Channel
• Delivery Confirmed Date: the anchor date for every wait in this build
• Primary Product Purchased, Primary Product SKU, Primary Product Category
• Product Review Delay Days: per-SKU or per-category, the number of days after delivery before a review is worth asking for. Consumables 7, apparel 10, electronics 14, furniture and bedding 30. This field is the reason the reviews are specific rather than generic.
• Product Replenishment Days: per-SKU consumption window. The core field of the reorder half of the build.
• Calculated Reorder Date: Delivery Confirmed Date plus Product Replenishment Days, minus a 5-day head start so the message arrives before the customer runs out
• Satisfaction Score: 1-5 from the private check
• Satisfaction Checked Date
• Review Left: switch; Review Platform: Google / store / Trustpilot / Facebook; Review Rating Public
• Issue Category: dropdown: Damaged / Wrong Item / Late Delivery / Not As Described / Sizing / Quality / Missing Parts / Other
• Issue Resolved: switch, with Issue Resolved Date
• Lifetime Order Count, Lifetime Order Value, Average Days Between Orders: the last of these is computed and, after three orders, overrides the SKU default because the customer's own rhythm beats your estimate
• Reorder Prompt Count and Reorder Prompt Last Sent: cap enforcement
• Subscription Offered and Subscription Declined Date
• Marketing Consent Email, Marketing Consent SMS: separate, explicit, never inferred

Tags

• post-purchase-active: in the lifecycle
• pp-first-order, pp-repeat-customer, pp-vip (above the lifetime-value threshold)
• pp-promoter: satisfaction 4 or 5; pp-passive: 3; pp-detractor: 1 or 2
• pp-review-requested, pp-review-left, pp-review-declined
• pp-issue-open, pp-issue-resolved
• pp-consumable: the product has a replenishment window; pp-durable: it does not, so the reorder half is replaced by a cross-sell
• pp-reorder-due, pp-reordered, pp-lapsed
• pp-subscription-candidate: two or more reorders of the same SKU
• pp-review-suppressed: never ask this contact for a public review, applied by a detractor result or by hand
• sms-opted-out, email-unsubscribed

Forms and pages

• Satisfaction Check: a one-tap 1-to-5 scale, each option a separate link in the email so the rating is captured in a single click with no page load. The follow-up question appears only after the click, and it differs by rating.
• Issue Report: shown to anyone rating 1-3. Fields: issue category, free-text description, photo upload, and what outcome they want (replacement / refund / advice). Asking what they want resolves the ticket a round trip faster.
• Review Landing Page: for promoters only. Lists the items they bought with a review link per item, plus the external platform buttons. Never a bare “leave us a review” link, which produces reviews that mention nothing.
• Reorder Page: a pre-filled single-click reorder of the exact previous basket, with a quantity stepper and the subscription option alongside.
• Subscription Offer Page: for contacts on their second or third reorder of the same SKU, framed around never running out rather than around the saving.

BO's role and guardrails

• BO does: answer replies to any post-purchase message across email, SMS and chat; answer usage, care, dosage-on-label, storage and compatibility questions from the knowledge base; look up order and tracking status; capture Issue Category and the desired outcome; place a reorder of a previous basket; set up or pause a subscription; explain the returns process and generate the returns link; log a review as left.
• BO does not: authorize a refund, a replacement or a goodwill gesture; promise a delivery date the carrier has not given; give advice that goes beyond the product label, particularly on anything ingestible, applied to the body, or safety-related; respond to a public review; or push a reorder on a contact with an open issue.
• Escalation triggers: Satisfaction Score of 1 or 2; the words refund, chargeback, damaged, injured, reaction, allergic, ill, faulty, unsafe, legal, lawyer, trading standards or complaint; a second contact about the same unresolved issue; pp-vip; any request for compensation. Anything suggesting harm from a product goes to a named human immediately and bypasses every queue.
• Knowledge base: product usage and care per category, expected consumption rates, what is and is not covered by the guarantee, the returns and exchange process, how to start, pause or cancel a subscription, delivery carrier and timeframe by method, and the standing instruction to escalate rather than improvise on anything health-adjacent.

Reviews and reputation

• Private before public, always. The satisfaction check runs first and decides what happens next. Only promoters are asked publicly. This is not about hiding bad reviews. The detractor gets a faster, better response than a public complaint would have produced. It is about not inviting a review from someone whose parcel arrived damaged.
• Platform rotation across Google, the on-site product review and one third-party platform, weighted toward wherever the business is thinnest, so one profile does not grow while the others stagnate.
• Per-item review prompts rather than a generic request, so the resulting copy mentions the actual product and is useful on the product page.
• Review replies drafted for every new review and held for human approval. Nothing publishes unapproved.
• Social planner queue fed by strong reviews, with the customer's permission captured at the point they leave it. A tick box on the review landing page, not an assumption.

Numbers and channels

• The store number from the order-notification setup, reused rather than duplicated, with two-way SMS enabled so a reply about a damaged item reaches a person.
• Email on the authenticated sending subdomain, warmed.
• Web chat with BO primed on post-purchase questions, which are different from pre-purchase ones: usage, care, returns and tracking rather than sizing and shipping cost.
• Channels unified per contact, so an issue raised by SMS and chased by email is one thread.
• A single global frequency budget shared with the cart recovery build, so a customer mid-reorder-prompt who also abandons a cart does not receive both programs at once. This is the integration most often missed, and it is the one customers notice.

One first-time customer buying a 60-day supply of a consumable, from checkout to second order.

1. Tuesday. Order placed. Card created in Post-Purchase Lifecycle at Order Placed, tagged post-purchase-active and pp-first-order. Primary Product SKU is written, and from the SKU table the build inherits Product Review Delay Days = 7 and Product Replenishment Days = 60.
2. Wednesday. Dispatched. Card moves to In Transit. Tracking goes out on the order-notification path, which is deliberately separate from this build so the two do not duplicate each other.
3. Friday. The carrier webhook confirms delivery. Delivery Confirmed Date is stamped and Calculated Reorder Date is computed: delivery plus 60 days minus a 5-day head start. Card moves to Delivered.
4. Friday, 4 hours after delivery. A short arrival message, not a sales message. It confirms the parcel landed, gives the one thing people most often get wrong about using this product, and invites a reply with any question. For a first-time buyer this message does more for retention than any discount.
5. Saturday to Thursday. Settling In. Nothing is sent. The silence is the design: the customer is forming the opinion that the satisfaction check will measure.
6. The following Friday, 7 days after delivery. The satisfaction check goes out by email: one line of context, then five tappable faces. One tap, no page, no form. Card moves toward Satisfaction Checked on any click.
7. The customer taps 5. Satisfaction Score = 5, tag pp-promoter applied, card moves to Satisfaction Checked then Review Requested.
8. Two hours later (not immediately, because back-to-back automated messages read as a machine) the review request arrives. It names the product, links to the product review form, and offers the Google option, chosen by rotation because that profile is currently the thinnest. A tick box asks permission to quote them.
9. They leave a four-sentence review mentioning the product by name. Review Left, Review Platform and Review Rating Public are written, pp-review-left applied, and the review-request ladder cancels so no reminder follows a completed review. A reply to the review is drafted and queued for human approval, and because permission was given, the quote enters the social planner queue.
10. Day 10. A single usage-tip email, relevant to the product, carrying no offer. This is the only purely-value message in the sequence and it exists to make the reorder prompt welcome rather than abrupt.
11. Day 55: the Calculated Reorder Date. Card moves to Replenishment Window, tag pp-reorder-due. The reorder prompt goes out by email with a one-click link that rebuilds the exact previous basket: “You're about five days off running out, going by a normal 60 days. One tap puts the same order through.” The honesty about the estimate matters; a customer who used it faster or slower will tell you, and that correction improves the field.
12. Day 58. No order. One SMS (the only SMS in this sequence) mid-morning, inside the window, with the reorder link and the opt-out. Reorder Prompt Count = 2.
13. Day 58, afternoon. The customer replies I've still got about two weeks left. Reply detection cancels the remaining prompts, BO acknowledges and offers to move the reminder, and: the valuable part: Product Replenishment Days is adjusted for this contact to 74. The second cycle will be correctly timed because the first one asked.
14. Day 72. The rescheduled prompt goes out. The customer reorders in one tap. Card moves to Reordered, pp-reordered applied, pp-first-order swapped for pp-repeat-customer, and Average Days Between Orders is computed for the first time.
15. A new lifecycle card opens on the new order and the whole cycle restarts. Except the review request is suppressed, because this contact has already reviewed this product, and Average Days Between Orders now takes precedence over the SKU default.
16. After the second reorder of the same SKU, pp-subscription-candidate is applied and the subscription offer goes out once, framed around never running out. If declined, Subscription Declined Date is stamped and the offer is suppressed for 12 months. Asked once, honoured.

Eight workflows. Every send checks: no sms-opted-out or email-unsubscribed, no pp-issue-open (an open issue silences everything commercial), inside the channel window, and within the global frequency budget shared with the cart build.

1. Order Intake and Delivery Tracking

Trigger: order-created webhook from the store.

Actions:

1. Create the opportunity in Post-Purchase Lifecycle at Order Placed, named [Order ID]: [Primary Product Purchased]. Write Last Order ID, Last Order Date, Last Order Value, Primary Product SKU, Primary Product Category.
2. Look up Product Review Delay Days and Product Replenishment Days from the SKU table. If the SKU has no replenishment value, apply pp-durable and skip workflows 5 and 6 entirely for this order.
3. Apply post-purchase-active. Branch: Lifetime Order Count = 0 → pp-first-order; 1 or more → pp-repeat-customer; Lifetime Order Value above the VIP threshold → pp-vip.
4. On dispatch webhook: move to In Transit. Tracking notifications are handled by the order-notification setup, not here: do not duplicate them.
5. On delivery webhook: move to Delivered, stamp Delivery Confirmed Date, compute Calculated Reorder Date = delivery date + Product Replenishment Days − 5 days.
6. No delivery confirmation after the expected window plus 3 days: apply pp-issue-open, Issue Category = Late Delivery, create a task on fulfillment, and send the customer a proactive note: “Your order looks like it's running late according to the carrier. We're chasing it. You don't need to do anything, but reply if you'd rather we just resend it.” Getting ahead of a late parcel converts a complaint into loyalty; waiting for the customer to notice does the opposite.

Exit: order refunded or canceled, which removes post-purchase-active and closes the card.

2. Arrival Message and Settling-In Hold

Trigger: stage changes to Delivered.

Actions:

1. Wait 4 hours. Long enough that the parcel has been opened, short enough that it is still the day's event.
2. Send the arrival message by email. No offer, no cross-sell, no review request. pp-first-order version: “Your [Primary Product Purchased] arrived today: thanks for giving us a go. One thing worth knowing: [the single most common usage mistake for this category]. Anything you're unsure about, just reply to this, it comes to a real inbox.” pp-repeat-customer version: two lines, no onboarding content.
3. Move to Settling In. Send nothing further until Product Review Delay Days has elapsed from Delivery Confirmed Date.
4. Branch: pp-durable with an assembly or setup requirement: add one setup-help email at 48 hours with the instructions and a link to book a support call. This is where not as described reviews come from, and a timely email prevents a fair number of them.
5. Branch: pp-vip: additionally create a task for the owner or account manager to send a personal note within 2 business days. Automate the reminder, not the note.

Exit: any inbound message (hand to workflow 7), or the review delay elapsing.

3. Satisfaction Check and Routing

Trigger: Delivery Confirmed Date + Product Review Delay Days.

Conditions: no pp-issue-open, no refund or return in progress, not email-unsubscribed.

Actions:

1. Send the Satisfaction Check email. Subject: “How's the [Primary Product Purchased] working out?” Body: one line, then five tappable options, each a distinct tracked link. Nothing else. No offers, no footer promotions. One question, one tap.
2. Branch: score 4 or 5: apply pp-promoter, write Satisfaction Score, move to Satisfaction Checked, hand to workflow 4.
3. Branch: score 3: apply pp-passive. Show a single open question: “Thanks. What would have made it a 5?” Route the free-text answer to the product owner. Do not ask for a public review. A 3 produces a lukewarm review that costs more than no review. Continue to the reorder path.
4. Branch: score 1 or 2: apply pp-detractor and pp-issue-open and pp-review-suppressed, move to Issue Raised, and hand to workflow 8 immediately. No further commercial message of any kind goes to this contact until the issue closes.
5. No response after 3 days: one SMS reminder, if SMS consent exists: “Quick one: how did you get on with the [Primary Product Purchased]? Tap a number 1-5: [link]”
6. No response after 3 further days: stop. Apply pp-review-declined, move to the reorder path. Two asks is the limit; a third makes the next email less likely to be opened.

Exit: any score recorded, or the second reminder lapsing.

4. Review Request and Platform Rotation

Trigger: pp-promoter applied.

Actions:

1. Wait 2 hours after the satisfaction tap. Deliberate: two automated emails inside a minute reads as a machine and depresses response.
2. Select the platform by rotation, weighted toward the profile with the fewest reviews in the last 90 days, excluding any platform this contact has already reviewed on.
3. Move to Review Requested, apply pp-review-requested. Send: “Really glad the [Primary Product Purchased] is working out. If you've got two minutes, a few words about it genuinely helps the next person deciding, and it helps us know what to make more of: [review link]. No pressure either way.”
4. The landing page lists each purchased item with its own review link, plus a tick box: happy for us to quote this. Permission is captured here, not assumed later.
5. Wait 3 days. Condition: no review left? One reminder, by the same channel, shorter, with the link only.
6. Wait 4 days. Condition: still none? Stop and apply pp-review-declined. One request and one reminder. A promoter who did not review is still a promoter and should not be pestered into resentment.
7. On a review being left: write Review Left, Review Platform, Review Rating Public; apply pp-review-left; cancel the reminder; draft a reply to the review and queue it for human approval; and if the quote permission was given and the rating is 4 or 5, add it to the social planner queue for scheduling.
8. If a public review comes in at 3 or below despite the private routing: alert the owner immediately, draft a reply, hold for approval, and open an issue. Something in the gap between the private check and the public review needs understanding.

Exit: review left, or the reminder lapsing.

5. Replenishment Timing and Reorder Prompt

Trigger: Calculated Reorder Date reached.

Conditions: pp-consumable, no pp-issue-open, no active subscription for this SKU, no order containing this SKU since Last Order Date, Reorder Prompt Count for this cycle = 0.

Actions:

1. Move to Replenishment Window, apply pp-reorder-due.
2. Use the better estimate: if Lifetime Order Count is 3 or more and Average Days Between Orders exists, that value overrides the SKU default for this contact. Their behavior beats your table.
3. Prompt one, email: “Going by a normal [Product Replenishment Days] days, you're about five days off running out of [Primary Product Purchased]. One tap puts the same order through: [reorder link]. If you're using it slower than that, tell me and I'll shift the reminder.” The invitation to correct the timing is the most valuable sentence in the build. Set Reorder Prompt Count = 1, stamp Reorder Prompt Last Sent.
4. Wait 3 days. Condition: no order and no reply? Prompt two, SMS. The only SMS in this workflow, mid-morning, inside the window: “[First Name]: running low on [Primary Product Purchased]? Same order, one tap: [link]. Reply STOP to opt out.” Reorder Prompt Count = 2.
5. Wait 5 days. Condition: no order? Prompt three, email, final: the reorder link plus the subscription option framed as never having to think about it again. Reorder Prompt Count = 3. This is the cap; there is no fourth.
6. Wait 14 days. Condition: no order? Move to Lapsed, apply pp-lapsed, remove pp-reorder-due, and hand to the win-back program. Do not loop this workflow. A customer who ignored three prompts needs a different conversation, not the same one again.

Exit immediately on: any order containing the SKU, any reply, subscription started, or pp-issue-open.

6. Reorder Attribution and Subscription Offer

Trigger: order-created webhook containing a SKU with an open pp-reorder-due card.

Actions:

1. Move the old card to Reordered, apply pp-reordered, and attribute to the prompt channel and number from Reorder Prompt Last Sent.
2. Cancel every pending prompt. Increment Lifetime Order Count, add to Lifetime Order Value, and recompute Average Days Between Orders from the actual interval.
3. Swap pp-first-order for pp-repeat-customer if present.
4. Open a new lifecycle card on the new order via workflow 1, with the review request suppressed for any SKU this contact has already reviewed. Asking twice for a review of the same product is the quickest way to look automated.
5. Branch: second or later reorder of the same SKU and no subscription: apply pp-subscription-candidate. Wait 2 days after delivery of that order, then send the subscription offer once: “You've reordered the [Primary Product Purchased] a few times now: want it to just turn up every [interval] instead? You can skip, pause or cancel any time, in two taps.” The cancellation ease is stated up front because it is the actual objection.
6. If the offer is declined or ignored for 14 days: stamp Subscription Declined Date and suppress the offer for 12 months. Once.
7. Branch: subscription started: remove this contact from workflow 5 entirely for that SKU and hand to the subscription lifecycle. A subscriber receiving reorder prompts is the clearest possible sign nobody is watching.

Exit: on completion.

7. Reply Handling and BO Post-Purchase Support

Trigger: inbound reply on any channel from a contact carrying post-purchase-active, or a web chat from a known customer.

Actions:

1. Pause every scheduled step on this contact's cards immediately.
2. Hand to BO with the usage, care, guarantee, returns and subscription knowledge base, plus live order and tracking status.
3. Branch: usage or care question: BO answers from the knowledge base, strictly within what the label and documentation say. On anything ingestible, applied to the body, or safety-related, BO gives the label position and then escalates rather than elaborating.
4. Branch: “still have plenty left” or “ran out already”: BO acknowledges, adjusts Product Replenishment Days for this contact by the stated difference, recomputes Calculated Reorder Date, and confirms the new timing. This is the self-calibration loop and it should be built on day one, not bolted on.
5. Branch: order or tracking question: BO reads the live status and answers. If the carrier shows no movement for 3 days, BO opens an issue rather than repeating the tracking page back at the customer.
6. Branch: wants to reorder: BO builds the previous basket and sends the one-tap link.
7. Branch: wants to pause, skip or cancel a subscription: BO does it, immediately, without a retention attempt. One optional question afterwards about why. Friction here produces chargebacks and public reviews.
8. Escalation: any of refund, chargeback, damaged, injured, reaction, allergic, ill, faulty, unsafe, legal, lawyer or complaint; a compensation request; a second message about the same unresolved issue; pp-vip; or two stalled turns → assign to a named human with the full thread. Anything suggesting harm from a product notifies immediately and bypasses every queue.
9. Resume paused steps only after resolution, and only if at least 48 hours have passed.

Exit: resolution, or human takeover.

8. Issue Resolution and Service Recovery

Trigger: pp-issue-open applied, by a detractor score, by BO, or by hand.

Actions:

1. Suppress every commercial workflow for this contact: reviews, reorders, subscription offers, cross-sells, and any broadcast. One switch, checked everywhere.
2. Move to Issue Raised. Create an urgent task on the customer-service owner, due in 4 business hours, carrying Issue Category, the free text, the photos and the desired outcome from the Issue Report form.
3. Acknowledge within 15 minutes, automatically, naming a person: “Thanks for telling us: that's not the experience we want you to have. [Name] from our team is looking at this now and will come back to you today. You don't need to do anything else.” Speed of acknowledgement matters more here than speed of resolution.
4. Branch: Damaged, Wrong Item or Missing Parts: route to fulfillment, pre-draft the replacement or returns options for the human to approve, and include the photos. BO does not authorize; it prepares.
5. Branch: Late Delivery: route to fulfillment with the carrier status attached.
6. Branch: Quality, Not As Described or Sizing: route to the product owner as well as service, because this is product feedback wearing a complaint's clothes.
7. Branch: any mention of harm, injury, reaction or safety: notify a named senior person immediately by push and SMS, bypass the queue, and log it separately for whatever incident process the business is required to follow. Do not send any automated message beyond the acknowledgement.
8. Wait 4 business hours. Condition: task not actioned? Escalate to the manager. Wait 4 further hours: escalate to the owner. An unresolved complaint is the most expensive object in the business.
9. On resolution: apply pp-issue-resolved, stamp Issue Resolved Date, remove pp-issue-open, move to Satisfaction Checked.
10. Wait 5 days after resolution. Send one follow-up asking whether the fix landed. Nothing commercial attached.
11. Branch: the follow-up comes back positive: after a further 7 days, and only then, the review request may be re-enabled by a human decision. Never automatically. A recovered customer is often the most willing reviewer there is, but that ask has to be a judgment, not a trigger.
12. Resume commercial workflows 14 days after resolution, starting with the reorder path and never with a review request.

Exit: issue resolved and the 14-day cooling-off elapsed.

What is different afterwards

• Review timing matches the product. A consumable is asked about at 7 days, a mattress at 30. The reviews that come back are specific, mention the product, and are useful on the page, because they were requested at the moment the customer actually had an opinion.
• Unhappy customers get a person, not a review form. The private satisfaction check routes 1s and 2s straight to a human with the issue category and the desired outcome already captured, and permanently suppresses the public review request for that order. The customer gets a faster resolution and the business does not harvest its own one-star reviews.
• The reorder prompt is timed to consumption, not to the calendar. Per-SKU replenishment windows, with a head start so the message arrives before the customer runs out, and a per-contact adjustment once their real rhythm is known. This is the half of the build that produces revenue.
• The customer's own cadence overrides your estimate. After three orders, Average Days Between Orders replaces the SKU default. The system gets more accurate per customer over time rather than staying at the launch-day guess.
• Reviews stop being a one-profile problem. Platform rotation grows Google, on-site and third-party together instead of letting one accumulate while the others look abandoned.
• Subscriptions are offered at the moment they make sense (after the second reorder of the same item, when the habit is demonstrated) and offered once.
• Replies are answered. A customer who says I've still got two weeks left is giving you free calibration data. Here that reply moves the next prompt and corrects the field, rather than disappearing into a no-reply inbox.
• The programs stop colliding. A shared frequency budget with cart recovery means a customer is not in two automated sequences at once, which is the single most common way these builds go wrong when added one at a time.
• Lapsed customers hand off cleanly to a win-back program instead of receiving reorder prompts for a product they stopped using eight months ago.

Metrics to watch

• Satisfaction check response rate, and the score distribution. A one-tap check should get a materially higher response rate than any form; if it does not, the email is landing in promotions.
• Review conversion from promoters: reviews left as a share of promoters asked. This, not total review count, tells you whether the request is working.
• Review volume and average public rating by platform, tracked separately so rotation can be reweighted.
• Detractor resolution time, from satisfaction response to Issue Resolved Date. The number that decides whether the private route was actually better for the customer.
• Issue category distribution: a quality and fulfillment report, not a marketing one. Damaged and Missing Parts point at packing; Not As Described points at the product page.
• Reorder rate within the replenishment window, by SKU. SKUs with low rates usually have a wrong Product Replenishment Days, not an unwilling customer.
• Reorder prompt accuracy: how often customers reply too early or too late. Treat this as the tuning signal it is.
• Repeat purchase rate and time to second order, split first-order against repeat.
• Subscription take-up from candidates offered, and subscription retention after three cycles.
• Lifetime order value over time, cohorted by month of first order, which is the only honest way to see whether the program compounds.
• Unsubscribe and opt-out rate on post-purchase messages specifically. If it rises, the sequence has too many touches, not the wrong copy.

The work to do before any workflow is built

• Build the SKU table. Every sellable SKU needs a Product Review Delay Days and, where applicable, a Product Replenishment Days. This is the single biggest piece of preparation in the build and it cannot be skipped or guessed globally. Start at category level. Consumables 7 days to review and a measured consumption window; apparel 10; electronics 14; furniture and bedding 30, then override the SKUs that matter most. A reorder prompt for a 90-day product sent at 30 days is worse than no prompt.
• Decide which SKUs are consumable at all. Anything without a replenishment window gets pp-durable and a cross-sell instead of a reorder prompt. Mislabelling a durable as a consumable produces prompts that make the brand look like it is not paying attention.
• Pick the review platforms and the rotation weighting. Decide where reviews are actually worth having for this business, usually Google plus on-site, sometimes a third-party platform the category's buyers check.
• Name the humans. Who owns a detractor response, who owns fulfillment issues, who owns anything safety-related, and who approves review replies. Every escalation path in workflow 8 needs a named person, not a shared inbox.
• Agree the VIP threshold and what a VIP actually gets, so the task created in workflow 2 has something to do.
• Set the global frequency budget shared with cart recovery and any other messaging build. Decide the total number of automated messages a contact can receive in a week across everything, and build both programs against that one number.

Integrations

• Store platform: order-created, order-dispatched and order-refunded webhooks, product and SKU data including the category, and the ability to generate a pre-filled reorder link for a previous basket. Verify the reorder link specifically; without it the reorder prompt becomes a link to a category page and the conversion is a fraction of what it should be.
• Carrier or shipment tracking: the delivery-confirmed event is the anchor for every timer in this build. If the store cannot provide it, the entire sequence has to run from dispatch plus an estimated transit time, which is materially worse. Treat this integration as a prerequisite rather than a nice-to-have.
• Review platform APIs: Google Business Profile and whichever third-party platform is in scope, for both inbound review capture and reply publishing. Note that some platforms restrict or prohibit API-posted replies; check before promising automated responses.
• Subscription engine, if subscriptions are in scope. The platform's own or a third-party app, with the ability to create, skip, pause and cancel from an external trigger.
• Customer and order history sync for Lifetime Order Count, Lifetime Order Value and the computed Average Days Between Orders.
• Helpdesk or support inbox: the issue path must create a real ticket where support already works, not a parallel queue nobody checks.
• Email authentication: SPF, DKIM and DMARC on the sending subdomain. This build sends several emails per customer per cycle and will expose any deliverability weakness.
• Social scheduling connection for the review-to-social queue.

Numbers and messaging registration

• A2P 10DLC registration before any automated SMS. This build sends a mixture: the satisfaction reminder and the issue acknowledgement are arguably transactional, while the reorder prompt and the subscription offer are unambiguously marketing. Register the use case against what you actually send, and if the split is wide, use separate campaigns. Mis-registration causes silent filtering, which looks exactly like customers ignoring you.
• Marketing consent for SMS must be explicit and separate from the purchase. Buying something is not consent to receive a reorder prompt by text. Collect it at checkout with an unticked box and clear wording, and store the timestamp and the exact wording shown. In the US, SMS marketing without prior express written consent carries statutory damages per message under the TCPA. The reorder prompt is the highest-volume marketing SMS in this build and therefore the highest-exposure one.
• Opt-out handling. STOP, UNSUBSCRIBE, QUIT, CANCEL and END apply sms-opted-out and halt everything instantly. Critically, test that a reorder prompt scheduled 55 days in the future honors an opt-out applied today. Long-dated scheduled steps are where opt-outs most often leak, and a marketing text sent two months after someone opted out is the kind of mistake that generates a complaint rather than an unsubscribe.
• Quiet hours. SMS window 9am-8pm local to the recipient; emails wider. The satisfaction-check and reorder triggers fire on date arithmetic, so they can land at any hour: queue them to the window rather than dropping them.
• Frequency caps. Maximum 3 reorder prompts per cycle, 1 review request plus 1 reminder, 1 subscription offer per 12 months, and no more than 2 automated messages per contact per day across this build and cart recovery combined. Build the monitoring with the caps.

Reviews, compliance and data protection

• Review solicitation rules. Routing unhappy customers away from a public review form is a widely used and generally accepted practice, but review gating (selectively suppressing negative reviews on a platform that prohibits it) is not, and both the FTC in the US and the CMA in the UK have taken action on fake and manipulated reviews. Check each platform's own terms: some explicitly prohibit asking only satisfied customers. Where a platform prohibits it, request from everyone on that platform and keep the private satisfaction check as a service tool rather than a filter. Do not offer any incentive in exchange for a positive review, and if an incentive is offered for a review of any kind, disclose it.
• Quoting customers. Permission for a public quote is captured on the review landing page with a tick box. Do not repurpose a review into an advertisement on the assumption that posting it publicly implied consent.
• Health, supplement and cosmetic products. BO must not give usage advice beyond the label, and any mention of a reaction, allergy, illness or injury escalates immediately to a named person and is logged separately. Product categories like these carry regulatory reporting duties in many jurisdictions, and an automated reassurance in that moment is a serious exposure. Make the guardrail explicit in BO's instructions and test it with adversarial prompts before launch.
• Purchase history is personal data. Using it to time a reorder prompt is profiling under GDPR and similar regimes. Disclose it in the privacy notice in plain terms and make sure there is a lawful basis.
• Sensitive product categories. Where a product could reveal something personal about the buyer, exclude it from SMS and from any message whose preview names the product.
• Subscription rules. Negative-option and automatic-renewal offers are regulated in many jurisdictions, with specific requirements on pre-purchase disclosure, consent, renewal reminders and easy cancellation. The subscription offer in workflow 6 has to meet those requirements, and the easy-cancellation promise has to be true in the interface, not just in the copy.
• Retention and erasure must cover order history, satisfaction scores, issue records and photo uploads, not just the contact row.

None of this is legal advice. Review-platform terms, review-solicitation and endorsement rules, SMS consent standards, subscription and auto-renewal law, and reporting duties for health, supplement and cosmetic products all vary by jurisdiction and change. Confirm the specifics with the client's own counsel before launch, particularly the review-request approach and anything touching an ingestible or applied product, and keep a written record of what was agreed.

Scoping

What this build costs depends on the size of the SKU table, whether delivery confirmation and reorder links are available, and whether subscriptions and third-party review platforms are in scope. Book a call at bookings.appbo.io to scope it against the actual catalog.