Subscription Management Business Rules & Use Cases

Open Issues/Questions
Billing Plan Change
General Use Case
Business Rules
Reference: Billing Plan List
Upgrade
General Use Case
Business Rules
Downgrade
General Use Case
Business Rules
Sidegrade
General Use Case
Business Rules
Use Cases
P1: User-selected subscription line sidegrade is stacked after current billing plan
P0: CSR can stack subscription line sidegrade after current billing plan
P0: CSR can immediately sidegrade a customer's subscription line with financial reconciliation
P2: User subscription line change takes immediate effect with financial reconciliation
Pause
General Use Case
Business Rules
Auto-Renew
General Use Case
Business Rules
Auto-Renewal Date
General Use Case
Business Rules
Billing Retry
General Use Case
Business Rules
Fulfillment Dates
General Use Case
Business Rules
Cancel
General Use Case
Business Rules
Suspend (System cancel)
General Use Case
Business Rules
Restart
General Use Case
Business Rules
Sales & Discounts
Summary
General Use Cases
Discount Method:
Attributes of discounts
Reference:
Addendum: Terminology
Stream Management
Transfer Subscription
General Use Case
Business Rules
Pricing Change
General Use Case
Business Rules
MMB
General Use Case
Business Rules
B2B: Facebook
General Use Case
Business Rules
B2B: Charter Schools
General Use Case
Business Rules
Emails (transactional and marketing)
General Use Case
Business Rules
 TO COME:
School Edition
Inventory Management (shop integration, web site updates, automation)?
Customer Service Subscription Management Use Cases
FUTURE PHASES (NOT MVP)
Prepaid Stacking
More Gifting Scenarios
Auto-Migrate
Customer Service Data Requests
Back Order Rules (Shop/Subscription?)
Shipping
Ops Management & Reporting
Cancel-Save

Open Issues/Questions
Upgrade: Will user get a single charge or see two charges when they renew to Premium? (hoping single)
Suspend: Need to understand the current error cases that would lead to this and the email output for them.

Billing Plan Change

General Use Case

Active Subscriber to Subscription Line A-Billing Plan A changes to Subscription Line A-Billing Plan B

Example: I'm on Early Explorers monthly recurring and switch to EE 12-month recurring

Business Rules

Customers should be able to select in the Web site UI to go from one Billing Plan within a Subscription Line to another billing plan at any
time.
The selection of Billing Plans will only include those that are currently available to new customers.
If a user is near their Subscription Line Completion, they should only see Billing Plan options that are fewer months than the
remaining packages, i.e. if I am on a monthly plan only have 7 packages left in my Subscription Line, when I choose to change
my billing plan, the only option I will have is a 6-month plan (no 12-month plan).
Both a customer and a CSR should be able to change a billing plan and can be stacked (CSR & Customer option) or immediate (CSR
only option)
Customer initiated Billing Plan changes take effect at the customer's next auto-renewal cycle (stacked). i.e. If I am on a 12-month Billing
Plan and choose to go to monthly during my 2nd month, I will finish out the next 10 months of my already paid-for billing plan and on my
renewal date I will start being charged monthly instead.
For CSR within Magento UI, CS would like the Change Plan button to allow the rep to choose between changing the plan at the end of
the billing cycle (new functionality for them) or to trigger an immediate cancel with refund and immediate start of the new billing plan
(behavior they have today in Magento, but updated to use non-tree logic)
More details here on tweaks/improvements that would help CSR: CS Needs on Billing Plan Change
Immediate billing plan change is available for packages prior to going to Order Processing.
Abundance of clarity: We are not going to continue to support the "tree" logic we have today for CS where we try to catch people up to a
renewal cycle that is divisible for the number of packages. i.e. the idea of going on a 4 month plan temporarily to get to a 6 month plan so
that at the end of the subscription line everything is divisible by 6. Instead any billing plan change takes effect per the rules outlined
above and if at the end of the subscription line there are fewer packages than the last renewal charge, we will prorate that last charge.
More on the proration here: Subscription Management Business Rules & Use Cases#Auto-Renew

Reference: Billing Plan List

See Current Magento Billing Plans for list of billing plans and number of existing users (pre Next Gen) on each.

Upgrade
General Use Case

Active Subscriber to a Standard subscription type upgrades to a Premium Subscription type (same Subscription Line)

Business Rules

Upgrade to Premium should take place with the customer's next shipment
If user is on a monthly billing plan, they would be charged for Premium with their next monthly billing.
If user is on a prepaid billing plan (6- or 12-month) and
is in their last month before renewal, they would be charged for 6- or 12- months (depending on their billing plan
duration) of Premium on their next renewal charge
has n pre-paid months remaining in their existing billing plan cycle, they will be immediately charged the price difference
for the remaining n months of premium. On the next auto-renewal date, they would be charged for Premium for they
would be charged for 6- or 12- months (depending on their billing plan duration)
Upgrade to Premium should only be offered to customers whose next scheduled package has a premium item available. i.e. if we
currently are only stocked for Premium items for M1-M12 of the WE Subscription line, a user currently in M18 should not be offered a
Premium upgrade option.
Both a customer and CSR should be able to initiate an upgrade.

Downgrade

General Use Case

Active Subscriber to Premium subscription type downgrades to a Standard Subscription type (same Subscription Line, same Billing Plan duration)

