The people who tried to give us their number

In Klaviyo a phone number is a profile attribute. Consent is a separate subscription write. Anything that writes profile data can set phone_number and never touch consent: a Shopify order sync, a form submit, an identify() call, a CSV import. Two different writes, and only the second one grants permission to text anybody.

That is why this stayed invisible. Nothing malfunctioned in a way that would raise an alarm, and nothing unlawful happened by storing the number. The proof that no consent was ever taken is in the data: sms_method is None on 100.0% of all 39,918 profiles. Klaviyo stamps a method (FORM, SHOPIFY, TEXT, API) every time consent is granted or changed. A blank on every single record means there has never been a consent event of any kind on any of them.

2,265 of the 5,850 have bought from us before, carrying $281,310 of historic revenue. The other 3,585 have never ordered, so for them an SMS opt-in is the first commercial relationship rather than a deepening of one.

1. Make the cohort addressable. Done These 5,850 cannot be expressed as a Klaviyo segment: the condition would have to be “submitted form step X”, and T4qceY submitted_form_step is rejected as a metric id in the segments API. So it is a static list: SRLmDN “SMS Gap Recovery - tried Jun-Aug 2026 (never confirmed)”, 5,850 profiles, verified. I added them by list membership only, which does not touch consent and fires no confirmation emails. Checked before and after: no live flow triggers on it, so nothing auto-sent. A 100-profile sample reads 100% email SUBSCRIBED and 100% SMS NEVER_SUBSCRIBED, which is exactly the intended audience.
2. Point the page at a real offer. The one thing on /claim I could not write. Whatever it is, it has to be worth typing ten digits for, and it has to be honoured by a code that actually exists.
3. One email, then one reminder. Single purpose, single CTA, straight to /claim. No product education, no bundling it into a promo. The subject should reference that they already started this, because they did, and that is the only thing that makes this email different from a cold SMS ask.
4. Send to a 1,000-person slice first, weighted to the 2,265 existing customers, and read the real conversion before committing the rest.
5. Add the passive net. A phone-only Klaviyo popup targeted at the same list, for anyone who visits without clicking the email. Klaviyo's own benchmark for phone-only forms aimed at existing email subscribers is 10 to 13% Klaviyo benchmark.

On pre-filling the number for Group A: we could pass the 1,020 known numbers into the page as a URL parameter so they only have to tap confirm. I would not. It puts a phone number in a query string, which Vercel and every intermediary logs, and a number typed at the moment of consent is a cleaner consent record than one we asserted on their behalf. Ten digits is a low price for a defensible record.

One dedicated campaign to SRLmDN SMS Gap Recovery - tried Jun-Aug 2026 (never confirmed), single purpose, one CTA, then one reminder to people who did not click. Explicitly not folded into a promo or a newsletter, for two reasons. The only thing that makes this email legitimate rather than cold is that it references something they started, and that argument does not survive being bundled with a sale. And a single-purpose send gives a clean conversion read, which is the whole point of running this cohort before the bigger list.

Sequence: send to a 1,000-person slice first, weighted to the 2,265 existing customers. Read the real opt-in rate. Then decide on the remaining 4,850. The email itself still needs to go through the framework audit and the repo pull; I have not drafted it, and it should not be improvised.

/claim as it stands is a working prototype, not the production page. The mechanism is proven and the code is final. What has to change before it goes in an email:

1. Move it off vercel.app onto blackforestsupplements.com. This is the one non-negotiable. Putting an unfamiliar domain behind the only CTA in an email to 5,850 people costs us deliverability and reads as phishing to anyone paying attention. The page is a single self-contained HTML file with inline JS and no build step, so it drops into a Shopify page template as-is. The Klaviyo client endpoint is called from the browser and needs no server, so hosting it first-party changes nothing about how it works.
2. Set the offer. The one line I could not write. It has to be worth typing ten digits for and it has to be honoured by a code that actually exists.
3. Pre-fill the email field from the Klaviyo link, not the phone field. Passing the email as a URL parameter is standard practice and removes half the typing. Passing the phone is not: it writes a mobile number into a query string that Vercel, Shopify and every intermediary logs, and a number typed at the moment of consent is a stronger consent record than one we asserted for them. The trade-off on pre-filled email is that a forwarded link could attach someone else's phone to that email, which is a small and well-understood risk in exchange for a real lift.
4. Keep the disclosure exactly as it is. The TCPA language on the page is what makes a single-opt-in capture defensible. It is not decoration and it should not be shortened for design reasons.
5. Test end to end with one real number before the send, and confirm the profile lands on VdWm2S On-Page SMS Subscribers with SUBSCRIBED and a custom_source of “SMS gap recovery”, so the cohort stays attributable afterwards.

