Skip to content
Sparkus Docs

Pools and coach supply

Pools and coach supply

What a pool is

A pool is a named group of people that a program (or one of its cohorts) can draw on. In practice, pools are how you organize your supply side: the coaches, mentors, and other support givers who will be paired with participants. Pools are created and managed by admins.

A pool can be scoped as broadly or as narrowly as you need — company-wide, per program, or per cohort — and the pools that serve matching are each tied to one role, so a “Coach” pool and a “Mentor” pool are separate groups even inside the same program. A pool can carry an optional capacity (a ceiling on how many members it should hold; leave it empty for no cap), and it can be enabled or disabled without deleting anything.

Pools can hold your own employees, external coaches, or a mix. Companies working with Sparkus-provided coaches can also create a sub-pool drawn from the Sparkus-managed coach pool, filtered by expertise, language, or experience, so a curated slice of that external bench serves a specific program.

Where pools fit in the journey

People move toward a program in stages, and pools mirror those stages:

  1. Talent / shortlist pools — long lists of people you might invite: a “high-potential managers” list, an internal coach bench, a shortlist for an upcoming program. These are curated by hand: you filter your employee population by attributes (expertise, language, experience, profile completeness) and add the right people. From here you can also send platform invitations, individually or in bulk, and see who has been invited and who has accepted.
  2. Awaiting approval — people who have applied (or been put forward) and are waiting for an admin decision. See Demand and intake for how people get to this point.
  3. Enrolled — people who actually hold a role in a cohort.
  4. Available for matching — the working set of support givers that matching draws candidates from for a cohort role.

A person occupies one stage at a time for a given program role — when someone is promoted (say, from awaiting approval to enrolled), they move forward rather than appearing in two stages at once, and the system remembers where they came from. Admins can also move a member between stages by hand when needed.

The pools dashboard shows a live summary of these stages side by side — how many people sit at each step for your company — so you can see at a glance where your supply is building up or thinning out.

The two views: enrollment vs. availability

For each cohort role there are two numbers that matter, and the platform deliberately shows both:

  • The enrollment view — who actually holds the role in the cohort. This is the system of record: it is maintained automatically as people are enrolled and unenrolled, and it is what reports and participation are based on.
  • The availability view — who matching can currently draw on for that role. This is a working view kept in step with enrollment, and it is what the matching engine reads when proposing or forming pairs.

The two are normally identical. The cohort’s pools screen presents them as a small funnel view, side by side per role, so if they ever disagree (imagine a hypothetical cohort showing 40 enrolled but 38 available), the difference is visible immediately instead of hiding behind a single number. Enrollment itself always happens on the cohort’s participants screen — the pools screen is where you see the state, not where you change who is enrolled.

One practical consequence: the participant side of pooling is automatic. Support receivers are placed into their cohort’s bucket as part of being enrolled — you never manage a participant “pool” by hand. The pools you actively curate are the practitioner ones: who is on the coach bench, which cohort they serve, and how much capacity they represent.

Pools are keyed to concrete roles, mapped per cohort

Every pool that serves matching is tied to a specific, concrete program role — “Coach”, “Mentor”, “Reverse Mentor” — not to a generic category. Each cohort role then points at exactly one active pool through an explicit cohort-to-pool mapping. You can re-point a cohort role at a different pool, which is how, for example, two cohorts can share one coach bench while a third runs on its own dedicated pool.

When a marketplace application is approved, the platform enrolls the person into the cohort role and routes them into the mapped pool automatically — see Marketplace for the applicant journey. If a cohort role has no pool mapped yet, approvals still stand; the person is simply held until a pool is mapped, and admins are alerted so the gap gets fixed rather than silently swallowed.

How pools feed matching

Matching sources its candidates from the availability pool mapped to the cohort role. Pool capacity, per-person quotas, and the temporary “reservation” that a pending request places on a support giver’s capacity are all described on the Matching and demand page — the short version is: if the pool has no members, or its members are at capacity, matching has nothing to offer, and that is the first place to look when a cohort “isn’t matching”.

What an admin can do

As an admin you can:

  • Create and edit pools — name, description, capacity, and display order, plus the role/program/cohort scope (chosen when the pool is created), with enable/disable (individually or in bulk).
  • See every pool in one dashboard — searchable and filterable across all pool kinds and stages, with live member counts and the per-stage funnel summary.
  • Manage members — add people to a talent pool from an attribute-filtered view of your population, remove them, pin or reorder members, and send platform invitations with per-member invite status (not invited / invited / accepted).
  • Move members between stages — promote or demote a member within one cohort role’s funnel, with the move recorded.
  • Map cohorts to pools — decide which pool serves each cohort role, and re-point it when programs are reorganized.
  • Check pool health — a built-in, read-only health check reviews each member against readiness requirements for their stage (for example: can they sign in, is their enrollment consistent, is the pool within capacity, have invitees been invited) and rolls the results up into a per-pool status, so you can spot a not-ready bench before a program depends on it.