Session Limits, Access Expiry and Reminders Are Three Different Product Rules

Subscription session limits and expiry describe different promises. A customer can have unused sessions after access expires, or active access with no sessions remaining. Reminders are a third rule. Sending a reminder should not silently change either the allowance or the expiry date.

For a domain expert packaging guided sessions or structured reviews, write these rules independently. The product must explain why a customer can or cannot begin the next session without requiring support to interpret a single ambiguous status.

Create an entitlement worksheet

Rule	Illustrative value	Decision to specify
Allowance	Ten sessions	What event consumes one?
Access window	Ten weeks from activation	What starts activation?
Reminder	Before the access end	Who receives it and when?
Individual exception	One approved extension	Which rule changes?

The values are fictional product examples. Replace them with the actual offer. Define whether a session is consumed when started, completed or explicitly accepted. Include abandoned and failed sessions in the rule so support does not invent a different answer for each customer.

Test quantity and time independently

Create four test accounts covering sessions available with active access, no sessions with active access, sessions available with expired access, and neither available sessions nor active access. Specify the expected message and allowed action for each.

In an illustrative package with ten sessions, a customer who completes six has four left. If the access period ends, the arithmetic remains ten minus six equals four. Whether those four can be used depends on the separate access rule. Show both facts rather than reducing them to an unexplained disabled button.

Make the time boundary unambiguous

Agree the exact instant access ends and the time zone used to explain it to the customer. Test immediately before and after that boundary. A calendar date displayed in one time zone can be interpreted differently by a customer elsewhere.

Decide what happens to a session already in progress when the boundary passes. Finishing an existing session and starting a new one are separate actions. Record the choice in acceptance tests and the customer-facing explanation.

Handle overrides without changing unrelated promises

Customer entitlement identifier
Rule being overridden
Previous value and approved replacement
Effective time
Reason and authorized owner
Effect on sessions already used
Effect on scheduled reminders
Expected message on the next sign-in

If access is extended, recompute reminders that depend on the end date. A previously queued expiry reminder can otherwise tell an eligible customer that access is ending. Recheck the current entitlement when sending it.

Keep enough history to explain an access decision. Support should be able to distinguish exhausted allowance, expired access and an incomplete activation. This reduces the chance that fixing one customer’s problem accidentally grants extra sessions or changes the whole organization’s defaults.

Bring the package rules and one customer exception. We can separate the allowance, expiry and reminder behaviour into testable decisions. Discuss the first release with Adamant Code.