Hypertune · email programme

Hypertune email: what it does today, what to change

What our emails do today, and what to change · 22 September 2026

Prepared 22 September 2026 by Vinson Leow, for Austin. Sources: the Klaviyo account, Stripe's failed-payment records, the live website. Last 90 days unless stated. "Paid" always means a payment that went through in Stripe, never an open or a click. Grey boxes explain the technical terms; skip them if you do not need them.

1. One page

Email earns about $1,650 a quarter, about 1% of revenue. 180 of the 203 payments credited to email came from the failed-payment flow, and most of those were Stripe retrying the card on its own, not the emails.

Delivery is fine: 99.7% delivered, zero spam complaints. The problems are in how the sequences are built.

#FindingFix
1The failed-payment flow restarts on every Stripe retry, has no link to fix the card, and drops 97% of people after two days.Six changes to the rebuild already in progress. Section 2.
2Klaviyo reports 0% conversions on everything because it is set to count a website event that can never happen.Change one setting to "Successfully Paid". Ten minutes. Section 4.
3The 8 September "50% off yearly" email went to current paying customers, and to people part-way through a cancel sequence.Standing exclusion rules on every campaign. Section 5.
45,000 people start a trial each quarter and get one email. The "your trial ends soon" email exists and is switched off.A five-email trial sequence. Section 5.
5Both cancel sequences are built to send a different email by reason for leaving. The reason is never recorded, so those emails have never sent.Kevin connects the reason field. No email changes. Section 5.
6Klaviyo's tracking script is not on hypertune.gg.One line in the site layout. Kevin or Kamil.

No new sequences are needed. Your decisions are in section 8.

Terms. Klaviyo is the email system. It receives events from Stripe (paid, payment failed, trial started, cancelled) and sends emails in response. A flow is an automated sequence started by one of those events. A campaign is a one-off send to a list.

2. Failed payments: what changes from the 17 September plan

Agreed on the 17th: seven-day window, three emails, an in-app reminder, dashboard shows recovered customers and dollars. That stands. Reading the actual flow step by step, and pulling Stripe's failed payments by decline reason, added six build details. The builder needs these before it ships.

#ChangeWhy
1One entry per customer per 30 days.Stripe retries a failing card up to four times over seven days, and each retry restarts the flow today. Result: 27,406 emails to about 3,800 people, five each. A seven-day flow without this rule sends more, not fewer.
2Every email has one button, "Update payment method", to the billing page.Today's first email says "try a different card" and links only to Discord, three times. 27 clicks in 90 days.
3Everyone stays the full seven days. The decline reason changes the wording only.Today, after 48 hours only "insufficient funds" continues; everyone else is dropped. 94 people got a third email in 90 days. Insufficient-funds customers recover at 1.8%; every other reason at 2 to 8%. We keep talking only to the group least able to fix it.
4Send on days 0, 3 and 7 (0, 1, 3, 7 if four emails). Never drop day 7.Stripe cancels the subscription on day 7. That email is the last chance.
5Pause the "free month" offer.94 sends, zero payments. It costs a month of revenue and has no measured return.
6Set the flow to measure "Successfully Paid", 30-day window.Klaviyo then shows the recovery rate itself. Same fix on the other five flows.

Terms. Re-entry is whether a person is put back at the start of a flow when the trigger event fires again. Today it is, on every retry. Decline reason is the code the bank returns with a failed payment ("insufficient funds", "expired card", "do not honor"). Conversion metric is the one event Klaviyo counts as success for a flow; ours is set to a website visit that never registers (section 4).

In-app reminder, as agreed: a banner in the app from the day of failure until the card is fixed, same button. The app keeps a session open while running, so this reaches people who never open email.

Two Stripe settings to check (Kevin, five minutes): Smart Retries on; Stripe's own "email customers when a payment fails" off, or customers get two sets of emails.

Worth: about 3,800 failures a quarter, 2.5% recover today. 10% is ordinary once there is a card-update link. Roughly 280 saved subscriptions and $2,000 a quarter on first renewals, more over the months after.

3. The numbers

FlowStarts whenEmails sentPeoplePaid afterValue
Payment faileda payment fails (every retry)27,406~3,800180$1,268
Account createdsign-up with no trial yet24,456~8,5006$128
Trial cancelleda trial is cancelled16,983~5,90010$116
Trial startedfirst free trial10,537~5,0001$10
Became paidfirst successful payment8,582~4,6002$10
Subscription cancelleda paid subscription is cancelled3,692~1,3004$115
Total91,656203$1,647

