Start Building

Lesson 20: Discount Cooldown Policy Template and Recovery Logic

Discount experiments fail when teams only decide when to run sales, but never decide when to stop.

This lesson gives you a practical cooldown policy template you can reuse after every promo window. You will set pause rules, define recovery phases, and re-open discount testing only when evidence says it is safe.

What You Will Build

By the end of this lesson, you will have:

  1. A discount cooldown policy template with hard triggers
  2. A three-phase recovery flow after weak promo performance
  3. A restart checklist for future discount tests
  4. A policy owner and review cadence for team accountability
  5. A simple log format for audit-ready pricing decisions

Step 1 - Define cooldown trigger conditions

Your policy starts with objective triggers, not mood.

Add cooldown triggers such as:

  • net revenue per day drops below your guardrail
  • refund rate rises above your acceptable threshold
  • support ticket volume exceeds handling capacity
  • review sentiment trend drops during promo traffic

If any trigger fires, the next planned discount window is automatically paused.

Mini Task

Create discount_cooldown_triggers_v1.md with four triggers and one threshold value for each.

Step 2 - Build a three-phase cooldown model

Use the same structure every cycle:

  1. Pause phase (7-14 days): no new discount tests, stabilize messaging and build quality
  2. Recovery phase (1-2 windows): run full-price or low-volatility windows with strong patch clarity
  3. Re-entry phase: resume discount experiments only after restart criteria pass

This prevents panic discount loops that train players to wait for sales.

Step 3 - Add recovery logic tied to operations health

Cooldown is not only a pricing event. It is an operations reset.

During recovery, track:

  • unresolved critical bug count
  • first-response support time
  • patch-note clarity and expectation alignment
  • wishlist-to-purchase quality trend

If operations are unstable, extending cooldown is often cheaper than forcing another sale.

Step 4 - Create restart criteria before re-entry

Do not restart testing because "enough time passed."

Require a restart checklist:

  • trigger condition has been below threshold for two review cycles
  • current build quality passes launch-week smoke checks
  • support ownership and promo ownership are explicitly assigned
  • hypothesis for next discount window is written and measurable

No checklist pass means no re-entry.

Step 5 - Assign policy ownership and audit trail

A good template fails if nobody owns it.

Assign:

  • one pricing owner
  • one operations reviewer
  • one final approver for re-entry

Log each decision in this format:

Window | Trigger fired? | Cooldown phase | Restart checklist pass? | Decision owner | Next review date

That log becomes your evidence base for future launch planning.

Pro Tips

  • Run cooldown review on a fixed weekday so decisions are consistent across teams and time zones.
  • Keep pricing and release notes in one shared review doc to separate price impact from product impact.
  • Add one "no-discount justification" note when cooldown extends so stakeholders understand the tradeoff.
  • Use the same trigger names every cycle to keep dashboard comparisons clean.

Common Mistakes

  • Treating cooldown as optional when triggers already fired
  • Restarting discounts before support load normalizes
  • Using subjective language instead of measurable thresholds
  • Skipping ownership fields and creating approval confusion

Troubleshooting

Team wants to break cooldown for short-term cash

Run a restart checklist review first. If core quality or support readiness fails, the short-term gain usually increases refunds and trust loss.

Cooldown keeps extending every cycle

Your thresholds may be unrealistic, or root issues are unresolved. Revisit support staffing, patch quality, and message clarity before changing discount cadence.

Stakeholders disagree on re-entry timing

Use your log and checklist as arbitration. Policy wins over individual preference.

Mini Challenge

Create discount_cooldown_policy_template.md with:

  1. trigger thresholds
  2. pause/recovery/re-entry phases
  3. restart checklist
  4. owner roles
  5. decision log table

Then simulate one failed promo window and run the full policy decision path.

FAQ

How long should a cooldown be after a weak discount window?

Use at least one full review cycle, often 1-2 windows, and only restart when trigger metrics stay below thresholds for consecutive checks.

Should we always keep full price during cooldown?

Usually yes for test clarity, but you can use low-volatility windows if your policy explicitly allows them and guardrails stay healthy.

What is the safest first metric for cooldown triggers?

Net revenue per day plus refund-rate movement is a strong starting pair because it captures both financial quality and player fit.

Can cooldown policy work for very small teams?

Yes. Small teams benefit most because cooldown prevents support overload and protects scarce execution bandwidth.

Lesson Recap

You now have:

  • objective cooldown triggers
  • a repeatable three-phase recovery model
  • restart criteria for safe re-entry
  • named owners for policy enforcement
  • a decision log format for accountable launch operations

This turns discount cadence into a controlled system instead of a reactive cycle.

Next Lesson Teaser

Next, you will build a lightweight launch control panel that combines pricing cadence, support load, and build stability into one weekly go/no-go dashboard.

Related Learning

Bookmark this lesson before your next promo review so discount cooldown decisions remain systematic and defensible.