Business Rules

Downgrade should be able to be stacked (at end of currently paid-for billing cycle) or immediate (with a refund given)
Stacked downgrade (customer & CSR option):
Shipments: User continues to receive any already paid-for premium items until the end of their current billing cycle.
Starting at their next renewal, user will receive Standard packages.
Billing/Charges: User starts being billed at the standard subscription type price on their next scheduled auto-renewal dat
e. Subsequent auto-renewals will be for the Standard Subscription type.
Immediate downgrade (CSR-only option):
Shipments: Any unshipped Premium items are canceled and do not ship. The user's next shipped subscription package
will be a Standard package
Billing/Charges: User is refunded for any unused portion of Premium. Subsequent auto-renewals will be for the Standard
Subscription type.
Both a customer and CSR should be able to initiate a downgrade.

Sidegrade

General Use Case

Active Subscriber to Subscription Line A (any Billing Plan) sidegrades to Subscription Line B (any Billing Plan)

Business Rules

Sidegrade should be able to be stacked (at end of currently paid for billing cycle) or immediate (with a refund/credit given)
Stacked sidegrade:
Shipments: User continues to receive any already paid-for packages from Subscription Line A per standard schedule;
Subscription Line B will start the month after the final package from Subscription Line A is shipped.
Billing/Charges: User is billed for Subscription Line B at the next auto-renewal date from Subscription Line A.
Immediate sidegrade:
Shipments: Any unshipped packages from Subscription Line A are canceled and do not ship. User immediately gets
their Subscription Line B package on the next shipping date.
Billing/Charges: User is refunded or credited for any unused portion of their Sub Line A billing plan and billed
 immediately for their Sub Line B billing plan.
Sidegrade should allow going to any billing plan on the selected subscription line (you can sidegrade from a monthly billing plan on Sub
Line A to a 6-month billing plan on Sub Line B)
User should not be able to sidegrade to a subscription line that they have already completed
If a user sidegrades to a Subscription Line that they started but canceled/expired before completing they should be given a choice of
restarting that subscription (same child use case) or starting over at the beginning (different child use case)
Phasing: Initial customer facing need is to have stacked sidegrade. Customer service will need both stacked sidegrade and immediate
sidegrade capability. A customer being able to initiate immediate sidegrade is a future possibility.

Use Cases

The following came up in group discussions. Need to make sure these are covered in the user story spreadsheet.

P1: User-selected subscription line sidegrade is stacked after current billing plan

1. Current subscription is canceled (aka auto-renew turned off) and user is told they will start the new subscription line at the end of their
current paid-for period.
a. If user already paid for n months but has not received the packages, they should receive those packages before they start the new
subscription line.
2. Subscription Line B is stacked on the canceled billing plan. User is charged for Subscription Line B Billing Plan on their next scheduled aut
o-renewal date
3. User receives Subscription Line B package after successful payment.
a. If user has never subscribed to Subscription Line B before, they receive the Intro Kit (M1)
b. If user has subscribed to Subscription Line B previously we should allow customer to choose if they wish to restart their previous
subscription or start a new one. See more here: Subscription Management Business Rules & Use Cases#Restart
4. Subsequent re-billings will occur based on the auto-renewal date from Subscription Line A

Edge Cases/Scenarios:

1. User should not be able to switch to a subscription line that they have completed
2. User should be able to switch back and forth between subscription lines, each time the selection will take effect after any previously
paid-for billing plan durations have been fulfilled.

P0: CSR can stack subscription line sidegrade after current billing plan

Same as "User-selected subscription line sidegrade is stacked after current billing plan" except the side grade is initiated by customer service
rep.

P0: CSR can immediately sidegrade a customer's subscription line with financial reconciliation

1. CSR at customer request disables the current subscription, refunds any remaining money on the existing subscription billing plan and user
is told they will start the new subscription line the next month.
a. This disabled subscription should be eligible for restart by the customer.
2. Subscription Line B starts the next calendar month. User is charged immediately for Subscription Line B Billing Plan.
3. User receives Subscription Line B package after successful payment.
a. If user has never subscribed to Subscription Line B before, they receive the Intro Kit (M1)
b. If user has subscribed to Subscription Line B previously we should allow customer to choose if they wish to restart their previous
subscription or start a new one. See more here: Subscription Management Business Rules & Use Cases#Restart
4. Subsequent re-bills will occur based on the Billing Plan selected for Subscription Line B

P2: User subscription line change takes immediate effect with financial reconciliation

Similar to "CSR can immediately sidegrade a customer's subscription line with financial reconciliation" except action is taken by the customer.
TBD on the business side if we will provide a credit put toward the side graded plan or a refund and new charge. (leaning is credit the account)

Pause

General Use Case

Active Subscriber puts a temporary hold on their subscription until a future date, stopping all shipments and charges temporarily.

Business Rules
 Pausing a subscription should put a hold on both shipments and auto-renewal re-bills.
