Sports Club Administration Opportunity Audit
Status: Active Last reviewed: 2026-06-28
This audit compares the current TwoMore app against the market research and identifies how to improve the product so it can own the niche of sports club administration, starting with Korean amateur tennis clubs.
Use this with:
- Market & Revenue Research for external competitor and pricing signals.
- App Functionality Map for the tab-by-tab and backend capability map.
- Product Spec Sheet for personas, scope, and success metrics.
- Roadmap for sequencing and acceptance gates.
- Roadmap Implementation Plan for concrete slices under the club-admin roadmap tracks.
Broad Picture
TwoMore's strongest market position is not "another tennis matching app," "a court-booking marketplace," or "a replacement for KakaoTalk/BAND." The stronger position is:
The operating system for Korean amateur tennis clubs and pickup hosts.
The codebase already contains many of the ingredients needed for this position: club roles, member flows, sessions, RSVP, dues, per-session payments, attendance, guest applications, reports, records, rankings, analytics, venues, weather/TMI, share routes, and compliance rails.
The gap is not raw capability. The gap is workflow consolidation. Much of the admin value is spread across separate screens, so a 총무 still has to remember where to look. The market opportunity is to turn those primitives into a weekly operating cockpit: one place that shows what needs attention, why it matters, and the shortest path to resolve it.
Strategic Thesis
The wedge should be "reduce club-admin chasing."
That means TwoMore should make these jobs visibly easier:
- Who is coming this week?
- Who has not paid?
- Which transfers need confirmation?
- Which members have attendance/no-show risk?
- Which guests or join requests need a decision?
- Which session needs scores, attendance, payment closeout, or a recap?
- Which club profile/growth actions will bring in the right players?
If TwoMore answers those questions faster than Kakao, BAND, spreadsheets, bank transfer screenshots, and ad hoc bracket tools, it can charge for organizer value before trying to monetize player-side identity or venue booking.
Where Club Administration Belongs
Club administration should not displace Home's current job. Home is already the highest-frequency surface: it consolidates club and pickup sessions, live play, today/week/month schedule, progress, and attention items. That is the right shape.
The club-admin architecture should be:
| Layer | Role |
|---|---|
| Home | Role-gated attention layer. Show urgent admin exceptions only when the viewer is an admin with work to do. |
| Clubs tab | Primary club operating destination. Make club value visible through joined-club cards, club health, next sessions, role badges, and admin-action counts. |
| Club detail | Full club workspace. Members get home/news/ranking; officials get the admin cockpit and management tools. |
| Activity/session detail | Session execution. Hosts manage session-specific actions here, while club-level exceptions roll up to Clubs/Home. |
This preserves privacy and role gates: non-members should not see private club operations, and ordinary members should not see admin-only actions. The change is attention architecture, not permission loosening.
Market Read
The market research points to six durable realities:
| Reality | Product implication |
|---|---|
| Korea already has default communication habits through KakaoTalk and BAND. | Integrate with those habits. Do not try to replace group chat as the first value proposition. |
| Generic group/team tools already cover messages, calendars, RSVP, polls, and payments. | TwoMore must specialize in tennis and club operations, not generic scheduling. |
| Korean tennis apps compete on matching, friends, lessons, rankings, and court discovery. | Player discovery is crowded. The less crowded wedge is retained club administration. |
| Tournament/bracket apps solve event-format problems. | TwoMore should connect match flow to membership, attendance, payments, records, and club retention. |
| Global racquet/facility SaaS validates bookings, memberships, events, payments, lessons, POS, and reporting. | Venue/facility revenue is credible but should follow club density and operational proof. |
| Payment products create support, refund, and trust burdens. | Manual payment tracking can be valuable now; real PortOne monetization should wait for production payment proof. |
Primary market sources used by the companion market brief include MCST's sports participation survey summary, Kakao IR materials, BAND, CourtReserve, Playtomic, TeamSnap, OpenSports, Spond, PortOne, SMASH, Baceline, TeChinSo, and Korean bracket tools. Treat external pricing as directional; validate Korean willingness to pay with pilot clubs.
Current App Strengths
Club Operating Core
TwoMore already has the admin primitives that generic chat tools do not combine:
| Current surface | Evidence | Strength |
|---|---|---|
| Club admin hub | packages/features/clubs/src/club-detail/admin-tab.tsx | Central route into members, dues, attendance, analytics, sessions, board, inter-club, venues, and settings. |
| Club dues | packages/features/clubs/src/club-dues-screen.tsx, packages/app/src/presentation/hooks/queries/use-dues.ts | Monthly dues, paid/unpaid/partial/waived state, notes, overdue dues query, member/admin modes. |
| Club attendance | packages/features/clubs/src/club-attendance-screen.tsx | Per-member attendance rates, strike counts, flagged members, excuse action. |
| Session attendance | packages/features/sessions/src/session-attendance-screen.tsx | Session-level attendance confirmation for confirmed RSVPs. |
| Session payments | packages/features/sessions/src/session-payments-screen.tsx, packages/app/src/adapters/supabase/session-payment.supabase.ts | Per-session payment roster, pending/paid/waived state, submitted-transfer badge, paid-no-show signal. |
| Guest applications | packages/features/sessions/src/pickup-host-dashboard-screen.tsx, packages/app/src/presentation/hooks/queries/use-guest-applications.ts | Host surface for pending guest applications, approve/decline, bulk approve, cancellation. |
| Club analytics | packages/features/clubs/src/club-analytics-screen.tsx, packages/app/src/domain/entities/club-analytics.entity.ts | Growth/profile completeness, pending applications, sessions, active members, attendance rate, dues rate. |
Player Retention Core
The app is not only admin tooling. It gives players reasons to come back: records, rankings, achievements, match board, scorecards, practice log, profile, friends, DM, activity, and share-card routes. This matters because admin SaaS only works if members continue using the player side.
Distribution Core
The app already treats share and public routes as important. That is right for the Korean market: Kakao/BAND should be distribution and communication layers, while TwoMore should become the structured system of record.
Architecture Core
The project has a strong multi-agent development substrate: active docs, generated current-state pages, VitePress tracker, architecture tests, ESLint project rules, PI schema lint, and stale-reference lint. This makes the admin niche feasible to build iteratively without letting strategy drift away from implementation.
Product Gap Analysis
1. Admin Value Is Distributed, Not Consolidated
The admin tab is currently a navigation hub with live badges for pending join requests and overdue dues. The underlying app has richer operational facts: payments, submitted transfers, no-show risk, pending guest applications, reports, sessions needing closeout, and analytics signals.
Improvement: turn the admin tab into a cockpit, not only a menu.
Before building the cockpit UI, build a club-operations read model that can serve both the Clubs tab and role-gated Home exception cards. This avoids manually reassembling admin state in two separate surfaces.
The cockpit should group work by urgency:
- Today and this week: upcoming sessions, RSVP shortfalls, payment deadlines.
- Money: unpaid holds, submitted transfers, overdue dues, paid-no-show review.
- Trust: attendance flags, no-shows, reports, blocked/safety review.
- Growth: pending join/guest applications, incomplete club profile, share actions.
- Closeout: sessions missing attendance, scores, payment confirmation, or recap.
2. Analytics Are Informative, But Not Yet Prescriptive
The analytics screen exposes useful numbers, including profile completeness, pending applications, sessions, active members, attendance rate, and dues rate. Those are good metrics, but admins need next actions.
Improvement: every admin metric should answer "what should I do next?"
Examples:
- Low dues rate -> show unpaid member list and reminder action.
- Low attendance rate -> show flagged members and next session attendance prompt.
- Pending applications -> route directly to approve/reject queue.
- Profile completeness below target -> show exact missing fields and share impact.
- Session utilization low -> suggest share/invite path for the next session.
3. Payment Tracking Is Valuable Before Full Payment Processing
TwoMore already tracks manual participation fees and dues. That is useful even before PortOne production rails are complete because clubs already use bank transfer and screenshot-based workflows.
Improvement: strengthen trust around manual payments first.
Near-term:
- Add clearer ledger/reconciliation views for admins.
- Make submitted transfer review prominent in the cockpit.
- Keep manual paid/waived decisions auditable.
- Show member-facing payment status with low ambiguity.
- Define support/refund/correction states before real processor rollout.
Gated later:
- PortOne production payment confirmation.
- Webhook/idempotency smoke proof.
- Refund/support workflow.
- Fee disclosure and legal review.
4. Guest And Pickup Workflows Should Feed The Club Admin Pipeline
Guest applications and pickup-host actions exist, but they are mostly localized to pickup/session management. For admin value, those decisions should appear in the weekly club operating view.
Improvement: surface pending guest applications and host decisions alongside join requests, attendance risk, and session readiness.
This is how TwoMore can beat generic team apps: guest participation affects club quality, payment reliability, no-show risk, records, and future membership.
5. Kakao/BAND Should Become Distribution, Not Competition
Kakao/BAND inertia is real. TwoMore should not ask clubs to abandon their social channels immediately.
Improvement: make TwoMore the place where structured decisions are made, then send concise summaries back to chat.
Strong share targets:
- Session RSVP link.
- Payment/dues reminder summary.
- Weekly attendance/payment closeout recap.
- Club leaderboard or match-result card.
- Join/guest application link.
6. Venue Booking Should Stay Behind Club Density
Facility SaaS and racquet platforms validate booking, payments, memberships, and lessons, but direct booking requires supply, settlement, support, and inventory control. TwoMore's current advantage is club operations, not venue inventory.
Improvement: start with venue-aware operations.
Near-term venue work should help admins run sessions:
- Canonical venue/court attachment to sessions.
- Booking-link or contact handoff.
- TMI/weather visibility.
- Venue notes useful to members and guests.
Direct booking can wait until repeated manual handoff demand is proven.
7. Multi-Sport Expansion Should Be Delayed, But The Admin Primitives Should Be Clean
The sports club administration niche is broader than tennis, but tennis should remain the proof market. Do not generalize match formats, ratings, or sport models before tennis retention is proven.
Improvement: keep tennis-specific product surfaces, but implement reusable admin primitives underneath:
- Member roster.
- Event/session lifecycle.
- RSVP/waitlist.
- Fees/dues/payment status.
- Attendance/reliability.
- Guest/applicant decisions.
- Reports/moderation.
- Announcements/share recaps.
- Exports/analytics.
Improvement Map
| Opportunity | Current evidence | Recommended improvement | Success signal | Where to look |
|---|---|---|---|---|
| Admin cockpit | Admin tab routes to many operational screens but only exposes limited counts. | Replace the menu-first admin tab with grouped exception cards and drill-down actions. | A seeded admin can identify all unresolved weekly work without opening each sub-screen. | packages/features/clubs/src/club-detail/admin-tab.tsx; new cockpit read model/hook under packages/app/src/presentation/hooks/queries/. |
| Club tab prominence | Joined-club cards sort by next session, but admin value remains mostly hidden inside club detail. | Add role-aware club card signals: next session, role, club health/activity, and admin-action badges. | A club official can see which club needs attention before opening each club detail page. | packages/features/clubs/src/club-list-screen.tsx; packages/features/clubs/src/shared/my-club-card.tsx; club operations read model. |
| Home admin attention | Home surfaces user attention, live play, and recommendations; admin exceptions are not yet a first-class home signal. | Add small role-gated exception cards for urgent admin work, deep-linking back to the club cockpit or existing admin screens. | Admin work appears in Home only when actionable and never becomes a full admin console. | packages/features/home/src/home-feed-screen.tsx; packages/features/home/src/shared/home-recommendations-section.tsx; club operations read model. |
| Session closeout | Attendance and payment screens exist separately. | Add a post-session closeout workflow: attendance -> payment confirmation -> score/record review -> recap/share. | Fewer sessions remain missing attendance/payment/record state after completion. | packages/features/sessions/src/session-attendance-screen.tsx; packages/features/sessions/src/session-payments-screen.tsx; session detail surfaces. |
| Payment trust | Manual payment state exists; PortOne is scaffolded but gated. | Add ledger/reconciliation clarity before real processor rollout. | Admin can explain every pending, submitted, paid, waived, and no-show payment row. | packages/app/src/adapters/supabase/session-payment.supabase.ts; dues and payment hooks; PortOne guide. |
| Dues automation | Monthly dues management and overdue dues query exist. | Promote overdue dues into cockpit and add reminder/action affordances. | Dues follow-up starts from a prioritized exception list. | packages/features/clubs/src/club-dues-screen.tsx; packages/app/src/presentation/hooks/queries/use-dues.ts. |
| Attendance reliability | Member attendance rates, strike counts, and session attendance exist. | Show attendance risk in cockpit and trigger follow-up after missed closeout. | Admins can resolve flagged members and missing session attendance from one queue. | packages/features/clubs/src/club-attendance-screen.tsx; packages/features/sessions/src/session-attendance-screen.tsx. |
| Guest/member intake | Join requests and guest applications exist in separate flows. | Combine pending join and guest decisions into a single intake lane. | Admin can process intake without hunting through club/session screens. | packages/app/src/presentation/hooks/queries/use-club-join-requests.ts; packages/app/src/presentation/hooks/queries/use-guest-applications.ts. |
| Growth loop | Share routes and analytics exist. | Turn profile completeness and session-share prompts into admin actions. | More invited users land in the correct club/session path. | Share routes, public preview screens, club analytics. |
| Reporting/safety | Report/block infrastructure exists. | Surface unresolved reports in admin/safety lane where roles allow. | Safety exceptions are visible before they become trust failures. | Report hooks/adapters and club admin role gates. |
| Pricing readiness | Subscription/payment scaffolds and market brief exist. | Add value counters: exceptions resolved, payments tracked, reminders sent, admin time saved. | Pilot clubs can see why Organizer Pro is worth paying for. | Entitlement/subscription models; analytics; cockpit event tracking. |
Executable Slice Map
Use these as roadmap candidates. Each slice should stay bounded and verified before moving to the next one.
| Slice | Goal | Start condition | Acceptance proof | Verification ladder | Blocked scope |
|---|---|---|---|---|---|
| SCA-0 Admin workflow teardown | Capture the actual admin workflow from current screens and seeded data. | Current app can run locally with seeded club/session/payment data. | A docs artifact lists the admin jobs, current screen paths, missing links, and screenshots or screen notes. | yarn docs:check; manual screen inventory. | New product code. |
| SCA-1 Club operations read model | Aggregate counts and priority items for one club admin view, reusable by Clubs and Home. | SCA-0 identifies the exact first set of cockpit cards and Home exception signals. | Focused hook/read-model tests prove counts for sessions, dues, payments, attendance, intake, and reports. | Unit tests; yarn check. | New visual redesign beyond displaying read-model data. |
| SCA-2 Clubs admin prominence | Make unresolved weekly work visible from the Clubs tab and club detail admin cockpit. | SCA-1 read model exists. | Seeded admin sees prioritized club/action cards with drill-downs to existing screens. | Device/manual smoke; route smoke; accessibility pass; yarn check. | Payment processor changes; venue marketplace. |
| SCA-3 Home admin exceptions | Add role-gated Home exception cards for urgent admin work only. | SCA-2 proves the cockpit destinations and deep links. | Admin sees actionable Home alerts only when work exists; ordinary members/non-members do not see admin-only content. | Role-gated smoke; hook tests; yarn check. | Turning Home into a full admin console. |
| SCA-4 Session closeout | Reduce post-session cleanup work. | Cockpit can identify a completed session with missing closeout. | Admin can complete attendance, payment review, score/record review, and recap from one flow. | Seeded session smoke; mutation tests for money/trust state. | Full accounting export. |
| SCA-5 Payment trust ledger | Make manual money tracking defensible. | Session payment and dues status flows are stable. | Admin can review every money exception and correction state. | Hook/adapter tests; seeded manual-payment smoke. | Real PortOne charge capture until external gates close. |
| SCA-6 Kakao-native admin sharing | Push structured summaries back into existing chat habits. | Domain/share setup and Kakao template constraints are confirmed. | Admin can share session, payment, dues, or recap links with useful previews. | Share-route smoke; Kakao template smoke when credentials exist. | Replacing chat or building a chat-first strategy. |
| SCA-7 Organizer Pro pilot | Validate willingness to pay for admin value. | Cockpit and closeout are used by pilot clubs. | Pricing interview/pilot data shows retained admins would pay for the workflow. | Pilot ledger; analytics; support-load review. | Broad subscriptions before payment/legal readiness. |
Development Guardrails
- Keep final launch readiness after R1 club growth, R2 organizer operations, and R3 product polish evidence, while tracking external launch blockers in parallel.
- Keep Kakao/BAND as distribution, not enemy platforms.
- Do not start with direct booking marketplace work.
- Do not charge for real payments before PortOne, refund, support, and legal gates are closed.
- Do not generalize to multi-sport until tennis club retention is proven.
- Preserve one visible app rating unless there is strong evidence to split it.
- Keep every admin improvement source-grounded: current app evidence, market evidence, acceptance proof, and verification.
Recommended Next Step
Build SCA-0 and SCA-1 before doing any large UI redesign. The cockpit should be driven by a real read model, not by manually assembling scattered screen state in the component tree. Once the read model is tested, SCA-2 can make the admin tab feel like the product's strongest surface rather than a menu.
Maintenance Rule
Refresh this audit when:
- The app adds or removes an admin capability.
- The market brief changes competitor or revenue assumptions.
- The roadmap changes R2 Organizer Operations.
- Pilot-club evidence changes the admin workflow or willingness-to-pay thesis.
When this document changes, run:
yarn docs:generate
yarn docs:check