Subscription Fulfillment Overview

Subscriptions are generally fulfilled through the Olympus application, which has the ability to trigger the creation of a fulfillment batch on the server. This is a somewhat lengthy process. Therefore, the creation of a batch is triggered, which the runs in the background. The status of the batch-creation can be seen (it is noted in the Mailings table). Once the mailing/fulfillment batch is completely created, it can be accessed in various ways (and the system sends an email with the appropriate files attached to the recipients interested in fulfillment batches).

There are two different kinds of fulfillments: Paper fulfillments (those that require physical magazines or welcome packages being sent to the reader) and notifications of new digital issues being read.

Create Fulfillment Batch (Issue-Based Distribution)

Olympus UI for Fulfillment Processing

In Olympus, the creation of fulfillment batches can be triggered through the following UI:

The Create Fulfillment Batch screen is used to generate a print-and-mail fulfillment batch for a specific magazine issue. The operator begins by selecting the target issue, then defines the eligible recipient population through a combination of filters. These include geographic regions (e.g., United States, Canada, Europe, or other international regions), subscription statuses (such as active, expired, cancelled, deleted/flagged, or digital-only tiers), and subscription types (single-copy and/or multi-copy subscriptions). An optional maximum copy limit can be applied to cap the size of the batch.

Additional special handling options control fulfillment behavior, such as preventing duplicate issues from being sent to the same recipient name, bypassing welcome-pack recipients and force-processing subscriptions, and optionally auto-verifying U.S. postal addresses. The system also supports a Test/Count Mode (see below), which runs the full selection logic but does not generate an actual batch; instead, it returns a record count for validation and planning purposes. During execution, the system displays real-time progress feedback while processing the batch criteria and compiling eligible records.

Creating a Test/Count Run

The Test / Count Run option allows users to preview the results of a fulfillment run without creating any actual distribution batches. When this mode is enabled, the system runs the entire fulfillment process exactly as it would for a live batch, including all rules, filters, validations, and cross-checks. The only difference is that no output files, mailing batches, or downstream fulfillment actions are generated.

During a Test / Count Run, the system evaluates region filters, subscription status and type selections, copy limits, duplicate-prevention logic, special handling options, and any enabled address verification rules. All records in the applicable dataset are processed, and all eligibility and exclusion logic is applied. This ensures that the resulting numbers accurately represent what would be produced if the batch were run live.

At the end of the process, the system returns a count of eligible records based on the current configuration. This feature is intended for validation, troubleshooting, planning, and confirmation of fulfillment rules before committing to a live distribution run.

When to Use Test / Count Mode

Test / Count Mode should be used:

• Before creating a new fulfillment batch
• When adjusting region, status, or subscription filters
• After data changes that may affect eligibility
• To estimate batch size or mailing volume
• To confirm that suppression and duplicate rules behave as expected

Step-by-Step Workflow: Running a Test / Count

1. Open the Create Fulfillment Batch screen
   Navigate to the fulfillment batch creation interface for the selected issue.

2. Configure region filters
   Select one or more geographic regions to include in the evaluation.

3. Select subscription statuses
   Choose which subscription states should be considered (e.g., active, expired, cancelled, etc.).

4. Select subscription types
   Specify whether single-copy subscriptions, multi-copy subscriptions, or both should be included.

5. Apply optional limits and special handling rules

   • Set a maximum copy limit if required
   • Enable duplicate suppression
   • Enable or disable welcome pack exclusions. (This means that if welcome packs are excluded, then people who are eligible to receive a welcome pack - likely because they are new subscribers - are excluded from this batch).
   • Enable address verification options as needed. (If this option is on, then US subscription addresses included in this batch will be automatically verified, if they have not been verified yet).

6. Enable Test / Count Mode
   Check the option labeled Do NOT create batch. Count records only.

7. Start processing
   Initiate the run. The system will process all data using the full fulfillment logic.

8. Review progress and completion status
   Monitor the progress indicator while the system evaluates all records.