Any package in Pending can be paused. Once the package moves to Order Ready it should continue through shipment.
Pause should be available for all billing plans though monthly is the only P0.
Pausing will be for 1 to n months. Customer-selected pause will have a max number of months for a pause, but customer service should
have full flexibility.
Customer will be able to see details about their Pause period in their account management screen.
Subscriptions should automatically resume at the end of the pause period.
Shipments should pick up where they left off at the end of the pause time period:
For magazine streams, since all customers get the same boxes in a given shipping month, they user will not receive the
packages for the skipped months. They will continue to receive the same packages as other customers in the given
month. At the end of the subscription line, package rules for filling in empty slots will put the missed packages into the
user's stream.
For non-magazine streams, a customer will resume with the next package that was in their stream prior to pausing. i.e. If
I paused the subscription for 3 months after receiving my M3 package, then I will receive the M4 package when I
resume my subscription
Auto-renewals should be moved out by the pause period. If I put a 3 month hold on my subscription, my next auto-renewal
month should be moved out by 3 months.
During the pause period a customer should be able to resume the subscription before the pause completes if they change their mind. If
no immediate resume is selected, the subscription will auto resume as scheduled.
There is no limit to the number of times a customer can choose to pause over the life of their subscription.
Both customers and CSR should be able to initiate a pause
CS desires to improve the existing pause flow: CS Needs on Pause
Edge cases: General rule of thumb is that a customer resuming after a paused subscription is resuming the same Subscription Line &
Billing Plan that they had at the time of the pause. Should there be a change to either of those, the customer should have the same
experience as anyone else on their Subscription Line & Billing Plan who did not pause the subscription. Specific examples:
Stop offering billing plan during the pause:
If the billing plan is grandfathered in for existing customers, but not offered to new customers, the paused customer
should be grandfathered as well and allowed to resume.
If the billing plan was killed and we migrated all customers to another billing plan, then the paused customer should be
migrated as well.
Stop offering subscription line during the pause:
If the Subscription Line is ended and customers refunded, then the paused customer will also get a refund.
If the Subscription Line is no longer offered for new customers but we grandfather existing customers to finish their
subscription, we would resume the customer on the Subscription Line after the pause.
Price change (increase or decrease)
If it is a universal price change for both existing and new customers, the customer should receive all the same
notifications of the change as other customers on that plan and would experience the price change the same as anyone
else after they resume.
If the price change is only for new customers, then the paused customer would be grandfathered in as an existing
customer and resume on the former price.
Rare case: Subscription resumes near completion of the subscription line and there is no inventory for the last package(s). In this
case, similar to anyone in that case, we would cancel the sub and refund the undeliverable months.

Auto-Renew

General Use Case

An Active Subscription nears the billing plan's renewal date and the customer is charged for their next billing cycle.

Business Rules

If a customer makes no changes to their auto-renewal settings, the subscription will Auto-renew at the agreed upon cadence until the
Subscription Line Completion
Customers will be charged based on the auto-renewal date timing associated with their purchase date
See Subscription Management Business Rules & Use Cases#Auto-RenewalDate for business logic
Early Auto Renew should be allow for a segment of users flagged for EAR as selected by the business. For those customers they will be
charged one month earlier than their standard auto-renewal date.
FP&A determines which users fall into the early auto-renewal cohort and provide the list to be flagged as such.

If the customer is near Subscription Line Completion and has fewer packages remaining than their next Billing Plan duration, the final
charge to the customer will be for the remainder of packages as a prorated price equivalent to their billing plan. i.e. if I'm on a 12-month
recurring plan at $120 and on my next renewal I only have 2 packages left, I should be charged $20 instead of $120.
This pro-rated charge should be reflected in the renewal reminder email.
Email reminders of the upcoming billing are sent to customers on non-monthly plans. Monthly plans do not receive reminder emails.
Credit card billing failures should trigger retries for a period of time. See Subscription Management Business Rules & Use
Cases#BillingRetry for more details
Auto-Renewal Date

General Use Case

When a user purchases a subscription, their auto-renewal date for that subscription should be defined based on business rules for that purchase
date. So long as there is no lapse in their subscription, the auto-renewal date will persist even as a user changes billing plans or subscription
lines.

NOTE: This is a change from current logic that ties auto-renewal date to the plan being purchased.

Business Rules

For new customers after NextGen launches, auto-renewal date is defined based on the subscription purchase date. For launch we plan to
have 2 auto-renewal dates, but this should be flexible to handle as many as we may choose to have in the future.
Sub purchase day of month 11-24 = auto-renewal day 10
Sub purchase day of month 25-10 = auto-renewal day 24
Examples:
If I purchase on March 10, I will be billed for my M2 on March 24 and the 24th of each month thereafter
If I purchase on March 25, I will be billed for my M2 on April 24 and the 24th of each month thereafter
If I purchase on April 15, I will be billed for my M2 on May 10 and the 10th of each month thereafter
More details on billing & fulfillment dates here - keeping in mind the exact days and day ranges may change: Draft: Package
Dates: Billing & Fulfillment
For pre-NextGen customers, when we launch NextGen, their auto-renewal date should be based on their current plan's bill date. That
means prepaid customers will have an auto-renewal date of the 10th while MTM subscribers will have an auto-renewal date of 24th.
If a user with an active subscription changes their plan or subscription line, the auto-renewal date from the original subscription purchase
should persist.
If a user subscription lapses, when the customer restarts that subscription their auto-renewal date should follow the same rules as a new
purchase.
If user purchases multiple subscriptions, each subscription’s auto-renewal date will be based on that subscription purchase. So a
customer could have multiple auto-renewal dates per active subscription.
Customer service should be able to change the auto-renewal date for a customer to an alternate currently supported date, i.e. if a
customer requests to put two subscriptions on the same auto-renewal date.
TBD: Transactional emails, including the prepaid renewal reminder and MMB logic will need to be looked at to see if revisions
are needed based on the new re-bill rules.

