---
name: lifetime-deal-to-recurring-plan
description: Produces the dated ninety-day plan for what happens after a lifetime-deal cohort lands, when a product has many users, no recurring revenue and an open refund liability. Covers the ordering constraint that fixes affiliate payout terms against the refund window before any affiliate is recruited, the venue rule that puts review incentives off the marketplace rather than on the listing, the cap upsell that sells more of what a buyer already hit the limit on, the missed-the-deal standing reply, the community and second-launch decisions, and a branch for a cohort too new to segment. This skill should be used when a deal window has just closed, when affiliate commission terms are about to be published, or when somebody proposes building a new feature to sell to the cohort.
---

# Lifetime deal to recurring plan

## The claim this skill is built on

The day a lifetime-deal window closes you are cash-rich, revenue-flat and holding a refund liability against a cohort that has already paid you everything they will ever pay you. Nothing in your normal playbook is written for that position, because every part of it assumes the customer has a next payment.

The obvious plan gets each item right and the order wrong. Launch the affiliate programme first, because it is exciting and the buyers are enthusiastic today. Ask for reviews where the buyers already are, which is the marketplace listing. Then build something new and sell it to them. Two of those three destroy value, and the third quietly puts the listing at risk.

Three dependencies govern the ninety days:

1. **Affiliate payout terms are set against the refund window before a single affiliate is recruited.** Pay before the window closes and you pay commission on revenue that then reverses, and you cannot retroactively tighten terms with people you have already signed.
2. **Review incentives are prohibited on the marketplace itself and permitted off it.** The venue decides whether the same offer is a policy breach or ordinary practice.
3. **The upsell that works raises the cap the deal imposed. It is not a new feature.** A buyer who hit a limit has demonstrated the value. A buyer offered a feature has demonstrated nothing.

Everything below is an attempt to keep those three in order.

## Part one. Read somebody else's refund policy before you write anything down

The clock is not yours. Day 0 is the last day of the promoted window, or the last redemption if codes trickle in afterwards, and everything downstream counts from there.

**The rule: the affiliate payout period must be at least as long as the refund window, plus a settlement buffer for the payment provider.** Not the same as. At least. Shorter and you are paying commission on purchases that are still reversible.

One large lifetime-deal marketplace has run a sixty-day return policy on deal purchases and paid its own affiliates on net-sixty terms, which is the same rule applied to itself. Treat that as reported partner practice as of August 2026 rather than as a published rule you can rely on: windows differ by marketplace, they have changed, and no marketplace publishes a partner-facing table of any of this. Read the current policy, save the URL, and write down the date you read it.

**The dependency, stated plainly.** Recruitment cannot start until the payout day exists. The payout day cannot be computed until the refund window is known. The refund window is published by somebody else and can change between deals. So the first task of the ninety days is a policy read, and it is genuinely the first task, not a formality to be done in parallel with the fun part.

**The trap that catches people who already know the rule.** The window governing your payout day is not the one in your terms of service. It is the longest refund promise attached to the sale being commissioned. Deal launches routinely mirror the marketplace's guarantee into the launch email, the listing comments and the support macros, because matching it makes the offer feel equally safe. Fourteen days in the terms and sixty days in the launch email means sixty days, and the person computing the payout day reads the terms. Go and read what you actually promised, in the launch email and on the listing page, before you compute anything.

**Why the sequence is one-way.** A payout term published and then lengthened is a term change delivered to people who signed the old one. There is no version of that message that reads as anything other than bad faith, and the affiliates it goes to are disproportionately your best customers, because that is who you recruited first. Setting a longer term at the start costs nothing, because nobody has been promised anything shorter.

## Part two. The dated runway, and what each window depends on

Day 0 is the close of the promoted window.

**Days minus 14 to 0, inside the window.** Nothing new starts. The only work is capturing what you will need later: every redeemer with email, tier and timestamp, and the review sequence live so buyers are asked while they are still interested. If the sequence was not live during the window, accept that the early buyers' best moment has passed and plan a one-time catch-up rather than pretending otherwise.

