Skills/Marketing/Lifetime deal to recurring plan

Lifetime deal to recurring plan: the ninety days after the cohort lands, in the order they have to happen

The ordering is the asset: payout terms before any affiliate is recruited, review incentives off the marketplace rather than on it, and an upsell that raises the cap the deal itself imposed.

Not yet measured skill 4,335 words MIT by Locul Verified safe · 0 secrets Written 2026-08-20
/plugin marketplace add mkhalid1/locul-skills

Then /plugin to install Marketing, which includes this skill.

Download just this file4,335 words
No account and nothing to sign up for. The marketplace command works in Claude Code today. Using something else? Copy the file or download it and put it where your assistant expects.
We have not measured this skill. There is no result on this page because we have not run one. It is written, it has been read for accuracy, and it is free to take. Nothing below claims it improves an output, because we have not shown that. This is different from a skill that failed our test: those are not published at all.
What it is, and what we are not claiming

Untested. The assets are the ordering constraint against a refund window you do not control, and the case for selling a cap raise instead of a new feature.

We have not measured this one. It is published untested, and the fair starting assumption is that a strong model asked what to do after a lifetime deal will produce a reasonable list: thank the buyers, gather reviews, start an affiliate programme, build something to upsell, open a community. Every item on that list is defensible. The order is where the value goes.

What the file adds is three dependencies and a dated runway. It fixes the affiliate payout day against the refund window before any affiliate is recruited, and it points out that the window governing the payout is not the one in your terms of service but the longest refund promise attached to the sale being commissioned, which after a deal launch is often a sixty-day guarantee somebody mirrored into a launch email and then forgot. It separates review incentives by venue, because they are prohibited on the marketplace listing and permitted off it, subject to each destination's own policy and to consumer-protection law, and a plan that gets that backwards puts the listing at risk. And it argues that the upsell which converts is raising the cap the deal already imposed, on the grounds that a buyer sitting against a seat limit has demonstrated the value with their behaviour, while a buyer offered a new module has demonstrated nothing.

Where it is a close neighbour. Affiliate programme launch kit and Review harvest campaign each own one channel in full, and this file deliberately does not restate either. It owns the sequencing across four channels inside a window someone else defined.

Who it is not for. If your cohort redeemed and never came back, none of this applies and activation work does. If you sell to a handful of large accounts, a deal marketplace was the wrong channel and this is the wrong file.

When to reach for it

  • The day the promoted deal window closes and the marketplace's refund clock starts running, which is the last point payout terms can be fixed before anybody has been recruited under them.
  • Before commission terms are published anywhere the cohort can see them, because terms cannot be tightened afterwards with people who have already signed.
  • When the first can-I-still-get-the-deal message arrives after the window has closed and there is no standing reply, so it is being answered with an apology.
  • When somebody proposes building a new paid module to sell to the cohort, which is the moment to check whether a cap the deal already imposed is being hit instead.
  • When the marketplace asks what you did after the last launch, which is the question that decides whether you are run again.

Why there is no number on this page

Measuring one skill honestly costs about twenty model sessions: five runs with it, five without, on real material, each output graded alone by a session that is not told the other arm exists, against a rubric written by somebody who never saw the skill. We have not spent that on this one yet, so it ships labelled rather than ships silently.

How it would be measured. Five invented post-deal briefs, each stating a cohort size, a tier ladder with the capped resource named, the marketplace refund window in days, what the launch email separately promised about refunds, and a day count since the window closed, with one brief deliberately supplying no usage instrumentation at all. Graded mechanically on whether the published affiliate payout day is at least the longest refund promise attached to the commissioned sale plus a settlement buffer, whether it is fixed before any recruitment step appears in the plan, whether the recruitment order places published reviewers ahead of strangers, whether any review incentive is scoped to third-party destinations with a dated policy check rather than to the marketplace listing, whether the named upsell raises a cap the deal already imposed rather than adding a feature, whether a standing reply exists for missed-the-deal inbound, and whether the uninstrumented brief is routed to a forward-instrumentation branch with a dated re-read instead of a wait. The spine is computable, so Tier A.

Most of the spine grades without judgement. Payout day against the longest stated refund promise is a comparison. Whether recruitment appears after the terms in the plan is an ordering check. Whether the named upsell raises an existing cap or adds a feature is a lookup against the tier ladder in the brief. Whether the review incentive is scoped to third-party destinations is a string check with a dated policy step attached.