Billing Retry

General Use Case

If the initial charge for a subscription renewal is declined with a soft decline per the payment processor, it should go through a series of retries with
Braintree followed by a final retry against Vindicia before the subscription is moved to a canceled state that the customer can restart by updating
their payment info.

Business Rules

For hard declines, move the subscription to canceled due to billing failure (exact State & Status to be defined by engineering)
Do not retry the card.
Little Passports should immediately send the customer an email(s) to update their billing information
For soft declines, we should retry the card until it is successful or we hit the max number of retries.
The retry logic should be flexible as follows:
Retry every n days, x number of times
Separate configuration for prepaid vs. monthly.
All retries should be against Braintree except the final one which will be against Vindicia
If the retry is successful before the customer's scheduled fulfillment date, then the package should ship as scheduled
If the retry is successful after the customer's scheduled fulfillment date, then their fulfillment date should move to the next
available one.
If all retries fail, the subscription should be canceled due to billing failure (Suspended State) and we should email the customer to
update their credit card information
 If a user whose subscription was canceled due to a billing failure updates the card triggering a successful charge, the subscription should
restart.
Launch configuration:
The Rule (above): Retry ever x days for n times, with the last try against Vindicia.
MVP Simplification: Without Vindicia in MVP, the last retry will be against Braintree instead
Starting variables:
x=4 days
n=4 times
Example: 10th billing date will retry then on 14, 18, 22, 26; for 24th billing date the day of month will shift depending on if the
month is 28, 29, 30 or 31 days long, but will remain the same cadence: every 4 days for 4 times.
Reasoning: This cadence does two key things for us
Keeps the retries to no more than 4 in a 16 day period - best practice for soft decline retries
Means we will complete our retries before the supplemental fulfillment, even in a 28 day month.
Emails: We will email a customer when they have a hard failure and/or all billing retries fail telling them to login to the site and
“fix” their credit card. If they fix their card before the supplemental fulfillment they stay on their original cadence.

Fulfillment Dates

General Use Case

Every package in a customer's subscription should have a fulfillment date (called Output Date in Magento Package grid). This is the date when
the order will go to the fulfillment house if it has been successfully paid for. For flexibility, we need the fulfillment dates to be configurable based on
business rules.

Business Rules

Fulfillments for M1 packages will be based on purchase date rules (if purchased on day or range of days of month, fulfill on x day of
month). Example: Any purchase from 16th-25th gets a fulfillment date of the 25th. We should be flexible to handle anything from 1x per
month fulfillment to daily fulfillment depending on the rules.
Fulfillments for M2 packages will be based on auto-renewal date + when it is successfully paid for.
Prior to charging the customer we will estimate fulfillment dates based on the planned auto-renewal date. Example: If the auto-re
newal date is the 24th, we will fulfill on the 2nd
If the customer successfully pays for the package prior to the estimated fulfillment date, then there is no change to their
fulfillment date.
If due to credit card failure or other reasons, the successful payment for the package comes in after the estimated fulfillment
date, then there should be a supplemental fulfillment date.
If the successful payment comes in after both the standard fulfillment and supplemental fulfillment dates, then the month(s) will
be skipped and the payment applied to the next available fulfillment/supplemental fulfillment after payment.
More details on draft fulfillment rules here - keeping in mind the exact days and day ranges may change: Draft: Package Dates: Billing &
Fulfillment

Cancel

General Use Case

Active Subscriber decides to cancel their subscription.

Business Rules

Canceling a subscription is in essence turning off auto-renew.

We need to support two versions of cancel:
Standard cancel: A customer will continue to receive their subscription packages through any already-paid for period on the
subscription before the subscription expires. No refund is given.
Immediate cancel: In addition to auto-renew being disabled, already paid-for packages do not ship and the customer is refunded
for the remainder of their subscription period. (This will be a CS-only feature in v1).
If a package has moved to Order Processing or Order Shipped it cannot be canceled. It can, however, be canceled if it
is in Order Ready or an earlier state.
Both a customer and a CSR can initiate a cancel.
For CSR, here are desired improvements to the current Cancel flows: CS Needs for Immediate Cancel/Auto-Renew Controls
We need to store the cancel reason at the time of cancelation
If a customer initiates the cancel on the Web, they will be required to take a cancel survey prior to completing the cancelation
process. The survey will have pre-set reasons as well as an Other option with free-form entry.
 If CSR is initiating the cancel, they should have similar preset reasons as the Web survey as well as a free form entry field for
additional details
CSR should also be able to mark a subscription as Disabled.
Any subscription that has been canceled can be re-started by the customer unless it is marked as Disabled. Only CSR can restart a
Disabled subscription. See more here: Subscription Management Business Rules & Use Cases#Restart
Phasing: Initial customer facing need is standard cancel. Customer service will need both standard and immediate cancel capability. A
customer being able to initiate immediate cancel is a future possibility.

Suspend (System cancel)

General Use Case

System cancels a user subscription due to a renewal failure or other error that makes receiving payment from the customer fail.

Business Rules