**Days 0 to 7. Terms.** Read and date the refund policy. Establish the longest promise you actually made. Compute the payout day and publish it as a range that already includes your payment run, because a monthly run adds up to another month on top of the computed day. Write the clauses. Recruit nobody. Depends on: nothing you do not already have.

**Days 0 to 14. Missed-the-deal replies.** The standing reply goes into the support macros on day 0, because the inbound starts the day the window closes. Depends on: a decision about the discount, which takes an hour.

**Days 7 to 14. Affiliate recruitment opens.** Depends on: the payout day existing and the clauses being written. This is the dependency the whole file is built around.

**Days 7 to 28. Review distribution.** Depends on: a dated policy check per destination. Independent of the affiliate work, so it runs alongside.

**Days 14 to 56. Monetisation.** The cap upsell depends on usage instrumentation, which depends on having been switched on before you needed it. If it was not, this window is where you instrument and the upsell moves to days 45 to 90.

**Days 21 to 90. Community.** Depends on nothing except somebody owning it, which is why it slips.

**Day 60 onwards. The second-launch decision.** Depends on refunds having settled, so the numbers you take to the conversation are real.

**Around day 90. The first true reconciliation.** A sixty-day window plus a settlement buffer plus a monthly payout run puts the first commission on the earliest post-deal sales somewhere near here. That is the point at which you learn whether the programme is profitable, and it is much later than anybody plans for.

## Part three. Terms first, recruitment second

Pick one commission structure and write it down before anybody sees it.

- **Flat.** One rate on every sale. Simple, and every exception you write becomes a support conversation later.
- **Split by customer state.** A higher rate on a new buyer, a lower rate on a returning one, because without the split a partner's cheapest route to commission is pointing their existing audience at a purchase those people were making anyway.
- **Recurring.** A share of every subscription payment, capped at a stated number of months or running for the life of the account. This is the structure worth having if you sell subscriptions and your competitors sell one-off licences, because it is the only offer they cannot match.

**Then recruit, in this order.**

1. **Your published reviewers.** People who left a detailed public review during the deal have demonstrated enthusiasm and the willingness to write, and the second is much rarer than the first.
2. **Buyers already promoting your deal on the marketplace's own affiliate code.** They exist after every launch. Ask them to swap the link for yours. It costs one message and converts a promoter who is already promoting.
3. **A signup link inside the product**, where your users actually are.
4. **An invitation inside the account-creation email sequence**, which keeps recruiting when nobody is working on it.

**Do not over-engineer the placement.** One operator reported an affiliate link sitting at the bottom of a page, below every comment, in small faded type, that still produced meaningful signups for years. That is a single-account observation rather than a rule, and the point it supports is only that placement is not the binding constraint. The terms are.

**Two things are different after a deal.** Your affiliates are drawn from a cohort that holds thousands of unused or partly used codes, so self-referral through a second account is not a theoretical clause, it is the obvious move for a few hundred people. And the sales they produce are governed by your refund promise, not the marketplace's, which is precisely why part one insists you find out what that promise actually says.

**On attribution, honestly.** Operators consistently report that tracked affiliate links account for a small share of post-deal referral revenue and untracked word of mouth for a large one. The magnitude varies and the single-account figures floating around do not reconcile with each other, so take the mechanism and drop the number: tracked attribution understates this channel badly. The operational consequence is specific. Do not kill an affiliate programme on attributed revenue alone in the first ninety days, because the attributed number is the smaller half of the answer.

The clause list, the kit and the full payout arithmetic belong to the affiliate programme method and are not restated here.

## Part four. Reviews, and the venue rule

You finished the deal with reviews trapped on one listing. The job is moving that proof to the two or three destinations your category's buyers actually check.

**The distinction that catches people out: incentivised reviews are prohibited on the marketplace during the campaign and permitted afterwards on third-party sites.** The mechanism is worth stating carefully, because the two halves have different owners.

