Tutor LMS Course Bundle exposes bundles as wp_posts (post_type=course-bundle) with the included courses listed in wp_postmeta under a serialised _tutor_bundle_course_ids key. Per-user enrolment lives in wp_tutor_enrolled, and per-lesson progress comes from wp_tutor_lesson_complete and the standard wp_comments table that Tutor uses for completion records. The default bundle admin screen shows individual bundle posts and their pricing; per-bundle progress reports aren't a built-in view.

SleekView reads course-bundle posts and joins them to tutor_enrolled by mapping the serialised course-id list onto enrolment rows. A bundle roster shows each subscriber's progress across every course in the bundle in one row. A bundle-completion report sorts buyers by completion percentage so high-engagement buyers (good for testimonials) and stalled buyers (need outreach) are both visible in the same screen. A bundle-versus-single-course report compares whether bundle buyers complete more courses than people who bought courses individually.

Inline edits to enrolment route through Tutor LMS's API where supported so completion hooks fire and certificates issue. Direct table edits are available for finance back-fills like correcting historical enrolment dates. Multi-instructor sites get instructor-scoped views via WP capability gating so each instructor sees only the bundles that include their own courses.

Bundling is a margin lever in LMS businesses, but bundles only work commercially when buyers actually complete the included courses, and that's the operational layer most LMS admin screens treat as someone else's problem. Tutor LMS Bundles stores enough information to answer the important questions (which bundles convert, which bundles get completed, which bundles get sold-and-shelved) but it stores that information as serialised postmeta plus enrolment rows in a separate table, and joining them is a custom-SQL job by default. Marketing wants to find high-engagement bundle buyers for case studies.

Program managers want to know whether a bundle's promised value actually plays out across the included courses. Instructors want to know which bundles include their courses and how those buyers are progressing so they can run targeted outreach. None of these are dashboards Tutor ships, and they're not dashboards a typical LMS admin should be writing SQL to produce.

SleekView's job is to unpack the serialised bundle composition, join it to the live enrolment and progress tables, and let each role build the saved view they actually need. Same data, hooks fire when wanted, dramatically less time spent in spreadsheets.