Reading the table. "Emails sent" counts every email. "People" is how many individuals received them. Where the first is several times the second, the same people were emailed over and over (the re-entry problem). "Paid after" is a Stripe payment within 30 days of an email, so the 180 on failed payments includes Stripe's automatic retries succeeding while an email happened to be in the inbox. Every flow already stops emailing a person once they pay.

One-off campaigns in the same window:

SendDateWent toExcludedDeliveredClickedPaidUnsubscribed
Beta over, email 123 Junwhole listnobody16,7148%(outside window)1.24%, about 200 people
Beta over, email 228 Junopeners of email 1anyone who paid in the last 7 days4,35428%11.5%
"Go Hyper for $60/year"8 Septwo "cancelled" listsnobody6,5760.15% (10 clicks)15 ($135)0.14%

15,487 people can be emailed. 8,473 who never paid and went quiet were removed from mailing in June; that rule still runs. Bounces under 0.7%, spam complaints zero.

4. Why Klaviyo says 0%

Klaviyo's conversion setting for this account is Active on Site, meaning "visited hypertune.gg". That needs Klaviyo's tracking script on the website, and it was never installed. The event never fires, so every flow and campaign reads 0%, including the ones that produced payments.

Klaviyo already receives every payment from Stripe. Nothing needs building. Two changes:

  1. Set the conversion metric on each flow, and the account default, to Successfully Paid, 30-day window. Ten minutes. Every Klaviyo report then shows real money.
  2. Put Klaviyo's script on the site (one line; Kevin or Kamil). This does not fix reporting. It lets Klaviyo see what people do on the site, which enables later sequences such as "visited pricing, did not buy".

Sowmya's 22 September review read the 0% off the dashboard and concluded tracking was missing. Her design points were right; the conclusion was the wrong dropdown.

5. Trials, cancellations, the 8 September campaign

Trials. 5,000 people a quarter start a trial and get one email: "Welcome to a faster, more powerful PC". The day-2 and day-4 emails, including "IMPORTANT! Your free trial ends soon", are switched off, and have been since about mid-August. Nobody starting a trial today is told it is ending. Proposed: five emails across the seven days (build sheet C3): day 0 download and first optimise; day 1 first win; day 3 anti-cheat and reversibility; day 5 game profiles; day 6 "trial ends tomorrow", one price, $59.99 yearly.

Cancellations. Both cancel flows send "Quick question..." at five minutes, then on day 3 are meant to branch by reason: too expensive gets a discount, too complicated gets done-for-you setup, no improvement gets a fix-it email. None of those three has sent once in 90 days. The field they read, "Reason Left", is never filled in, so everyone gets a generic "tell us about your experience". Fix is Kevin's: find the cancellation survey (app or Stripe page) and write the answer to Klaviyo. The flows then work as designed with no email changes. Also, the paid-cancel flow reuses the trial-cancel email; it should acknowledge they were a customer.

8 September campaign. "Go Hyper for $60/YEAR" went to two lists with no exclusions and Smart Sending off. The second list was created four minutes before the send and its definition includes "started a paid subscription in the last 90 days and has paid in the last 90 days". That is a current customer. Stripe shows 3,213 subscriptions started 10 June to 8 September still active on the 8th; some were offered half price on yearly while paying full monthly. Separately, 729 people who had cancelled in the previous two weeks were mid-way through a cancel sequence when it landed. The sender-name test (4 clicks vs 6) proves nothing. Result: 15 payments, $135. In June the team excluded recent payers; September skipped it.

Rules for every campaign from now on: exclude anyone who paid in the last 30 days; exclude anyone inside a flow; Smart Sending on; one job per email; the button goes to one tagged page, not the homepage. And fix the "Paid & Cancelled" list by removing the "started a paid subscription" condition.

Terms. A segment is a saved list definition ("everyone who cancelled in the last 90 days"). Smart Sending is a Klaviyo setting that skips anyone already emailed in the last 16 hours. A branch is a fork in a flow: the person goes down one path or another depending on a condition, here the reason they left.

6. Housekeeping

7. What not to test next

8. Decisions needed from you

  1. Approve the six changes to the failed-payment build (section 2), and confirm who builds it and when.
  2. The billing page URL for the button: Stripe's hosted portal or the account page.
  3. The campaign rules in section 5 as standing policy.
  4. The trial sequence: five emails, ending day 6 with one price, $59.99 yearly. I write the brief.
  5. Kevin to find why "Reason Left" is never recorded and connect it.
  6. One sender name; publish or delete the three drafts.
  7. Who puts Klaviyo's script on the site.

Build sheet (for the implementer)

For whoever makes the changes in Klaviyo. Terms as used in the Klaviyo interface.

