Diagnostics: a healthy program, and why matching stalls

This page is for program admins who need a quick answer to “why is nobody getting matched?” — and a way to check a program is set up correctly before that question comes up.

The healthy-program checklist

Before matching can produce pairings, confirm each of these:

Both roles are configured on the program. Every matching relationship needs a Support Receiver–side role and a Support Giver–side role defined and enabled for the program. If only one side is configured, matching has nothing to pair against.
People are actually enrolled in the cohort, not just invited. Being on an invitation or shortlist is a different state from being enrolled. Matching pulls from enrolled cohort membership — an invitation that hasn’t been accepted yet does not make someone available to match.
Enrolled people have logged in at least once. A person can be enrolled and still not be usable in matching if they’ve never signed in or accepted their invite. This is checked per person, not just at the cohort level.
Support Givers have an available quota. Every Support Giver has a maximum number of concurrent matches, resolved from (in order of precedence): a manual admin exception, their own per-program capacity setting, a global cap on their user profile, the program’s default, or the tenant-wide default. If none of these are set, capacity is treated as unlimited. If a Support Giver is already at their cap — from active matches or from matches still pending acceptance — they will not appear as available, even if everything else about them is correctly configured.
Support Givers have marked themselves available for matching. This is a toggle Support Givers control themselves (in their own profile/settings), separate from their enrollment and their quota. A fully enrolled, under-quota Support Giver who has switched themselves to unavailable will not show up as a candidate.
If the program uses demand-based pool mapping, the mapping actually points somewhere. Some programs route Support Giver supply through explicit pool-to-cohort mappings (e.g., a specific coach pool assigned to a specific cohort) rather than “everyone enrolled as a Support Giver in this cohort.” If that mapping exists but is empty or misconfigured, the system falls back to the plain cohort-role pool — worth checking directly if you expected a specific curated pool to be used instead.
Something has actually triggered matching. Configuring roles, quotas, and pools prepares a program — it doesn’t create pairings by itself. In self-service or hybrid programs, matching happens when participants open the matching window and make their selections; nothing further needs to be “run” by an admin. In manually-matched programs, an admin creates each match directly, and it takes effect immediately — there is no separate “run” step to trigger. If you’re waiting for something to “run” on its own, there’s nothing to wait for: the fix is either to create matches directly, or to make sure self-service is open to participants.
For hybrid/self-service flows, someone still has to act on a pending request. A Support Receiver choosing a Support Giver creates a temporary hold on that Support Giver’s quota (an escrow), not an instant match. If the Support Giver doesn’t accept, decline, or let it expire, the pairing stays unresolved. Check for pending requests sitting unanswered before assuming matching itself is stuck.
If the program requires prerequisites, the affected people have completed them. Some programs require a participant to finish something first — such as a required exercise or form — before they can be matched. If prerequisites are enabled and someone hasn’t completed them, they won’t be matchable yet. Check whether prerequisites are turned on for the program and whether the people you expect to match have completed them.

Symptom → likely cause → what to check

”No one is getting matched”

This is almost always one precondition failing quietly, not a single big switch. Work through these in order:

Cause: the cohort has items and structure but no real participants yet. A program can be fully built out — items, milestones, matching rules — and still have an empty or near-empty cohort if invitations were sent but never accepted, or if people were added to a waiting list rather than enrolled. Check: look at actual enrolled counts for each role in the cohort, not just invited counts. If invited-but-not-accepted is high, that’s your answer — chase acceptance, not matching config.

Cause: only one side of the pair is present. If there are Support Receivers but no eligible Support Givers (or vice versa) in the cohort, there is nothing to pair against. Check: confirm both roles have enrolled, logged-in members. It’s easy to onboard participants and forget to also onboard/enroll the coach or mentor side.

Cause: Support Givers exist but are all at capacity. Every Support Giver has an effective quota. If your Support Givers already have live matches, or have pending requests waiting on their response, they can look “full” even though the roster looks fine. Check: look at each Support Giver’s current match count and pending requests against their configured maximum (their own setting, a global cap, or the program/tenant default, whichever applies). A single unusually low individual cap is enough to silently exclude someone from a run.

Cause: Support Givers have switched themselves to unavailable. This is a self-service toggle, so it’s outside the admin’s normal view unless specifically checked. Check: verify availability status for the Support Givers you expect to be active. This is a common reason a Support Giver who should be poolable — enrolled, logged in, under quota — is still absent from the shortlist.

Cause: a demand-mapped pool is pointing at the wrong (or an empty) set of people. Programs that use curated Support Giver pools mapped to specific cohorts depend on that mapping being correct. An empty or stale mapping quietly falls back to the plain cohort roster, which may not be who you intended. Check: confirm the pool-to-cohort mapping resolves to the people you expect. If it resolves to nobody, the system substitutes the broader cohort pool — so it may look like “it’s not really broken,” but it’s not using the pool you configured either.

Cause: matching was configured but never triggered. Setting up roles, rules, and quotas prepares a program for matching — it doesn’t perform it, and it doesn’t happen on a timer by itself. Check: in self-service or hybrid programs, check whether participants have actually opened and used the matching window yet — that participant activity is what starts the process, not an admin action. In manually-matched programs, check whether anyone has actually created matches yet; there is no separate batch “run” to kick off first. A program that looks “ready” in every configuration screen can simply be waiting for one of these.

Cause: prerequisites are blocking part of the group. If the program requires people to complete something before matching (a required exercise or form, for example), anyone who hasn’t finished it is held back. Check: see whether prerequisites are enabled for the program, and whether the people you expected to match have completed what’s required.

Cause: requests are pending, not stuck. In self-service or hybrid modes, a participant’s selection creates a hold on the other side’s quota while a response is awaited. If nobody accepts or declines, the pairing sits open indefinitely. Check: look for pending requests older than expected, and follow up with the Support Giver (or use the timeout/auto-approve setting for the program, if configured) rather than treating it as a matching failure.

”Some people are matched, but far fewer than expected”

Usually a subset of the causes above applies to part of the population — commonly:

A minimum-quota Support Giver (or a small group) hit their cap early and now looks “gone” from later runs.
A specific pool mapping only covers part of the cohort, so people outside that mapping fall back to (or are excluded from) the general pool depending on configuration.
A subset of participants never accepted their invitation and were never really enrolled, despite appearing on an early roster export.

Check: compare the enrolled-and-eligible count against the invited/roster count for each role, and check quota headroom for the specific Support Givers who “should” be receiving matches but aren’t.

”A Support Receiver can’t see a particular Support Giver they expect to see”

Check, in order: is the Support Giver enrolled in the same cohort and role; are they marked available for matching; do they have remaining quota; if the program uses pool mapping, are they inside the mapped pool (not just the general cohort).