On the marketplace, the ratings are the signal its own buyers use, so it protects them. The prohibition binds the listing rather than you personally, and enforcement looks like pulled reviews, a flagged listing, or simply not being run again. Off the marketplace, the constraint changes hands entirely: it becomes each destination's own published policy plus the consumer-protection law on incentivised endorsement in your jurisdiction, several of which were tightened between 2024 and 2026. Some destinations prohibit any incentive. Some permit a token with disclosure. **Each platform sets its own rule, so confirm it and never assume it**, record the URL and the date you read it, and if you cannot verify a destination's current position before the campaign date, run that destination with no incentive at all.

Two rules do not change with venue. **A reward may be for leaving a review and never for a positive one**, so the wording is explicitly "one star or five stars, your genuine experience". And no sentiment gating: you may add a support route for unhappy customers, you may not divert them away from the review form.

**Timing beats volume.** The cohort is at peak interest roughly 24 to 48 hours after purchase, which is an observation from one operator's own sequence rather than a benchmark, and it is worth testing because it is counterintuitive: the instinct is to wait until people have used the product properly. Tag the cohort automatically at that point, route them into a dedicated sequence, point them at a step-by-step page rather than writing instructions in the email, and let the ask escalate across several messages.

**The incentive that fits a deal cohort is a tier upgrade**, because it costs you nothing and it is the thing this specific audience wants. It is still an incentive. It goes to third-party destinations only, it is unconditional on rating, and disclosure obligations travel with it.

The campaign design itself, including the prompt wording that decides whether a review contains any specifics, belongs to the review harvest method.

## Part five. Monetising a cohort that has already paid you

**The missed-the-deal inbound.** After the window closes you get a steady trickle of people asking whether they can still get it. The answer is no, and the standing reply is fifty per cent off the annual plan. Most operators answer this with an apology. It is the cheapest revenue in the ninety days and it needs one support macro.

**The cap upsell, which is the most useful idea in this file.** Every lifetime deal caps something: seats, hours, projects, clients, credits, storage, sends. The upsell that converts is more of that, sold to the people already pressed against it.

The reason is not that capacity is easier to build. It is that the deal removed price as an objection, so the only question left is whether the thing is worth using, and hitting a cap is the only proof of that you are ever going to get. A power user at the seat limit has told you, with behaviour rather than a survey response, that the product is load-bearing in their work. A cohort member offered a new module has told you nothing at all, and you will spend six weeks finding that out. The cap raise is also a quantity decision rather than a value decision, which is a much shorter sale: nobody has to believe anything new.

Two observed price points, both single-account reports from 2026 rather than benchmarks: roughly nineteen units a month to double the usage limits, and roughly nine units a month for one additional block of capacity. Use them as a starting shape, not as a price.

**Never hold a feature back from the deal in order to sell it later.** Marketplaces prohibit it and the cohort detects it within days, because a deal cohort reads the listing more carefully than you wrote it.

**The line between raising a cap and repricing the deal.** If the product is unusable at the cap you shipped, the add-on is not an upsell, it is a repricing of something people already bought, and the complaint goes to the marketplace rather than to you. The test: would a new buyer on that tier, using it as described on the listing, get the result the listing promised without the add-on? If no, fix the tier. If yes, sell the add-on.

**You cannot sell a cap raise you cannot see.** Instrument three things: current usage against every capped dimension, the date each account first crossed eighty per cent of any cap, and whether they have crossed it more than once. Repeat crossings are the buying signal, single crossings usually are not.

## Part six. Community, and the second launch

**Community.** The venue matters far less than the effort. Seed it from touchpoints you already own: the deal page, support replies, the roadmap page and the onboarding sequence. Write the guidelines before the first member arrives. Then build the retention mechanism, which is the part people skip: **give the community real authority over the roadmap.** A lifetime buyer has no further payment to make, so the only lever you have on their behaviour is participation, and a member who chose what gets built next has a reason to be there when it ships.

**The second launch, from day 60.** Marketplaces track what a partner did after launch one when deciding whether to run them again, so the housekeeping is part of the offer. The strongest repeat is **a bigger product at the same price, not an expanded product at a higher one**, because the second cohort is comparing your offer against the first one, which they can still read. A straight re-run also works, aimed at the people who missed it.

