Newsletter monetisation planning template: log one offer change

This newsletter monetisation planning template is a change-control record for one proposed modification to an already approved offer.

Use it to capture the baseline, describe exactly what would change, identify which reviews or tests may no longer apply, and record who decides whether the change can proceed. It is for changes to a paid subscription, sponsorship, affiliate arrangement, one-off payment or another defined offer. It is not for creating a new strategy or treating an old approval as blanket permission.

Anchor the request to the approved baseline

Before assessing a proposal, identify the exact offer version that is currently approved. If there is no approved record yet, create one with the blank offer template; this change log is not a substitute for that baseline.

Refer to the existing decision, population and research record rather than copying it into every change request. Check that its audience, eligibility, geography, period, exclusions and limitations still describe the offer affected by this request; retain "unknown" where they do not.

Describe the proposed change

Create a separate entry for each proposal. If one request combines changes that need different reviewers or tests (for example, a new supplier and a changed price), split it into linked entries so each decision has a clear evidence trail.

Name the mechanism and service involved rather than writing only "platform". For example, identify whether the offer concerns paid subscriptions or tiers, sponsorship, affiliate links or one-off payments; where relevant, name the actual newsletter service and payment provider, such as Substack, beehiiv, Ghost, Stripe or Paddle.

These are examples to help make a record specific, not recommendations or claims that the services work in the same way. A pricing-model reference can help label the model, but it does not approve a change to your offer. For describing named services by exact function, see tools reviewed by exact function.

For a change affecting marketing contact, state the actual route and review it under the Privacy and Electronic Communications (EC Directive) Regulations 2003 (PECR). The ICO's Electronic mail marketing guidance advises keeping a do-not-contact list and screening against it.

If the proposal changes how an opt-out is handled, record the control and evidence; the ICO's guidance on respecting preferences advises using a suppression list instead of simply deleting details.

If a proposed change alters a paid offer's price, cancellation information or refund presentation, route it to the appropriate reviewer. The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 may be relevant to a distance contract; ask a qualified reviewer to assess applicability to the actual offer. Record any VAT review as a separate decision rather than carrying forward an assumption from the previous version.

Screen for evidence that may be stale

Compare the proposal with the approved baseline. Reopen the reviews and tests that the changed feature could affect, and write down why an item is affected, or why it is not. A previous "go" is not evidence that a different version has passed.

These are prompts, not a universal legal checklist. An open item can be sent to the market-entry checklist, but keep its owner and the evidence needed to resolve it in this change record too.

Here is an illustrative completed entry, not evidence of a real approval: CH-01 | Current: sponsor disclosure at the end of the edition | Proposed: disclosure beside the relevant sponsor content | Affected: approved wording and edition layout | Decision: hold | Owner: named editorial reviewer | Retest: inspect the revised edition and save the dated preview before reconsidering. This makes the change and its next action visible without implying that the proposed wording has passed review.

Record a test row for each affected behaviour

A test entry should identify the exact version and an observable result. Do not mark the whole service "tested" when only one changed behaviour has been checked.

For the illustrative disclosure change above, the test row could say: CH-01 | revised edition preview | authorised preview copy | disclosure appears beside the relevant sponsor content | saved preview location | reviewer and date | hold if missing or unclear; correct and retest. Use separate rows if the result depends on different services or contractors.

Where a contact-route change is involved, make the suppression check its own row rather than assuming a successful email send proves it worked. Schedule the retests inside the ninety day plan if one is running.

Close the record without erasing its history

Close the request only when the decision, affected reviews and required test evidence are recorded against the applicable offer version. If evidence is missing, a reviewer has not decided, or a test has failed, record a hold, rejection or deferral and the next action; do not label the change approved.

Keep unresolved assumptions visible as statement | evidence type | geography | date | owner | decision affected | update trigger.

If the change is approved, record the exact version it applies to and who may authorise a later change. A new audience, claim, data route, price or supplier can make earlier evidence stale; link the later request to this record and assess it on its own terms.