After the campaign, the same page is the destination for the 19,970 in RCm4nZ SMS Recovery · phone on file, never SMS-opted-in, email-reachable, and the same JS is what a phone-only on-site popup would do. It is one asset serving all three.

Nothing in a form points at it any more, but +1 888 302 6840 still accepts inbound keywords and SUmgWj SMS Subscribers is still gaining profiles. Anyone working from a saved message, an old screenshot or a cached page still lands in a list no flow listens to.

The form carries a PROMOTIONAL_SMS_CHECKBOX labelled “Check this box to receive promotional marketing texts”. Over 1 to 20 August it took 786 submits, and the checkbox came back ticked 509 times and unticked 273 times. So about 35% hand over a phone number without ticking the promotional box.

Those people get transactional consent only. The profile reads sms.transactional.consent = SUBSCRIBED and sms.marketing.consent = NEVER_SUBSCRIBED, which is exactly the pattern in the sample: 25 of 180 sit in that state. That is the form working as designed, not a fault, and it is a legitimate ongoing contributor to the pool. If we want more of that 35%, the lever is the checkbox copy and placement, not the opt-in setting.

Every fault on this page is detectable from the API. Every one of these faults is detectable from the API in about two minutes: for each live form, resolve the action's list_id, assert it exists, assert its opt_in_process, and assert SUBSCRIBE_VIA_SMS does not appear. That is worth running on a schedule rather than after the next collapse. Nothing on this page needed a person to notice a revenue dip first.

consent_type sets what a form may grant. A PROMOTIONAL_SMS_CHECKBOX component decides whether the promotional half is actually granted on a given submit. NAD+ EARLY ACCESS has one; the three PROMOTIONAL_ONLY pop-ups do not, and do not need one.

So a form set to “Transactional & promotional” with the box left unticked produces a transactional-only subscriber. That is the real mechanism on that form, and it accounts for 35% of its submits.

I said promotional-only costs us the transactional opt-in, then that it does not, then that the mechanism was unexplained. It is now traced, and both earlier statements were incomplete.

For almost every profile, transactional consent is never granted. It is a mirror of marketing consent. On profiles sourced by the promotional-only pop-ups the transactional block reads consent_timestamp: null and method: null while still saying SUBSCRIBED. No transactional consent action ever happened; the field simply reflects the marketing state.

Marketing SUBSCRIBED gives transactional SUBSCRIBED. Marketing UNSUBSCRIBED gives transactional UNSUBSCRIBED on 182 of 182 in the sample. Marketing NEVER_SUBSCRIBED gives transactional NEVER_SUBSCRIBED. It tracks in every direction.

The only real transactional records in the account come from one form. The metric RgFTui “Subscribed to Text Messaging Transactional” reads zero every month up to June 2026, then 354 in July and 778 in August. All 781 August events carry form_id: VCfHT8 and permission_name: sms_transactional, method form. NAD+ EARLY ACCESS is the sole source, because it is the only form set to “Transactional & promotional”. 911 profiles now hold one.

That record buys one specific thing: it survives a marketing opt-out. Of 212 sampled profiles in the explicit-grant cohort, all 212 carry a real transactional record, and of the 14 who have since unsubscribed from marketing, 10 kept transactional consent, which is 71%. In the derived population the same opt-out takes transactional with it every time.

The recovery list is SRLmDN, named “SMS Gap Recovery - tried Jun-Aug 2026 (never confirmed)”, holding 5,850 email-reachable people who acted on the SMS step and never completed.

So the overlap is small on purpose. SRLmDN SMS Gap Recovery - tried Jun-Aug 2026 (never confirmed) is an email-keyed audience and this cohort is overwhelmingly phone-only. These are two different populations reached two different ways, and only 162 people need suppressing between them.