9. Review the final count results
   Once processing is complete, review the returned record counts to confirm expected results.

10. Adjust configuration if necessary
    If the count does not match expectations, modify the configuration and rerun Test / Count Mode.

11. Proceed to live batch creation (optional)
    Once validated, disable Test / Count Mode and rerun the process to create an actual fulfillment batch.

The Back-End Process to Create Welcome packages

Welcome Packages are a special type of subscription fulfillment. When a subscriber creates a new subscription, the goal is to send them a welcome package as soon as possible, in order to both get a magazine in their hands ASAP, and also to send them additional information about CODE. We currently do this for the US only, although this may change in the future. Also note that sometimes it can be logistically difficult to do this in a timely fashion. In that case, we fail to deliver the first issue of the subscription quickly, but we still want to send other CODE information when we can. Therefore, this process may also sometimes run at a much later point in time.

MORE INFORMATION IS TO BE PROVIDED HERE!!!

The Back-End Process to Create Regular Fulfillments

• When the system receives a request to create a new fulfillment batch, it first creates a record in the Mailings table, which indicates that a new batch exists.
• The system then flags that batch as 0% complete (that is the percentage of creation completeness… it has nothing to do with whether or not mailings have actually been processed by US mail or any other mailing provider).
• The sysem can receive a request to create a “count-only” batch. Such a batch can be thought of as a “test batch”, which goes through the whole process, but instead of creating fulfillment records, it just counts the number of copies and individual recipients. A record in the Mailings table is still created as an anchor to tie the long running process to. In this case, the bCountOnly flag is set to true. After the completion of the counting process, this record is removed from the system. (Note that this record does not show up through the Olympus interface).
• The system then triggers a background process that can run for a while. At that point, control is returned to the user.

Once the creation of a batch is triggered on the UI, the process will continue to its conclusion, even if the UI is shut down. Theoretically, multiple batches can be created at the same time. However, that is only recommended for different distribution regions.

At this point, the background process starts the heavy lifting and digs through the subscriber records in order to create an appropriate fulfullment batch including the individual subscribers. For that, the following steps are taken:

• All subscribers with a certain status at a certain date (typical the current date) are queried, for all the regions included in the request. For instance, all Active subscribers with a valid subscription on the day the process is run, in the US and Canada regions may be considered.
• The system then processes each subscriber and checks whether that subscriber has already received their magazine. This could be because the subscription was handled in a prior fulfillment batch (or a welcome package), or - in rare cases - because the same subscriber already happened to receive promotional issus that ended up covering our obligation towards that subscriber.
• The system also checks whether the subscriber is a new subscriber from the US region, who have never received a welcome package. If they need to receive a welcome package, they are excluded from the batch, unless we force an override to process all subscribers regardless.
• If the system determines that the subscriber in question still needs to receive magazines, the sytem checks whether the subscriber is a single-copy or multi-copy subscriber, and whether or not those are to be included (requests can be created for single-copy subscribers, multi-copy subscribers, or both).
• If the request is for a real distribution batch (not just counting records) the system takes a snap-shot of the subsriber and subscription, including data such as:
  • The name as it appears at that point in time is stored in the SubscriptionFulfillments table.
  • The address the mailing is sent to at that time is stored in the SubscriptionFulfillments table.
  • The current expiration date of the subscription is stored in the SubscriptionFulfillments table.
  • Full and quick qualification dates are stored in the SubscriptionFulfillments table.
  • Whether the subscription was considered a paid subscription at that point in time is stored in the SubscriptionFulfillments table.
  • The subscription status (since we can force expired or inactive subscriptions in special cases) is stored in the SubscriptionFulfillments table.
  • The offer and referral codes the subscription was based on at that time are stored in the SubscriptionFulfillments table.
  • If a subscription is considered paid, then whether or not the bill was paid (or remained unpaid) at that point in time is stored in the SubscriptionFulfillments table.