Suspended subscriptions behave similarly to a standard canceled subscription (customer) except the actor causing the cancelation is
different.
If the system cause of the cancelation is a chargeback, the subscription should also be marked as Disabled. Disabled subscriptions can
only be restarted by a CSR. (see Restart below)
For other reasons, i.e. general billing failures, the cancelation should not be Disabled and the customer should be able to restart
the subscription.
Additional emails should be triggered for suspensions alerting the user that their subscription has been halted due to billing issues.
TBD: Need to understand what billing error cases we have today in case any others should be "disabled" and making sure we
have the right email streams for them all.

Restart

General Use Case

A customer who canceled their subscription decides to restart it.

Business Rules

Any subscription that is not Completed (has been canceled but has remaining packages available in the stream) is eligible to restart.
A customer or a CSR should be able to initiate a restart.
If a subscription is disabled, only a CSR can restart the subscription. A customer cannot.
User can restart a canceled subscription that is active (still shipping packages) or lapsed (unless it is Disabled).
If the subscription is active when restarting, the restart is stacked at the end of the currently paid-for billing cycle. To the
customer, this behaves as if they had not turned off auto-renew: The next charge is on the same schedule as prior to cancel and
packages continue shipping without any gaps.
If the subscription is lapsed when the customer restarts, they will be billed immediately for the restarted subscription, auto-renew
will be re-enabled and their renewal day & fulfillment day for pending packages will be updated based on the restart date.
When a user restarts a subscription, they can select from the available Billing Plans for that Subscription Line
We will default to the Billing Plan they had at time of cancel (if it is still available) with an option to select any other available
Billing Plan on that Subscription Line.
If the user was on a Basic variant of their subscription line when they restart, LP would like to upsell them to Premium at the time
of restarting, i.e. for xx more get the premium offering!
If user selects Premium they should restart at the same place in their package grid as they would have on Basic, but get
the variant that includes the Premium additional items (currently a book)
If the user is near Subscription Line Completion, we will only show them Billing Plan durations that are less than their remaining
packages, i.e. if I was on a 12-month recurring plan and canceled when I had 8 packages remaining, then I would only see the
monthly and 6-month Billing Plan options.
If the subscription is in a Suspended state due to billing error, the user will need to fix their credit card as part of the restart flow.
Shipments should pick up where the stream left off prior to cancel:
For magazine streams, since all customers get the same boxes in a given shipping month, they user will restart with the package
associated with their first restart month.
For non-magazine streams, a customer will restart with the next package that was in their stream prior to cancel. i.e. If the last
package I received after canceling was the M3 package, then I will receive the M4 package when I restart my subscription
If the stream has been versioned up, the customer will restart with their original stream, unless it was decommissioned and all users in
that stream were versioned up.
 If there was a price change, the customer will restart at the price associated with their restarted stream.
If the price change was universally made for everyone on that stream, the customer will restart at the new price
If the price change was for new purchasers only and existing subscribers on that stream kept their price point, then customer will
restart at their previous price.
If a customer tries to purchase a Subscription Line that they previously received and have since canceled, they should be prompted to
confirm if they wish to restart their former subscription or start a new subscription from the beginning to handle.

Sales & Discounts

Summary

Little Passports can discount the price on subscriptions and/or shop items based on Magento rules. From a consumer-facing perspective there
are three fundamental promotion experiences:

1. Discount given after manually entering a code (example: Valentines Day Sale with code LOVE)
2. Discount given after taking a specific action (example: accepting an offer in the cancel flow)
3. Sale visible on the site and available for a limited time to anyone who purchases (example 15% off all Shop Items for a specific period of
time)

General Use Cases

1. Customer enters a code to get a discount. Example: Code “LOVE” for 15% off all subscriptions at Valentines Day.
a. At time of purchase
b. P2: At time of restart (P2)
c. P2: Mid-way through a subscription to get a discount on a future rebilling. (P2)
2. Code is automatically applied to an order by the system (customer doesn’t see the code, but one is applied). Example: Code
“AUTORENEWAL15” is applied to a renewal if a customer accepts a cancel-save offer during the cancel flow.
a. At time of purchase
b. At time of restart
c. Mid-way through a subscription to get a discount on a future rebilling.
3. Discounted price is shown on the Web site and available to anyone who makes a purchase, without use of a code. Example: March
Madness Sale 2019 (to come) or Cyber Monday Sale 2018 where all shop items were 15% off.
4. Code is added by Customer Service to a subscription cycle within Magento.

Discount Method:

% off (up to 100% or free)

$ off
Set sale price ($ price, not discount off)

Attributes of discounts

Discounts can apply to

