Feel Pro Club Docs

Appearance

0008. Market Discovery and Player Summoning ​

Status: Approved Author: Codex Created: 2026-03-09

Overview ​

This PRD defines the prototype market where organizers search for available players, inspect detailed free-player profiles, and summon them into active matches. It also captures the player-side visibility toggle shown inside the market.

Problem Statement ​

When a team is short on players, organizers need a fast way to search beyond the fixed roster without abandoning the team workflow. At the same time, players need control over whether they are visible to invitations and what information teams can use to find them.

Goals ​

  • Make free-player discovery fast through search and filtering.
  • Let organizers act directly from discovery into a live match convocatoria.
  • Give players clear control over whether they are open to invitations.

Success Metrics ​

  • High use of market search and filters before player summons.
  • Strong conversion from player detail views to successful summons.
  • Increased share of complete free-player profiles that are actually visible in the market.

Scope ​

In Scope ​

  • Market player list, search, and multi-category filtering.
  • Player visibility toggle from the market surface.
  • Player detail cards with extended availability data.
  • Summon flow from player detail into active-match selection.

Out of Scope ​

  • Team discovery inside the market.
  • Player-to-team applications or direct messaging.
  • Market ranking, recommendations, or pricing mechanics.

Personas and Roles ​

  • Organizer: Needs to find replacement players and summon them into active matches.
  • Visible free player: Wants teams to discover and invite them.
  • Non-visible player: Wants to remain in the app without being open to outside invitations.

User Journey ​

  1. The user opens the Market tab.
  2. The user searches by name or area and optionally applies filters for position, play style, location, days, and time windows.
  3. The user opens a player detail card to inspect the full market-ready profile.
  4. If the current user is allowed to summon, they choose a target active match and complete the summon.
  5. The player appears as invited/summoned in the relevant convocatoria, and the organizer can return to the market or the convocados view.

Functional Requirements ​

Market List and Filters ​

  1. The market shall present a list of available player cards.
  2. The market shall support a free-text search across at least player name and location. Location search shall match against CABA neighbourhood names from the database vocabulary.
  3. The market shall support filter categories for position, play style, locations, available days, and time windows. The location filter shall use the same database-managed CABA neighbourhood vocabulary used during free-player onboarding.
  4. Location filters shall present the CABA neighbourhood vocabulary from the database; no custom location values are accepted.
  5. Applied filters shall appear as removable chips above the list.
  6. The market shall display a result count when search or filtering is active.
  7. Players already summoned by the current organizer shall be visibly marked as summoned in the list.
  8. When search or filtering returns no results, the market shall display an empty-state message.

Visibility Toggle ​

  1. The market shall expose a clear toggle indicating whether the current user's profile is available for invitations. The toggle shall default to off for newly onboarded free players; the player must explicitly enable it to become discoverable.
  2. Turning the toggle off shall communicate that the player will no longer receive invitations.
  3. Turning the toggle on shall communicate that the profile is discoverable again.

Player Detail ​

  1. The player detail screen shall show at least positions, preferred foot, play intensity, preferred group types, desired locations, available days, and preferred times when present.
  2. The detail screen shall support returning to the market without losing global market context.
  3. If the player is already summoned somewhere, the main CTA shall indicate that and allow summoning them to another match. The time-overlap check is enforced at confirmation time, not at summon time.

Summon Guardrails and Match Selection ​

  1. Only organizer-equivalent users shall be able to summon players from the market.
  2. If the user has no administered team, the summon CTA shall block and explain that they need to create a team first.
  3. If the user has administered teams but none with an active match, the summon CTA shall block and redirect the user toward the team workspace.
  4. If summon prerequisites are met, the user shall choose among active matches from eligible teams.
  5. Completing the summon shall create a success state and offer paths back to the market or into the summoned-player list.

Business Rules and Permissions ​

  • Summoning is team- and match-specific, not just a generic "invite player" action.
  • A player may be summoned to multiple matches simultaneously. The time-overlap check is enforced at confirmation time, not at summon time.
  • Turning off market visibility stops future discovery only. Pending invitations and existing confirmations are not affected.
  • Team discovery is out of scope for this MVP phase.
  • Market access in this first phase is organizer-focused; the studied UI does not provide a separate team-discovery experience for free players.
  • An organizer can summon players already in the team regardless of profile completion. Free players can enable market visibility only after completing both the base player profile and the free-player availability profile.

UX Considerations ​

  • Filters should feel fast and additive, with clear visual feedback when they are active.
  • The player detail surface should answer the organizer's core decision quickly: where the player can play, when they can play, and what kind of football they are looking for.
  • Summon guardrail modals should explain the missing prerequisite and route the user to the next best step rather than dead-ending the action.

Error States ​

  • Market list loads shall distinguish no-results empty states from load failures and provide retry without clearing the user's current search text or filter selections.
  • If the filter vocabulary for locations cannot load, the market shall keep previously applied filters visible, disable only the unavailable control, and offer retry rather than breaking the whole screen.
  • Visibility-toggle changes may update optimistically only if the previous state is restored on failure and the user is told whether they are currently discoverable.
  • If a player profile becomes unavailable or a selected match becomes inactive between browse and summon, the summon flow shall stop before commit, explain what changed, and return the user to a refreshed market or match-picker state.
  • Summon completion shall be idempotent. Retrying after a timeout shall not create duplicate invitations for the same player and match.