Terms. Exit filter: a condition checked before every send; if true, the person leaves the flow. All six flows have one today: leave once "Successfully Paid" has happened since entering. Keep it everywhere. Trigger split: a fork based on a property of the trigger event (here the decline reason). Conditional split: a fork based on a property of the person (here "Reason Left").

AIn order

#ChangeOwnerUnblocks
1Payment-failed flow: re-entry once per 30 days; card-update button in every email; reason changes copy only, not who continues; days 0/3/7 or 0/1/3/7; pause the free-month A/B; conversion metric Successfully Paid 30d. In-app banner day 0 until paid.Email implementer; Kevin for banner and portal URLReal, measurable recovery
2Conversion metric Successfully Paid (30d) on all six flows and as account default.Email implementerKlaviyo reporting shows money
3Campaign policy: exclude Successfully Paid last 30d; exclude "in any flow" last 14d; Smart Sending on; fix "IB // Paid & Cancelled users" (remove the first-paid-subscription condition).Email implementerNo offers to paying customers
4Trial flow: five emails per C3, including the trial-ending email now in draft.Vinson briefs; implementer buildsLargest untouched audience
5Reason Left profile property: find the source (app cancellation survey or Stripe cancel page) and write it to the Klaviyo profile on cancel.KevinCancel-flow branches start working
6Klaviyo.js in the site layout (public key from Settings > API keys).Kevin or KamilSite-behaviour triggers later
7Became-paid flow: publish or delete the three "Austin From Hypertune" drafts; one from-name account-wide.Austin decidesConsistency
8Template pass, 21 templates: button destination, price, first_name default, footer image typos.ImplementerHygiene
9Delete the two December draft flows.ImplementerNo confusion with the new build
10Later: "Account Created" event from Clerk; "first optimise" event from the app.Kevin, with telemetrySkip steps already done

BNew sequences only

SequenceTriggerEmailsWhy it does not exist
Signup incomplete (optional, later)Account created, no trial after 2 hoursHour 2: start your trial, one button. Then hand to Account created day 1.Day-1 email already does this at 36% open; low priority.
Engaged product update (campaign cadence, not a flow)Monthly, to opened or clicked in 60 days, not cancelled, not in dunningOne job per send. 28 June is the control (28% click).No newsletter to engaged customers exists.

CEach existing flow

C1. Payment failed (Un6Nkh). Trigger: Failed Payment. Re-entry: not within 30 days. Keep the existing exit filter. Conversion metric: Successfully Paid, 30d.

DayTodayChange
0"Ugh oh, your payment declined"; Discord links onlySubject "Your Hypertune payment didn't go through". One paragraph, one button "Update payment method" to the portal. Two copy versions by decline reason: insufficient funds ("we'll retry on [date]; another card if easier"); all others ("your card was declined; update it here").
1Features emailReplace: still not through, same button, what happens on day 7. If three emails is fixed, drop this and let the in-app banner cover it.
2Insufficient-funds-only split; free-month A/BSplit sets copy only; nobody exits here. Pause the A/B.
3nothingSame ask, shorter.
7nothingLast notice: subscription closes today unless the card is updated. Same button.
In-appnothingBanner from day 0 until Successfully Paid. Same button, same URL.

C2. Account created (Rwzvi6). Keep trigger, filter, timing. Day 8: remove the free-month offer; make it "start your 7-day trial" with the anti-cheat line.

C3. Trial started (SDXETb). Keep trigger, 7-day re-entry, exit filter. Conversion metric Successfully Paid.

DayJobButtonSkip if
0You're in. Download and run the first optimise.Open Hypertune
1If no optimise yet: the ten-minute first win.Run the optimiserfirst-optimise event, when it exists
3Trust: reversible, anti-cheat safe (Riot, EAC, BattlEye).How it stays safe
5Game profiles: pick your titles.Apply a profile
6Trial ends tomorrow. One price, $59.99 yearly, no second widget.ContinueSuccessfully Paid

The existing day-2 and day-4 drafts can become day 1 and day 6 with edits.

C4. Became paid (VvFhmh). Keep trigger, once-ever entry, cancellation exit, trial/direct split. Publish or delete the drafts. Day 10 becomes conditional on "no optimise run" once that event exists.

C5. Trial cancelled (YAQBAv). Keep trigger and exit. Once Reason Left is populated the day-3 branches work as designed. Day 13 free month: keep, measure on Successfully Paid; if under 5 paid a quarter, replace with "what changed since you left". Delete the two finished A/B shells and the draft.

C6. Subscription cancelled (XK844V). Same as C5. Email 1: acknowledge they paid ("you were with us for N months"); current copy is the trial version reused.