any SKU i.e. a subscription or a shop item
shipping (i.e. free shipping)
rules about the cart, i.e. if the cart value is over $ amount or if a combination of items are in the cart.
P1: multiple future billing cycles on a subscriptions (i.e. 15% off next 3 months, then full price thereafter on a monthly plan) (P1)
FUTURE: a category/segment of SKUs, i.e. all shop items or all subscriptions (P2)
P1: In the case of multiple future billing cycle discounts, if a user cancels their subscription and/or hits the end of the subscription line
before receiving all discounted renewals, they would forfeit any unfulfilled discounts.
Can combine the application rules above in one discount code/rule, i.e. 15% off a SKU + free shipping (within the capabilities provided by
Magento - some limitations)
Can have tiered rules, i.e. $10 off monthly subs, $20 off 6-month subs, $40 off 12-month subs.
On subscriptions, discounts can be applied at any time in the subscription lifecycle, meaning at time of initial purchase (acquisition), on
upcoming renewal(s) in an active subscription (cancel-save) or at restart of a canceled subscription (win-back)
Have a start date and expiration date.
Can require a code or no code
Key attributes of codes
Can be entered by the user or applied by the system
Can be multi-use (promo code) or one-time use (coupon code) Note on terminology
Can be human-defined code (i.e. EXPLORE) or system generated (list of one-time codes)
Rule name and code (if applicable) are associated with the purchase for analytics purposes.
Multiple rule names can be applied to an order.
 Discounts cannot be stacked (meaning you can’t use two different codes to get a double discount or apply a code to a sale priced item)

Reference:

Examples of current and recent promos

Promos that will be Active at time of MVP launch

Addendum: Terminology

Note on terminology: Today we use the terms promo code and coupon code interchangeably in our dev code and conversations, but future facing
we should differentiate these terms as follows

promo code = a code that can be used by many users i.e. today’s EXPLORE code
coupon code = a one-time use code that after being redeemed cannot be used again i.e. customer-specific promotions.

Stream Management
Summary of current behavior: Package Lists and Stream Behavior

Key Needs for the Catalog-level Package List:

Rearrange the order of the packages. Could be for all users or some users. Use case: Inventory issues means we don't have enough
packages to fulfill all customers so we might move. No SKU Changes.
Remove a package from the stream entirely. Use case: We no longer want anyone to receive that package because we can't resource it
anymore. SKU Removal.
Add new packages to the stream. Use case: We decide to extend a stream for another n packages beyond the original subscription
completion (i.e. we add a year to the subscription). Additional SKUs added.
Replace contents of a package (no stream change). Use case: We decided to add some item or swap an item within the package. The
package SKU doesn't change, just the items within that package change.
We create a whole new stream version for new customers. Use case: We add a feature to the stream that the user needs to get in M1
and has follow ons in subsequent packages. In this case the new packages are not backward compatible for existing users who are part
way through the old stream. We version up the stream and have all new SKUs for the packages. We keep existing users on the legacy
stream and new subscriptions would be associated with the new stream.

Key Needs for the user-level Stream:

Stream is set at time of purchase based on the subscription's associated package list. If the package list is changed, the user-level
pending shipments need to be recalculated to use the revised package list.
Customer stream cadence can diverge from package list in a few ways:
Changes to delivery/bill dates (i.e. pause)
Rearranging of the package order by customer service (i.e. CSR may be trying to put two children in the household on the same
cadence, so they would change the order of one child to match that of the other child)
Packages within the user stream shows the status, including whether it's been completed, in progress to send, pending (paid for,
but not yet shipped), skipped, etc. In addition to existing statuses, we need to add a new one for exclude:
Exclude: Customer service has identified that this package, which has not already been shipped to the customer, should
be excluded from future shipments. Today (prior to Next Gen) CSR does this by marking a packages as "shipped" so
that it won't be shipped in the future, but this is untrue from a data perspective. The shipping logic down stream from this
selection should behave similarly to if that package had already been shipped though in that the package will be
excluded from their future stream calculations.
For non-magazine streams, the user would continue to receive monthly packages and just skip over the
excluded ones. i.e. if 3 months from now my planned package was Argentina, but CSR marks it exclude, then 3
months from now I would get the package that comes after Argentina. I should not miss any shipments.
Edge case: For magazine streams, since the packages are tied to a specific month of shipment, if a CSR
excludes a future date package (ex: June 2090), then I would not get a package in that month (June 2090). This
behavior would be similar to pause from a package count perspective. Ex: User pays for 6 months. Month 3
gets excluded by CSR. In this case user would not get a package in month 3, but would get a package in month
7 (so they would get 6 total packages still)
Edge case: CSR should be able to swap a version (case of two kids want to be on the same stream but second kid bought on the new
one). JODI TO ASK CYNTHIA HOW COMMON IS THIS?

Transfer Subscription
General Use Case

The parent of a gift recipient wants to continue the subscription line after the gift has ended, in essence they want to purchase that subscription
line but make sure they continue with the next package in the stream from their gift.

Business Rules

Only canceled subscriptions can be transferred. If a subscription is scheduled for auto-renewal it would not be eligible.
Both canceled-Active and canceled-Expired should be eligible for transfer
When a subscription is transferred the stream associated with that subscription should persist so the child does not receive any repeat
packages.
The person taking over the subscription will need to have or create a Little Passports account with a valid credit card.
The person taking over the subscription should be able to choose from the currently available billing plans for that Subscription Line,
independent of what the gift giver had selected.
Similar to restart, if the subscription is nearing the line completion, they would only have options of billing plans that are shorter
than the number of remaining packages.
Transfer is a moment in time move of the subscription information from one account to another and not a movement of the account itself
or the purchase history. As such:
When a subscription is transferred the original purchaser's purchase and invoice history persists in that purchasers account.
The person taking over the subscription will have only invoice/payment information from their first billing cycle forward.
A transfer could be initiated through:
Customer service. If a customer contacts a CSR they should be able to provide the customer a link to take over the subscription
if it is eligible for transfer.
LP marketing and systems, should be able to email a parent to encourage them to continue the subscription, providing them a
customer-specific link to take over the subscription if it is eligible for transfer.
Need to honor appropriate laws for transactional vs. marketing messaging to the recipient.
After a subscription has been transferred, the original purchaser should not be able to restart that subscription from their account history.
From a data perspective, there should be two distinct customers and two different subscriptions with a reference tying them together.
Reference: How transfer subscription works today