**Housekeeping that decides whether you are invited back.** Tell your marketplace contact about plan changes, dormant-account notices, ownership changes, material product changes and problem customers. Silence is what gets partners quietly dropped, and nobody is told why.

## Part seven. The decision rule

Run this before committing the ninety days.

- **You can identify accounts at or above eighty per cent of a capped dimension, and they are a meaningful slice of redeemers.** Build the cap raise first, price it monthly, and sell it only to that segment. Everything else in the plan is slower and smaller.
- **The cohort is active and nobody is near a cap.** The caps were too generous to be the upsell. Do not invent a feature to fix that. The revenue is in what the deal did not cover: additional seats and workspaces, and the missed-the-deal inbound.
- **The cohort is active and the refund window is still open.** Do the terms work and the review work. Recruit affiliates once the payout day is published. Pay nobody, and do not count the deal revenue in any plan yet.
- **Activation is far below your normal cohort.** Stop the monetisation work. Ninety days spent on first-run activation is worth more than any sequencing, because none of the steps above survive a cohort that is not in the product.
- **You cannot tell, because the cohort has not been in the product long enough to know who is active.** This is the normal case inside the first thirty days, and it is not a reason to wait. Do three things. **First, instrument the caps now**, because usage data is only collectable forward and every week you delay is a week of the signal you cannot recover. **Second, run everything with no dependency on activation**, which is a genuine majority of the plan: read and date the refund policy, establish the longest promise you made, compute and publish the payout day, write the clauses, and recruit the affiliates you can already identify from public praise, since a published review is evidence you have today. **Third, set a dated re-read**, and give it a proxy you can measure from day one, such as the share of redeemers who completed the first setup step within seven days of redemption. Then take a branch above. One thing is prohibited in the meantime: do not launch the cap upsell into a cohort you cannot segment. An untargeted paid offer to people who have just bought everything for ever reads as a bait and switch, and that complaint lands on the listing rather than in your inbox.

## Part eight. Worked example, compressed

A shared inbox tool for small agencies runs a deal on a lifetime-deal marketplace. The cohort is 1,840 redeemers: 1,050 on the entry tier with three seats, 560 on the middle tier with ten, 230 on the top tier with twenty-five. The marketplace's return policy is sixty days. The team's terms of service say fourteen.

**The plan on the table, one week after close.** Launch the affiliate programme immediately at thirty per cent recurring with net-thirty payouts. Email the whole cohort asking for reviews on the listing, offering a free tier upgrade in exchange. Build a reporting module and sell it at fifteen units a month. Start a community.

**Ordering pass, one item at a time.**

**The payout day.** Somebody checks the launch email and finds the sentence "the same sixty-day, no-questions refund applies to anything you buy from us this week". The effective window is sixty days, not fourteen. Net-thirty against sixty means every sale refunded between day 31 and day 60 has already had commission paid on it. If the programme produces 140 annual plans in the first quarter and refunds on partner traffic run at one in eight, roughly 17 sales carry a payment on returned revenue, and much of it is unrecoverable because the partners who earned it have stopped selling by the time you notice. The payout is republished as a stated range that already contains the monthly run, so nobody is told later that the terms changed. Recruitment moves to the following week.

**The review push.** The incentive cannot sit on the marketplace listing. The campaign is rebuilt to point at two third-party destinations, both policies read and dated, with the tier upgrade offered only there, unconditional on rating, and a plain unincentivised thank-you note used on the listing itself.

**The reporting module.** Nobody asked for it. Usage data, switched on in week one, shows 410 entry-tier accounts crossed eighty per cent of their three-seat cap within thirty days, and 240 of those crossed it more than once. There is no comparable signal anywhere near reporting.

**The inbound.** Support is fielding roughly seventy can-I-still-buy messages a week and answering each with an apology.