The awkward part is the material. A fair brief needs a cohort size, a tier ladder with the capped resource named, a refund window, and separately what the launch email promised, because the interesting failure is the gap between those last two. Writing five of those richly enough that the arms are graded on method rather than on invention is the slow part, and a plan is a document rather than an answer, so the remainder still needs blind pairwise preference from judges who have run a deal.

The rule that decides pass or fail was written down before any run was executed and it does not move afterwards. It is in the method note on the hub, along with the full results table including every skill that was tested and cut.

What it does not do

Stated plainly, because a skill that claims everything is useful for nothing.

  • The figures here are not platform documentation. Refund windows, payout norms, review-incentive practice and the observed upsell prices are aggregated from partner guides and from single accounts' own analytics, and no marketplace publishes them as rules for partners. Re-check every one against the current policy and against your own numbers before you rely on it.
  • It cannot tell you a named marketplace's current refund window, review policy or partner terms. Those differ by marketplace, several changed between 2024 and 2026, and the plan is wrong at the first step if the window is wrong. Read the policy, record the URL and the date you read it.
  • It does not write the affiliate clauses or implement the programme. The clause list, the commission structures and the full payout arithmetic belong to the affiliate skill, and link generation, refund reversal, fraud screening and mass payouts belong to a platform such as Rewardful or PartnerStack.
  • It cannot supply your cap-hit data. Without knowing which accounts sit against which capped dimension, the decision rule terminates at the cannot-tell branch and the only honest move is to instrument forward and wait for a dated re-read.
  • It cannot repair a cohort that never activated. If the deal buyers redeemed and left, no amount of sequencing produces recurring revenue from them, and the ninety days are better spent on first-run activation than on any of this.
  • It does not decide the legal position. Incentivised-review rules, endorsement disclosure, contract enforceability on affiliate terms and withholding on payouts vary by jurisdiction and have been actively enforced. It names the questions. A qualified adviser answers them.

Install it

  1. Open Locul, go to Library, and choose Import. One-click import from this page lands shortly.
  2. Locul writes the file to the right folder for every assistant you have connected, so you do not have to know where each one keeps its skills.
  3. Environment variables and headers in any shared config are replaced with a placeholder before they reach you, so importing a stranger's setup cannot hand you their credentials or take yours.
  4. Locul is free to start, on Mac and Windows. Get it here.
  1. Download SKILL.md using the button above, or copy the file.
  2. Save it at .claude/skills/lifetime-deal-to-recurring-plan/SKILL.md in your project, or under ~/.claude/skills/lifetime-deal-to-recurring-plan/SKILL.md on Mac and Linux, or %USERPROFILE%\.claude\skills\lifetime-deal-to-recurring-plan\SKILL.md on Windows, to make it available everywhere.
  3. Start a new session. Claude Code picks up the skill from the name and description in the file's frontmatter, so you can also invoke it by name.
  1. Download or copy the file.
  2. For Claude Desktop, add it through the skills panel in settings, or drop the folder into your skills directory.
  3. For Cursor and other assistants that read plain instruction files, paste the body into your project rules file. The skill is plain markdown with no tool bindings, so it carries across.

Pairs well with

What else does this job

An operator who has run two deals will beat this file on everything except the payout dependency, which is the one that bites people who have run five. If you have that person, use this as a checklist for the steps they skip, which are usually the dated policy read and the second-launch housekeeping.

For the measurement half, a subscription analytics product wins outright: cohort retention and expansion revenue per cohort are solved problems and rebuilding them in a spreadsheet takes a week you will not get back. For the affiliate half, an affiliate platform does the tracking, the refund reversal and the payouts, and it will happily pay on a schedule that is wrong, because the schedule is your input.

The model with no skill is also a real alternative. Ask it three questions: which refund window the payout day is computed from, whether a review incentive is allowed on the marketplace listing, and what to sell to a lifetime buyer. If it answers the longest promise attached to the sale, no but yes off-platform, and more of what they already hit the limit on, you do not need the file.

For the legal layer, neither this nor any model is the alternative. Incentivised endorsement rules and payout withholding are questions for a qualified adviser in the jurisdictions you sell into.

Read the full source
---
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.
Why import instead of copy

A skill is only as good as what it can read.

These skills all ask your assistant to check things against your actual codebase, your actual schema, your actual design system. Locul keeps that context current on its own, from the files you already have, on your machine. Mac and Windows, free to start.

Start free