Pricing Change

General Use Case

We decide to increase or decrease the price on a subscription line.

Business Rules

We will need to support two cases

Grandfathered Price Change: The new price is only applied to new users while existing users stay on the old price.
Global Price Change: All users on a specific billing plan/subscription line will experience a change in their price, both existing and
new users.
Phasing: Grandfathered price change is the priority. We can prioritize the global price change at such point as we have a specific use
case/timing that is known.
Handling a price change for these actions is covered in the linked sections:
Subscription Management Business Rules & Use Cases#Pause
Subscription Management Business Rules & Use Cases#Restart

MMB

General Use Case

With each M2+ package shipment we encourage users to add specific items to their upcoming (next) package. They can do this via a link in their
Manage Account screen or from the MMB email.

Business Rules

Specific SKUs can be associated with a package as an MMB item for that SKU
Email
Prior to the fulfillment date for any package that is going to ship as part of an active subscription, we will email the user a single
 combined email with all available MMB upsets for their upcoming package(s).
Since we are going to two billing & fulfillment days per month the email, the email should be triggered based off of logic around
the upcoming package dates and not a hard coded date, i.e. one week prior to fulfillment day (exact logic TBD)
MMB Email landing page allows the bundling of the MMB item(s) with their upcoming package if it is prior to fulfillment date. If after, it can
still be purchased but will ship separately (same logic as today)
Manage Account also has a link to add items to an upcoming package (same logic as today)
Current MMB Documentation (Old Gen)

B2B: Facebook

General Use Case

We have created a custom 3 package subscription that Facebook purchases for their employees kids if they are transferring to a new Facebook
location. The first box ships to the person's home and the subsequent two packages ship to their new Facebook office. This is a non-renewing
one time subscription.

Business Rules

Facebook provides the list of emails/addresses fro the subscriptions

We are able to upload those to Magento and have a subscription and $0 orders created.
Invoice occurs after the subscriptions are created and start shipping.
Fulfillment is via the same fulfillment processes as other subscriptions.
Reference:
Facebook "how to" from the ops team

B2B: Charter Schools

General Use Case

Charter Schools purchase any of our subscription line(s) and pay for them via purchase order.

Business Rules

Reference:
How to process Charter School orders (Purchase Order docs)

Emails (transactional and marketing)

General Use Case

As a Little Passports product manager or marketer, I would like the current triggered emails to continue to work after next generation launches,
using the new data variables from SMS and PS to power them.

Business Rules

List of triggered emails we need to transition to NextGen

Reference: Video of the Email kickoff

TO COME:
School Edition

Inventory Management (shop integration, web site updates, automation)?

Customer Service Subscription Management Use Cases

CS Reference spreadsheet of current solutions

CS Need Customer Use Case Next Gen Solution CS

Spreadsheet
Ref

Subscription Customer is charged for a renewal that he/she does not want and requests immediate Immediate Cancel 2, 29, 31, 32
Rollback remediation.

Create new Customer, affiliate, marketing or internal requests to create a new subscription. Desire is to be Start Subscription (no new 3
sub able to do it via the front end or backend reqs)

Prepay for Customer who has auto-renew off wants to pay for additional time period(s) that are different Phase 1: Encourage to 4
additional from their original subscription, i.e bought 6 months and wants to prepay for another 3 or 12. change billing plan to a 6 or
packages 12 month plan at a discount.
Prepaid stacking will not be
in Phase 1.

Cancel Customer does not want their subscription to auto-renew / continue and requests that Standard Cancel 5&6
subscription auto-renew be disabled

Delay M1 Customer wants their first package delivery to be delayed Delayed Start (no new reqs) 7

Expedite M1 Customer wants their first package to be shipped immediately/quickly Expedited Shipping (no new 8
reqs)

Ship At Once Customer requests that all of their packages be shipped immediately instead of on a monthly No longer supporting this 9
cadence. feature in NextGen. Will use
shop skus instead.

Pause Customer asks that their subscription be paused (MTM or prepaid) until a future date. Pause Subscription 10
Subscription

Same Edition Customer on a monthly wants to change to a prepaid or vice versa on the same subscription Billing Plan Change 11 & 12
Plan Switch - line.
no refund

Same Edition Customer made a mistake and bought a prepaid plan, but really intended for it to be charged Immediate Cancel & restart 13 & 14, 28
Plan Switch - monthly and not all at once. on new billing plan (Billing
with refund Plan Change)

Switch Customer wants to change from one subscription line to another. They may want to do so at the Sidegrade (Immediate or 15, 16, 17 &
Editions end of their current already billed cycle or immediately (with refund given). Stacked) 18, 28

Duplicate Customer had a subscription and instead of restarting/renewing it, they bought a new one that Immediate Cancel to trigger 24
subscriptions, started over. refund on the mistake sub; r
same estart subscription. More
purchaser on Duplicate Subscriptions
(renew
mistake)

