Post-Purchase SMS Automation That Attributes Its Own Revenue

Post-purchase SMS automation is a set of timed texts and emails that fire after an order: a thank-you, a delivery check, usage tips, a reorder nudge. It earns its keep only if it can show which sales it caused. Most tools credit themselves generously, so the useful build is a journey that carries its own receipts: a message ID on every send, an order ID on every purchase, and a held-back group that never gets the texts.

We built part of that for a D2C brand in our group. This post covers the job, the steps, and a plain account of what is not yet running unattended.

What is the job, and why does attribution break it?

The job is to talk to a customer between their first order and their second, at the right moments, without a person pressing send. The failure is not the texts. The failure is the scoreboard that says the texts worked.

Take a vendor most stores use. Klaviyo’s help documentation, read in October 2026, says SMS conversions are counted if the message was delivered before the purchase. Its default window for accounts created after 9 October 2024 is five days, for email and SMS alike. An email counts only if the recipient opened or clicked it, and Apple Mail Privacy Protection opens count unless you exclude them.

Read that carefully. A customer who was always going to reorder, and who happened to have a text delivered two days earlier, is a conversion. That is not fraud. It is a definition, and the definition favours the sender.

What does the agent do, step by step?

A tomte, our word for one production agent with one defined job, owns the journey from the order to the second purchase. Its steps:

1. Listen to the order feed. Every order, fulfilment and refund event arrives and is tied to one customer record.
2. Check consent before anything else. No recorded permission for a channel, no message on that channel.
3. Split before sending. A random slice of eligible customers is held back at enrollment. They get no journey texts. This is the only way to know what the journey added.
4. Send on schedule. Thank-you after the order, a delivery check after shipping, usage tips in the following weeks, a reorder prompt later.
5. Skip when the world changed. A refund, a second order, or a stop request removes the customer from the remaining steps.
6. Stamp every message. Each send gets an ID that is written next to the customer and the step.
7. Credit by evidence. A later order counts for a step only after a tracked click, inside a window you chose in writing.
8. Report the difference. Revenue per recipient for the journey group, minus revenue per recipient for the held-back group, per step.

Step 8 is the number that matters. Step 7 is the one most tools skip.

Delivered, clicked, or incremental: which one is revenue?

Three definitions of “this text made money” sit in the market. They produce very different totals.

Definition	What counts	Overstates when
Delivered before purchase	Any buyer who got a text inside the window	Loyal customers reorder anyway
Clicked before purchase	Buyers who tapped a tracked link	Habitual buyers click a link they would have typed
Incremental vs holdout	Journey group revenue minus held-back group revenue	Almost never, if the split was random

The third row is the only one that answers “what would have happened without the texts”. It is also the only one that needs you to withhold messages from real customers on purpose, which is why dashboards rarely offer it.

This is the same trap we wrote about for ad platforms in true ROAS tracking: the party doing the selling should not be the party keeping the score. The method carries over. Compute the number from your own order records, not from the sender’s report.

What changed when the order trail got fixed?

One concrete example from our own build. A flow that starts on shipment needs to know who the shipment belongs to. The fulfilment notification from the store carried no customer at all. A journey triggered on it would have enrolled nobody, and every dashboard would have shown a quiet, healthy zero.

The fix was to look the buyer up from the original order event, using the order ID. The same lookup linked refunds to customers, so a refunded buyer stops receiving reorder prompts. It is a small, unglamorous join, and it decides whether attribution is possible at all. It is also the pattern behind an agent that says it finished but did not: a status that looks fine while the link underneath is missing.

What do the rules say about opt-out?

Consent and stop requests are not an optional feature of this build. They are the first gate. The regulator pages below are the ones we read for this run; this is a summary of public documents, not legal advice.

For texts to US numbers, the Federal Communications Commission governs revocation under 47 CFR 64.1200(a)(10). Its public notice DA 24-1068 records that compliance with the 2024 revocation rules was required as of April 11, 2025. Its order FCC 26-67, adopted September 30, 2026 and released October 1, 2026, records that the “revoke all” provision had been delayed by waiver until January 31, 2027.

The same order lets callers designate an exclusive way to revoke consent, chosen from the three methods in the rule, instead of honoring every request made in any reasonable manner. A caller that designates none must keep honoring requests made in any reasonable manner.

The order says the change takes effect 30 days after Federal Register publication, and the specific date had not been announced when we read it. The rule text also requires honoring a request within a reasonable time not to exceed ten business days, and the same order opens a further rulemaking on revisiting that timeframe and on requiring two-way texting.

For email, the Federal Trade Commission’s CAN-SPAM guidance says to honor an opt-out within 10 business days, and states that each separate email in violation is subject to penalties of up to $53,088.

The practical build rule: the agent writes the stop request to the consent record at once, and checks that record before every send, failing closed if the lookup errors.

Where does our own version stop?

Short answer: the pieces exist, the proof does not, and we will not dress that up.

• The email flows we rebuilt for the brand, including a three-message post-shipment sequence, are built and still held as drafts. As of our last check they have not sent to a live audience.
• The text journey that does run today runs on an older system, on a schedule, without anyone pressing send. It sends. It does not attribute.
• Its reports can only be read by querying the database directly. No reporting surface shows revenue per step, and no held-back group exists yet.
• Our own review of that older system found a stop-reply gap: the send code read an opt-out table, and nothing in the deployed code wrote to it. A fix was drafted and set behind a switch. We are not claiming it is on and verified.

We tell you this because proof over promises cuts both ways. A journey that sends daily is not the same as a journey that proves it earns. The first is a cron job. The second is the build this post describes.

What would it cost as a Sprint?

A post-purchase journey agent with consent gate, holdout split, message stamping and a per-step report is one system with one job. That is a standard AI Workforce Sprint: from $9,500 fixed, four to six weeks, built on your own accounts and handed over with documentation and a recorded walkthrough. The scope is written before work starts.

For a sense of how the honest-number approach lands, see the ad-spend truth case, where the platform said 4.87x and the ledger said between 0.33x and 0.50x.

Messaging provider accounts and credits sit on your own accounts.

Start async

If you run post-purchase texts or emails and cannot say what they added beyond what customers would have bought anyway, describe your setup at /start. We reply in writing within one business day, with no meetings and no call. Start async.