Matching and demand

The mental model

Think of matching in two layers:

The program defines the rules of the game — which roles are being paired (for example Support Giver ↔ Support Receiver), how strict or open eligibility is, what quotas/capacity apply, and which matching mode is used (manual, self-service, hybrid, or API-based import).
The cohort is where a matching event actually happens — a specific run against a specific pool of enrolled participants, producing (or proposing) pairs for that cohort.

The program-level settings are the default “recipe.” A cohort inherits that recipe unless something more specific overrides it. This split is the single most important thing to orient a new admin around, because the same word (“matching”) is used to describe configuration screens (program side) and an execution screen (cohort side), and they are not interchangeable.

What you configure at the program level

Matching mode. Each program has a default matching mode, and — importantly — each support-giving role within the program can have its own mode that overrides the program default. The available modes are:

Manual — an admin manually creates every pairing; no algorithm involved.
Self-Service — participants browse a directory and choose their own match.
Hybrid — the system proposes a shortlist, the participant ranks their preferred choices, and an admin (or automated acceptance) finalizes the pairing. This is the recommended default for most programs.
API-based — pairings are imported from an external system (for example, existing manager–employee relationships from an HR system) rather than computed.

Algorithm (conceptually). Programs can select a named “algorithm template” that drives how candidates are scored/ranked for Hybrid or self-service suggestion purposes. Admins pick a template and can adjust the relative importance (“weights”) of different matching factors; they are not expected to understand or edit the underlying scoring math itself. A “run a simulation” option lets an admin preview what pairings the current template/weights would suggest, without committing anything — useful for sanity-checking a configuration before it’s used live.

Timeout and response behavior. When a Hybrid/self-service request is sent to a prospective Support Giver, the program defines how many days that person has to respond, and what happens if they don’t respond in time (the request can either be automatically cancelled, or automatically approved).

Quotas / capacity. Programs can cap how many matches a single Support Receiver may hold, and — separately — how many a single Support Giver may hold. These caps are enforced when someone attempts to add a new match; the system also tracks a temporary “reservation” state for any pending Hybrid/self-service request so that a Support Giver’s capacity isn’t double-booked while a request is awaiting their response. If the request is declined, times out, or is cancelled, the reservation is released back to available capacity.

Re-matching. Programs can choose whether a confirmed match is permanent, or whether participants may be re-matched later.

Eligibility and pools — the “who can even be considered” layer

Before anyone is matched, they first have to be eligible to participate in a given role for a given program. Eligibility can be driven by rules configured on the program (for example, requiring specific attributes or requiring a demand-collection form to be filled in). If a program has no active eligibility rules configured, every active person in the company is treated as eligible by default — eligibility is opt-in stricter, not opt-in open.

Once someone is eligible, admins work through a small pipeline of screens to actually shortlist and pool them:

An eligible pool view shows everyone currently eligible for a role, lets an admin search/filter them, and add selected people onto a short list.
Short list groups organize shortlisted people into named buckets that map either to a specific cohort (for Support Receivers) or to a specific Support Giver pool (for Support Givers). This mapping is what eventually connects “who’s eligible” to “which cohort or pool they’ll actually land in.”
Support Giver pools are the sets of coaches/mentors available to a given cohort and role; the pools screen shows current membership, capacity, and utilization (members vs. capacity) at a glance, plus recent join activity.
A request queue / applications view lets admins review and approve or reject people who applied or were nominated, before they’re promoted into the eligible/shortlisted pipeline.

This is a genuinely separate screen family from the matching-configuration screens above — eligibility/demand answers “who is in the running,” while program matching configuration answers “how will the running people be paired.”

The confusing split, named explicitly

Matching-related settings currently live in more than one place, and a new admin should expect to hop between them:

Program-level matching settings — the default mode, algorithm template, weights, timeout, and quota ceilings for the whole program.
Per-role overrides — an individual support-giving role can override the program’s default mode and/or algorithm template.
Demand/eligibility screens — a separate section entirely, governing who is even eligible and how they get pooled/shortlisted, which indirectly constrains who a matching run can draw from.
The cohort matching screen — where an admin looks at a specific cohort’s actual candidates and pairings, and can create, edit, or unmatch pairs by hand.

There is no single “matching settings” page that shows all of this at once — an admin configuring or debugging matching behavior for a cohort may need to check the program’s matching page, that role’s override, the demand/eligibility pages, and the cohort page itself.

What a cohort matching run actually produces today

At the cohort level, the matching screen shows: participants who are not yet matched, the pool of available Support Givers for that cohort, any pending “requests” awaiting a Support Giver’s response (with their expiry), current confirmed pairs, and past requests that were declined/expired/cancelled.

From this screen an admin can, today, act directly on pairings: create a manual match between a specific Support Receiver and Support Giver, edit an existing pair by swapping in a different Support Giver (capacity is re-validated when doing so), unmatch/break an existing pair, accept a pending request on a Support Giver’s behalf, and re-send the confirmation/agreement workflow for a pair. Assigning which Support Giver pool feeds a cohort is also done here.

There is a “runs” history list per cohort, intended to show past matching runs (when they happened, what algorithm was used, how many pairs came out, how long it took). At present this reflects only the manual actions described above, not an automated batch algorithm run — there isn’t currently a one-click “run the algorithm across the whole cohort” action; pairing happens one request/decision at a time (manually, or via a participant’s Hybrid shortlist selection). Treat any “batch run” language elsewhere as aspirational rather than a current capability.

Practical guidance for admins

If a cohort “isn’t matching,” check in this order: (1) does the program’s matching mode/role override make sense for what’s expected, (2) are the right people showing up as eligible, (3) are they on a short list mapped to this cohort/pool, (4) does the Support Giver pool assigned to this cohort actually have capacity.
Quota exhaustion and pending-request “holds” are a common source of “why can’t I add this Support Giver” — a Support Giver can look full because of pending requests, not just confirmed matches.
The algorithm/weights screen is for tuning suggestion quality (Hybrid/self-service ranking) and previewing via simulation — it does not itself execute a run against a cohort.