Duplicate Purchaser intended to pre-pay for an extended period of time on a gift subscription and bought UI alert; if still do it, can do I 19 & 20
subscriptions, multiple subs, i.e. three monthly subs (intention to prepay for 3 months) mmediate Cancel on extra
same subs and offer to change
purchaser user to a 6 or 12 month plan
(prepaid at discount. More on Duplic
mistake) ate Subscriptions

Multiple A child is receiving multiple subscriptions purchased by different people. Could be they were More on Duplicate 19&20
subscriptions, gifted subs by multiple people or could be that they were already a subscriber and got a gift. Subscriptions
different
purchaser(s)

Catching up A parent has multiple children receiving a subscription and wants them to receive the same Exclude unwanted 21
to sibling packages at the same time packages to catch up child:
More in Subscription
Management Business
Rules & Use
Cases#StreamManagement

Parent A parent whose child was gifted a subscription wants to resume the sub where it left off, but Subscription Management 22
resume gifted may or may not wish to purchase the same billing plan as the gift purchaser Business Rules & Use
sub Cases#TransferSubscription
 Capping A monthly recurring subscription customer wants to end their subscription in the future on a set ??? Future Cancel (reqs to 25
package grid month. come)
on monthly
plans

Charter Charter school provides a PO and we start a new sub for them Charter Schools (reqs to 27
School New come)
Starts

Charter Charter school provides a PO and we renew an existing sub for them. Charter Schools (reqs to 27
School come)
Renewal

Charter Charter school reached out to cancel a sub. We cancel/disable the sub and provide a refund for Charter Schools (reqs to 26
School any remaining packages come)
Cancels

Refunds Customer service may have any number of reasons to give a customer a credit or refund and Phase 1: Refund user or 30
(generically) should be able to apply a credit to any customers account. Example cases: apply promo to future billing.
(Sales&Discounts)
Customer complains that they thought they were getting a promotion but doesn't see it in
their charges (could be they didn't put in the coupon code) Crediting an account is not
Customer has significant problems with delivery and we want to give them a credit as a in Phase 1.
mea culpa

Order extra Customer contacts CS and requests additional items - could be a shop item or part of their kits, Order Items either in 33
items i.e. needs an extra suitcase or passport. Magento or on front end
(existing functionality)

Fulfill missing Customer calls because they did not receive one of their shipments Special Requests(reqs to 34
packages come)

Fulfill missing Customer says items are missing from one of their packages Special Requests(reqs to 35
items come)

Fulfill Customer says their delivery was damaged and requests a replacement. Special Requests(reqs to 36
damaged come)
items

School A recipient of the school edition (which is 6 months long) requests to continue to receive that School Editions (reqs to 37
Editions M7+ subscription. They need to be switched to a standard edition starting on M7. come)

FUTURE PHASES (NOT MVP)

Vindicia retry
Sidegrade
Upgrade
Dowgrade
Customer facing Billing Plan Change
Ship Date to Package Grid and downstream data
Item level association with refunds/orders

Prepaid Stacking
(discuss this vs. non-prepaid - do we limit this to people who had a sub that is either canceled or auto-renewing still? i.e. Allow anyone to buy
additional chunks re)

More Gifting Scenarios

Gift recurring v. non
Give to someone who already has a sub (same or different line)
Give to someone who gets a gift from another giver too
Parent controls - i.e. can a parent pause the line? can the parent do upgrade/downgrade/sidegrade and pay the difference/credit the
difference? Can the parent purchase MMB if the gift giver doesn't, etc.
Transfer (see above)
Gift message on non-bundled items (Shop items)
 CS needs - merging/handling duplicate purchases for the same person from different payers (same line or different line); could be parent
already owned sub and now they are being gifted one in which case ideal is to have the gifted on catch up to where they are on their
existing stream and cancel/pause their sub, or from different people in which case not sure how to handle?

Auto-Migrate
Opt-in or Opt-out possibility
Grandfather pricing possibility

Customer Service Data Requests

Integration with Zendesk
Real time SR List Reporting of reasons code and purchase details.

Back Order Rules (Shop/Subscription?)

Shipping
Ask from Ops:

Ability to add additional shipping speeds/options

Ops Management & Reporting

ASKS:

Fulfillment

Automated/quick transfer of orders to 3PLs, being to schedule, no file extraction or manual manipulation
No manual manipulation of files but need flexibility to be able to manually override for emergency one-off situations.
Daily intro kit fulfillment
Pre-submission verification - ability to verify and confirm a fulfillment file before submission in order to make sure there are no errors
Expedited SKUS during holidays
Being able to fulfill specific groups of orders/customers base don certain criteria (ex. US only, MtM vs. PP, etc.)

Tracking

Automated/quick upload of tracking to customers

Explore 3rd party shipping tracking

Reporting

Reporting on key Ops metrics, from one consolidated source

Automated fulfillment reporting by SKUS, job codes, by specific timeframe, etc.
Automated Ops Dashboard - shipping costs, fulfillment costs, warehousing costs
Automate ship date reporting
Forecasting tools

Billing

Automate Vindicia
Alternate payment methods TBD (Paypal, Apple Pay, etc.)
Ability to change the auto-renewal date more easily

Other

MMB Process: Review upset process and create accessible reporting and regular evaluation
Testing/Sandbox - end-to-end ability to test through fulfillment

Cancel-Save