Marketplace

Marketplace

What the marketplace is

The marketplace is the self-service side of pairing. Instead of the system pairing a support receiver with a support giver behind the scenes, the marketplace lets people browse the programs open to them and apply for the role they want — as a support receiver looking for a coach or mentor, or as a support giver offering to be one. Admins review those applications, and an approval flows straight through to enrollment.

This is one of two ways a program can form pairings: automatic matching (the system proposes pairs based on an algorithm and quotas) and the marketplace (people choose for themselves, within limits the admin sets). A program can lean on one, the other, or a mix of both — the marketplace is the “let people pick” complement to the matching engine, not a replacement for it.

The applicant journey

From the applicant’s side, the marketplace is a short, transparent pipeline:

1. Browse the catalog. A signed-in user sees the programs their organization has published to the marketplace, split by role — programs they could join as a support receiver, and programs they could join as a support giver. The catalog is searchable, and each program card already shows where the viewer stands: eligible, invited, application in review, approved, in a cool-off period, and so on.
2. Open the program detail page. Alongside the program’s description, expectations for the role, and (if configured) a welcome video, the page shows a personal eligibility card: whether this person can apply, and if not, the specific reasons why. Programs can also choose to display their eligibility requirements up front.
3. Apply. The application form (configured per program) opens pre-filled with what the platform already knows about the person. Progress is saved as a draft automatically — an applicant can leave and come back later to finish. Direct links to a program work too: an unauthenticated visitor is sent through sign-in and returned to the same program.
4. Submission and review. On submit, eligibility is re-checked — approval isn’t based on a stale page view. The application then moves through a review pipeline: submitted, under review, and optionally waitlisted, until an admin approves or rejects it. Applicants track all of their applications (both roles) on a My Requests page, where they can continue drafts, view submitted applications, or withdraw one they no longer want to pursue.
5. Approval → enrollment. When an admin approves an application, the person is enrolled into the appropriate cohort role and placed into the pool that serves it — no separate enrollment step for the admin to remember. See Pools and coach supply for what happens on the supply side.

Rejection isn’t a dead end. A program can impose a cool-off period (a number of days before re-applying). The applicant’s card shows the rejection reason and the exact date the cool-off ends, and once it lapses — or if no cool-off was imposed — a re-apply option appears.

Honest states, everywhere

The marketplace is deliberately explicit about why things look the way they do:

• Invitations are visible. Someone who was invited to a program sees an “invited” state on the card; if their invitation has expired and they never applied, the card says so instead of silently disappearing or blocking them without explanation.
• Rejection and cool-off carry their reason on the card, not just a status chip.
• Search survives navigation. Opening a program from search results and coming back returns the person to the same filtered list, not a reset page.
• Empty states tell the truth. “No programs match your search”, “no programs are published for your organization right now”, and “we couldn’t determine your organization — contact support” are three different messages, so a confused user (or an admin helping them) knows immediately which situation they’re in.

Limits on concurrent applications

Organizations can cap how many applications a person may have in flight at once — company-wide, per program, or both. An application counts against the cap while it is live (submitted, in review, waitlisted, or approved and active); the slot is released as soon as it closes — withdrawn, rejected, or the approved participation completes. When someone at their cap tries to apply, they get a clear message rather than a mystery failure, and the cap is enforced safely even if two applications are submitted at the same moment: one goes through, the other is told why it didn’t.

Support givers apply too

The marketplace serves the supply side as well. Coaches and mentors browse the programs open to support givers, apply (or continue a draft), and track their mentor applications in the same My Requests view; support givers also have their own marketplace dashboard. Whether each side can put itself forward is configured per program (see below), so a program can be self-service for participants, for practitioners, for both, or for neither.

What an admin configures

For each program, an admin can set:

• Whether the marketplace is switched on for that program at all. When it’s off, people go through matching (or another configured path) instead.
• The access mode — how open the browsing pool is:
  • Shortlist only: browsing is limited to people who already have a relevant invitation or have been placed on a shortlist for that role. This is the more restricted, curated mode.
  • Open: anyone who meets the program’s eligibility rules can browse and apply, without needing to already be shortlisted.
• Visibility for people who aren’t eligible — either they still see the program listed but can’t apply (with the reason shown), or the program is hidden from them entirely.
• Self-service options per side — whether support receivers can initiate a request themselves, and separately whether support givers can put themselves forward as candidates, each toggled independently.
• A cool-off period — a number of days someone must wait before re-applying after being turned down, to prevent immediate repeat requests.
• A cap on concurrent applications — how many live applications one person may hold for a role in the program (leave it empty for unlimited); a company-wide cap can sit above it.
• Manager approval — an optional requirement that a manager sign off before a candidacy is processed further.
• The application form — the questions applicants answer, with drafts and pre-filling handled by the platform.
• Descriptive content shown to each side — separate “about” and “what to expect” text for support receivers and support givers, which can be written per language so each audience sees the right description in their own language.

Admins also get a marketplace funnel report — how applications flow from submission through review to approval and enrollment over a period, with per-program breakdowns, a time series, filters (date, program, role, cohort), and export.

The tenant-level master switch

Above the per-program settings sits a company-wide switch: a company can turn the marketplace off entirely. When that switch is off, an individual program’s marketplace configuration becomes read-only — admins can see what’s configured, but can’t change it, and the marketplace won’t be shown to end users regardless of the program’s own settings. Turning the company-wide switch back on returns control to the per-program configuration.

In practice, this switch defaults to on, so most companies configure the marketplace at the program level without ever touching the tenant-level switch.

How it relates to matching

Matching and the marketplace are complementary, not competing, systems:

• Matching is admin/algorithm-driven: the program defines pairing rules and quotas, and the system proposes or forms the pairs.
• Marketplace is participant-driven: people browse and choose, subject to the eligibility, access-mode, and approval rules the admin has set.

A program can also combine them — for example, using the shortlist-only access mode so that only people already surfaced through a matching-adjacent process (like an invitation) can browse and finalize their own pairing through the marketplace.

Related pages

• Demand and intake — the broader picture of how people get into a program’s pool, including nominations and direct adds.
• Matching and demand — how the algorithmic side pairs people once they’re in.
• Pools and coach supply — where approved applicants land, and how the supply side is organized.