MemberPress Bundle (sold inside MemberPress as the Groups feature on Pro plans) lets you group several memberships into one purchaseable bundle. The bundle itself is a memberpressgroup CPT, the child memberships are memberpressproduct CPTs, and each customer purchase still writes one row per granted membership into mepr_transactions and one row into mepr_subscriptions with a shared group_id column linking them back to the parent bundle.

The default MemberPress admin shows transactions and subscriptions as flat tables, so a single bundle purchase appears as several rows with no obvious join back to the bundle. The Reports module aggregates revenue per product but does not surface a per-bundle, per-customer view where you can see who bought the bundle, how many child memberships they currently hold, and whether any of those children have lapsed independently.

SleekView reads mepr_transactions and mepr_subscriptions and joins them on group_id back to the memberpressgroup CPT so each row shows the customer, the bundle, which child memberships are still active, total bundle revenue per customer, and last renewal status. Bundle-level retention queries become one filter instead of stitched-together exports.

Bundles are how membership stores raise average order value, but they also create an operational blind spot in the default admin. Every bundle purchase writes multiple flat rows into the transactions and subscriptions tables, which the default admin shows as separate transactions with no parent grouping. That makes the most important bundle question (which customers have lapsed on one child but kept the others) invisible without exports or SQL.

SleekView groups transactions and subscriptions by group_id and user_id so each bundle purchase is one row with children-active count and per-bundle revenue inline. Membership admins get a partial-lapse view that is the retention queue for bundle products specifically, finance teams get per-bundle revenue per customer for the high-value targeting list, and support gets the at-a-glance view of which children in a bundle are active when a customer asks why a specific resource disappeared. The default admin stores all of this data but cannot surface it.

The joined workspace turns it into one screen.