**Verdict: sell the seat pack, not the module.** Three additional seats at nine units a month, offered only to the 240 repeat cap-crossers. At a twelve per cent take-up that is about 29 accounts and roughly 260 units a month of recurring revenue, from a change that ships in days rather than the six weeks the module would have taken. The standing reply on missed-the-deal inbound goes live the same afternoon. Affiliate recruitment opens in week two behind a published payout range, starting with the buyers who left detailed reviews. The second-launch conversation waits until day 60, when the refund number is real.

Nothing here changed the commission rate, the review copy or the price of anything. What changed the result was the order, plus one sentence in a launch email that nobody had reread.

**What is still undecided and goes to a qualified check:** whether the tier upgrade counts as an incentive requiring disclosure in the jurisdictions these agencies operate in, and whether the marketplace's return policy is still sixty days on the date the plan is executed rather than the date it was written.

## Failure modes

**Paying inside somebody else's refund window.** Commission goes out on day 30 for sales that reverse on day 45. It surfaces as a reconciliation gap in month three and as an awkward conversation with your best partner, who did nothing wrong and will remember it.

**The forgotten mirrored guarantee.** The terms say fourteen days, the launch email said sixty, and the payout day was computed from the terms. Nobody discovers it until a refund lands on a commissioned sale, and by then the terms are public and signed.

**The incentive on the listing.** A tier upgrade is offered for a review on the marketplace itself. Reviews are removed, the listing is flagged, or nothing visible happens at all and you simply are not run again, which is the version you never get told about.

**The new-feature upsell.** Six weeks go into a module for a cohort that has demonstrated nothing about wanting it, while the accounts pressed against the seat cap file support tickets and are told that is the plan limit.

**The retro-held feature.** Something described on the listing quietly moves behind a paid add-on. The cohort finds it within days, it goes into the deal page comments, and the marketplace hears about it before you do.

**Killing the programme on tracked revenue alone.** Attributed affiliate revenue looks small at day 90, the programme is shut, and the untracked referral traffic it was seeding disappears over the following two quarters with no visible cause.

**Self-referral through unused codes.** Thousands of people hold codes, an affiliate link takes thirty seconds and a second email address costs nothing. Without a written self-referral clause it is not fraud, it is a feature of the terms you published.

**Reviews asked for in month two.** The cohort is at its most enthusiastic in the first days and is asked six weeks later, in a general newsletter, alongside two other requests. The response rate reads as a copy problem and is a timing problem.

**Counting deal revenue before the window closes.** Hiring, spending or a runway calculation is done on the gross number in week two. The refunds arrive between weeks six and nine and the correction is made against commitments already given.

**The community with no authority.** A space is opened, guidelines are written, and the roadmap stays behind a closed door. It goes quiet in about six weeks and turns into a support queue with worse tooling than the support queue.

**Silence with the marketplace contact.** A plan change, an ownership change or a wave of problem customers goes unmentioned. The partner is quietly not invited back, and the reason is never communicated.

## What this skill does not do

- It does not get you listed. The submission manifest, the tier ladder, the coupon mechanics and the entitlement plumbing that make a redemption work belong to the listing method, and this file assumes the codes are already redeemed.
- It does not write the affiliate clauses or implement the programme. Clause lists, commission arithmetic, the partner kit, link generation, refund reversal and payouts all sit elsewhere, and this file owns only the date you may pay on.
- It cannot supply your cap-hit data, your refund rate or your activation rate. Without those the decision rule stops at the cannot-tell branch, and the honest output there is instrumentation plus a dated re-read rather than a plan.
- It does not decide the legal position on incentivised reviews, endorsement disclosure, affiliate contracts or withholding on payouts. Those vary by jurisdiction, have been enforced, and belong to a qualified adviser.
- It cannot repair a cohort that never activated, and it will happily produce a tidy ninety-day plan for one, which is the most expensive way to use it.
- The numbers in it are not platform documentation. Refund windows, payout norms, the peak-interest timing and the observed upsell prices come from partner guides and single accounts, carry an August 2026 date, and should be re-checked against the current policy and your own analytics before anything is published on them.
