feat: flatten routes and merge marketing and onboarding directories
This commit is contained in:
906
prd-template/campmatch-campreg-master-prd.md
Normal file
906
prd-template/campmatch-campreg-master-prd.md
Normal file
@@ -0,0 +1,906 @@
|
||||
# CampMatch + CampReg Master Product Requirements Document
|
||||
|
||||
**Version:** 0.1
|
||||
**Date:** 2026-06-01
|
||||
**Working Product Names:** CampMatch, CampReg
|
||||
**Related Systems:** VibnAI, Missinglettr API
|
||||
**Primary User Types:** Parents, Kids, Providers
|
||||
|
||||
---
|
||||
|
||||
## 1. Executive Summary
|
||||
|
||||
CampMatch + CampReg is a connected discovery, registration, operations, and growth platform for the youth camp and activity market.
|
||||
|
||||
CampMatch is the parent-facing discovery and matching layer. It helps families find camps and activities that fit a child’s age, interests, schedule, location, budget, needs, and preferences.
|
||||
|
||||
CampReg is the provider-facing registration and operations layer. It helps camps, schools, clubs, coaches, and youth activity providers manage listings, sessions, registrations, payments, forms, attendance, communications, staff workflows, parent relationships, and mobile operations.
|
||||
|
||||
VibnAI is the growth automation layer. It helps providers improve listings, create campaigns, fill under-enrolled sessions, reactivate past families, generate local content, and automate marketing execution through the Missinglettr API.
|
||||
|
||||
The ecosystem thesis:
|
||||
|
||||
> CampMatch creates demand.
|
||||
> CampReg converts and manages demand.
|
||||
> VibnAI grows demand.
|
||||
> Missinglettr distributes campaigns.
|
||||
|
||||
This product should not be built as a narrow camp registration tool. It should be built as a camp marketplace and provider operating system designed around three users: parents, kids, and providers.
|
||||
|
||||
---
|
||||
|
||||
## 2. Product Vision
|
||||
|
||||
### 2.1 Vision Statement
|
||||
|
||||
Make it dramatically easier for families to find the right camps and for providers to fill, manage, and grow their programs.
|
||||
|
||||
### 2.2 Product Mission
|
||||
|
||||
CampMatch + CampReg exists to reduce friction across the full camp lifecycle:
|
||||
|
||||
1. Parents discover better-fit camps.
|
||||
2. Kids get better-fit experiences.
|
||||
3. Providers fill programs and operate more efficiently.
|
||||
4. Growth becomes automated instead of manual.
|
||||
|
||||
### 2.3 Product Thesis
|
||||
|
||||
The current camp software market is fragmented between directories, registration systems, payment tools, spreadsheets, email platforms, and manual marketing. Parents struggle to compare options. Providers struggle to be discovered, fill sessions, and manage operations. Existing camp management platforms are operationally useful but often lack modern marketplace distribution, mobile-first workflows, API-first architecture, and automated growth.
|
||||
|
||||
CampMatch + CampReg should combine:
|
||||
|
||||
- Discovery marketplace
|
||||
- Registration engine
|
||||
- Provider CRM
|
||||
- Payments and ledgers
|
||||
- Parent portal
|
||||
- Staff mobile tools
|
||||
- Communication tools
|
||||
- Growth automation
|
||||
- Open API and webhook infrastructure
|
||||
- Compliance-by-design privacy and security controls
|
||||
|
||||
### 2.4 Strategic Positioning
|
||||
|
||||
CampMatch + CampReg is not only “camp registration software.” It is:
|
||||
|
||||
> A discovery, registration, operations, and growth ecosystem for kids’ camps and youth activity providers.
|
||||
|
||||
---
|
||||
|
||||
## 3. Core User Types
|
||||
|
||||
## 3.1 Parents / Guardians
|
||||
|
||||
Parents are the primary buyer, decision-maker, account owner, consent provider, payer, and communication recipient.
|
||||
|
||||
### Parent Jobs To Be Done
|
||||
|
||||
- Find camps that match a child’s age, interests, availability, location, needs, and budget.
|
||||
- Compare camps without opening dozens of tabs.
|
||||
- Understand dates, price, schedule, activities, safety policies, and requirements.
|
||||
- Register one or more children quickly.
|
||||
- Pay deposits, installments, or full balances.
|
||||
- Complete forms, waivers, uploads, medical information, and emergency contacts.
|
||||
- Manage authorized pickups.
|
||||
- Receive reminders, announcements, schedule changes, and urgent updates.
|
||||
- Track waitlist status.
|
||||
- Manage all camp activity from a mobile device.
|
||||
- Re-register easily in future seasons.
|
||||
|
||||
### Parent Success Criteria
|
||||
|
||||
- Can find relevant camps quickly.
|
||||
- Can register from mobile without confusion.
|
||||
- Can trust the provider information.
|
||||
- Can complete required forms without repeated data entry.
|
||||
- Can see what is still outstanding.
|
||||
- Can manage payments and documents in one place.
|
||||
- Receives timely, useful communication.
|
||||
|
||||
---
|
||||
|
||||
## 3.2 Kids / Campers
|
||||
|
||||
Kids are the beneficiaries of the experience and the center of matching, registration, attendance, and future personalization. In early versions, kids should not require direct accounts. Their information should be parent-owned and parent-controlled.
|
||||
|
||||
### Kid-Centered Product Principle
|
||||
|
||||
Most camp platforms treat children as records. CampMatch should treat kids as the reason the platform exists.
|
||||
|
||||
### Kid Data Used for Matching
|
||||
|
||||
- Age
|
||||
- Grade
|
||||
- Location
|
||||
- Schedule availability
|
||||
- Interests
|
||||
- Activity preferences
|
||||
- Skill level
|
||||
- Social preferences
|
||||
- Previous camp history
|
||||
- Accessibility needs
|
||||
- Medical/allergy flags where relevant
|
||||
- Parent-entered notes
|
||||
- Feedback after attendance
|
||||
|
||||
### Kid Experience Goals
|
||||
|
||||
- Better camp fit.
|
||||
- Less mismatch between parent expectations and child interests.
|
||||
- Easier repeat registration into camps the child enjoyed.
|
||||
- Safer operational handling through accurate emergency, allergy, pickup, and attendance records.
|
||||
|
||||
### Kid Account Policy
|
||||
|
||||
For the initial product, kids should generally not have independent login accounts. If future child-facing features are added, they must be designed with heightened consent, privacy, moderation, and age-appropriate safeguards.
|
||||
|
||||
---
|
||||
|
||||
## 3.3 Providers
|
||||
|
||||
Providers include summer camps, day camps, overnight camps, schools, after-school programs, sports clubs, coaches, art programs, youth organizations, outdoor programs, specialty camps, and multi-location operators.
|
||||
|
||||
### Provider Jobs To Be Done
|
||||
|
||||
- Claim or create a listing.
|
||||
- Publish accurate camp/program information.
|
||||
- Manage seasons, programs, sessions, pricing, forms, and capacity.
|
||||
- Accept registrations and payments.
|
||||
- Manage waitlists.
|
||||
- Communicate with parents.
|
||||
- Manage attendance and check-in/check-out.
|
||||
- Manage authorized pickups.
|
||||
- Manage staff permissions.
|
||||
- Track health/medication information where required.
|
||||
- View revenue, enrollment, and demand reporting.
|
||||
- Launch automated growth campaigns.
|
||||
- Fill under-enrolled sessions.
|
||||
- Reactivate past families.
|
||||
- Manage operations from desktop and mobile.
|
||||
|
||||
### Provider Success Criteria
|
||||
|
||||
- More registrations with less admin.
|
||||
- Better visibility on CampMatch.
|
||||
- Fewer manual spreadsheets.
|
||||
- Faster registration and payment collection.
|
||||
- Safer attendance and pickup workflows.
|
||||
- Easier communication.
|
||||
- Marketing automation without needing a marketing team.
|
||||
|
||||
---
|
||||
|
||||
## 4. Product Pillars
|
||||
|
||||
## 4.1 Discovery
|
||||
|
||||
Help parents find the right camp or activity for each child.
|
||||
|
||||
Required capabilities:
|
||||
|
||||
- Location-based search
|
||||
- Category-based search
|
||||
- Age filtering
|
||||
- Date filtering
|
||||
- Price filtering
|
||||
- Availability filtering
|
||||
- Saved camps
|
||||
- Comparison tools
|
||||
- Provider profiles
|
||||
- Camp detail pages
|
||||
- Matching based on child interests and parent constraints
|
||||
- Trust indicators
|
||||
- Direct registration or lead capture
|
||||
|
||||
## 4.2 Registration
|
||||
|
||||
Make it easy for parents to register, pay, and complete requirements.
|
||||
|
||||
Required capabilities:
|
||||
|
||||
- Parent accounts
|
||||
- Family profiles
|
||||
- Camper profiles
|
||||
- Multi-child registration
|
||||
- Dynamic forms
|
||||
- Waivers and e-signatures
|
||||
- Document uploads
|
||||
- Payment collection
|
||||
- Deposits
|
||||
- Installments
|
||||
- Waitlists
|
||||
- Confirmation flows
|
||||
- Parent dashboard
|
||||
|
||||
## 4.3 Operations
|
||||
|
||||
Give providers tools to run camp safely and efficiently.
|
||||
|
||||
Required capabilities:
|
||||
|
||||
- Program/session management
|
||||
- Rosters
|
||||
- Attendance
|
||||
- Check-in/check-out
|
||||
- Authorized pickup verification
|
||||
- Staff mobile access
|
||||
- Staff roles
|
||||
- Health/medical access controls
|
||||
- Communication tools
|
||||
- Reporting
|
||||
- Audit logs
|
||||
|
||||
## 4.4 Growth
|
||||
|
||||
Use VibnAI and Missinglettr to help providers grow enrollment.
|
||||
|
||||
Required capabilities:
|
||||
|
||||
- Listing improvement recommendations
|
||||
- Campaign generation
|
||||
- Social campaign automation
|
||||
- Local SEO content generation
|
||||
- Parent reactivation
|
||||
- Underfilled session campaigns
|
||||
- Demand signal analysis
|
||||
- Campaign performance reporting
|
||||
|
||||
## 4.5 Trust
|
||||
|
||||
Build around safety, consent, privacy, provider verification, child data protection, and transparent communication.
|
||||
|
||||
Required capabilities:
|
||||
|
||||
- Provider verification
|
||||
- Parent consent capture
|
||||
- Privacy controls
|
||||
- Role-based permissions
|
||||
- Audit trails
|
||||
- Secure health data segmentation
|
||||
- Data export/deletion workflows
|
||||
- Clear communication history
|
||||
|
||||
## 4.6 Mobile-First Experience
|
||||
|
||||
Mobile is required for both parents and staff. It is not a secondary channel.
|
||||
|
||||
Required capabilities:
|
||||
|
||||
- Mobile discovery
|
||||
- Mobile registration
|
||||
- Mobile forms
|
||||
- Mobile payments
|
||||
- Mobile parent portal
|
||||
- Staff rosters
|
||||
- Staff check-in/check-out
|
||||
- Pickup verification
|
||||
- Emergency contacts
|
||||
- Incident logging
|
||||
- Offline/degraded-mode planning for critical workflows
|
||||
|
||||
---
|
||||
|
||||
## 5. Scope Philosophy
|
||||
|
||||
The product should not use a “nice-to-have” framing for required workflows. If a workflow is necessary for a camp to operate safely, convert registrations, communicate with parents, or comply with reasonable privacy/security expectations, it should be considered in-scope.
|
||||
|
||||
However, the build can be sequenced. Sequencing is not the same as excluding features.
|
||||
|
||||
### 5.1 Required Product Areas
|
||||
|
||||
- CampMatch discovery marketplace
|
||||
- CampReg provider operations
|
||||
- Parent registration and portal
|
||||
- Kid-centered matching data model
|
||||
- Provider listing management
|
||||
- Payments and billing
|
||||
- Attendance and mobile staff operations
|
||||
- Communication
|
||||
- Waitlists
|
||||
- Staff roles and permissions
|
||||
- Compliance and security foundations
|
||||
- API and webhooks
|
||||
- VibnAI growth automation
|
||||
- Missinglettr API integration
|
||||
|
||||
### 5.2 Explicitly Out of Scope Unless Later Approved
|
||||
|
||||
- Independent child social accounts
|
||||
- Open child-to-child messaging
|
||||
- Unmoderated child-generated content
|
||||
- Direct card data handling
|
||||
- Selling medical compliance as guaranteed HIPAA compliance without legal review
|
||||
- Building a native mobile app before the core responsive/PWA workflow is validated, unless operational needs demand it earlier
|
||||
|
||||
---
|
||||
|
||||
## 6. Marketplace + Operations Architecture
|
||||
|
||||
### 6.1 System Relationship
|
||||
|
||||
CampMatch and CampReg should be separate but deeply connected products.
|
||||
|
||||
CampMatch handles:
|
||||
|
||||
- Search
|
||||
- Discovery
|
||||
- Matching
|
||||
- Listings
|
||||
- City/category pages
|
||||
- Parent-facing camp comparison
|
||||
- Lead generation
|
||||
- Marketplace attribution
|
||||
|
||||
CampReg handles:
|
||||
|
||||
- Provider onboarding
|
||||
- Registration setup
|
||||
- Session management
|
||||
- Forms
|
||||
- Payments
|
||||
- Attendance
|
||||
- Parent CRM
|
||||
- Communication
|
||||
- Reporting
|
||||
- Provider growth workflows
|
||||
|
||||
VibnAI handles:
|
||||
|
||||
- Listing optimization
|
||||
- Campaign recommendations
|
||||
- Content generation
|
||||
- Local SEO expansion
|
||||
- Underfilled session campaigns
|
||||
- Automated marketing planning
|
||||
|
||||
Missinglettr handles:
|
||||
|
||||
- Social campaign creation
|
||||
- Campaign scheduling
|
||||
- Content distribution
|
||||
- Post-level campaign execution
|
||||
|
||||
### 6.2 Registration Modes
|
||||
|
||||
CampMatch + CampReg must support multiple provider adoption levels.
|
||||
|
||||
#### Mode 1: Directory Link-Out
|
||||
|
||||
Provider is listed on CampMatch but registration happens externally.
|
||||
|
||||
Required functionality:
|
||||
|
||||
- Public listing
|
||||
- External registration URL
|
||||
- Click tracking
|
||||
- Provider claim option
|
||||
- Listing update requests
|
||||
- Attribution of outbound clicks
|
||||
|
||||
#### Mode 2: Lead Capture
|
||||
|
||||
Parent submits interest through CampMatch/CampReg, but enrollment is completed manually by the provider.
|
||||
|
||||
Required functionality:
|
||||
|
||||
- Lead form
|
||||
- Child age/interests capture
|
||||
- Parent contact capture
|
||||
- Provider notification
|
||||
- Lead status management
|
||||
- Follow-up reminders
|
||||
- VibnAI follow-up suggestions
|
||||
|
||||
#### Mode 3: Full CampReg Registration
|
||||
|
||||
Parent discovers the camp on CampMatch and completes registration, forms, and payment through CampReg.
|
||||
|
||||
Required functionality:
|
||||
|
||||
- Full parent account
|
||||
- Child profile
|
||||
- Session selection
|
||||
- Forms
|
||||
- Waivers
|
||||
- Payments
|
||||
- Confirmation
|
||||
- Parent portal
|
||||
- Provider roster
|
||||
- Attendance-ready enrollment
|
||||
|
||||
---
|
||||
|
||||
## 7. Provider Onboarding
|
||||
|
||||
### 7.1 Provider Claim Flow
|
||||
|
||||
Providers should be able to claim an existing CampMatch listing or create a new provider account.
|
||||
|
||||
Required steps:
|
||||
|
||||
1. Search for existing provider listing.
|
||||
2. Request ownership.
|
||||
3. Verify identity/ownership.
|
||||
4. Create provider organization account.
|
||||
5. Import or confirm existing listing data.
|
||||
6. Add programs/sessions.
|
||||
7. Select registration mode.
|
||||
8. Configure payments where applicable.
|
||||
9. Configure forms and waivers.
|
||||
10. Publish updates to CampMatch.
|
||||
11. Launch first growth campaign through VibnAI.
|
||||
|
||||
### 7.2 Provider Verification
|
||||
|
||||
Verification may include:
|
||||
|
||||
- Business email domain verification
|
||||
- Website ownership verification
|
||||
- Manual admin review
|
||||
- Phone verification
|
||||
- Document upload where needed
|
||||
- Existing public listing comparison
|
||||
|
||||
### 7.3 Provider Setup Wizard
|
||||
|
||||
The initial setup should guide providers through:
|
||||
|
||||
- Organization profile
|
||||
- Locations
|
||||
- Camp categories
|
||||
- Age ranges
|
||||
- Season dates
|
||||
- Sessions
|
||||
- Pricing
|
||||
- Capacity
|
||||
- Registration mode
|
||||
- Required forms
|
||||
- Payment setup
|
||||
- Staff invites
|
||||
- Communication settings
|
||||
- Marketplace publish preview
|
||||
|
||||
---
|
||||
|
||||
## 8. Parent Journey
|
||||
|
||||
### 8.1 Discovery Journey
|
||||
|
||||
1. Parent enters location, child age, interests, and desired dates.
|
||||
2. CampMatch returns relevant camps.
|
||||
3. Parent filters by category, distance, date, price, age, and availability.
|
||||
4. Parent saves or compares camps.
|
||||
5. Parent views camp details.
|
||||
6. Parent starts registration, lead inquiry, or external booking.
|
||||
|
||||
### 8.2 Registration Journey
|
||||
|
||||
1. Parent creates account or logs in.
|
||||
2. Parent creates or selects child profile.
|
||||
3. Parent selects session.
|
||||
4. Parent completes required forms.
|
||||
5. Parent uploads documents if needed.
|
||||
6. Parent signs waivers.
|
||||
7. Parent pays deposit, full amount, or joins payment plan.
|
||||
8. Parent receives confirmation.
|
||||
9. Parent sees the registration in portal dashboard.
|
||||
10. Parent receives reminders for outstanding tasks.
|
||||
|
||||
### 8.3 Parent Portal Journey
|
||||
|
||||
Parents can:
|
||||
|
||||
- View registered camps
|
||||
- View upcoming sessions
|
||||
- Manage payments
|
||||
- Complete outstanding forms
|
||||
- Update emergency contacts
|
||||
- Manage authorized pickups
|
||||
- Monitor waitlists
|
||||
- Receive messages
|
||||
- Update child preferences
|
||||
- Register again for future sessions
|
||||
|
||||
---
|
||||
|
||||
## 9. Kid Matching Engine
|
||||
|
||||
### 9.1 Purpose
|
||||
|
||||
The matching engine should help parents find better-fit camps for each child by combining structured filters, child interests, provider attributes, and marketplace behavior.
|
||||
|
||||
### 9.2 Matching Inputs
|
||||
|
||||
- Child age
|
||||
- Grade
|
||||
- Location
|
||||
- Date availability
|
||||
- Interests
|
||||
- Skill level
|
||||
- Preferred camp type
|
||||
- Indoor/outdoor preference
|
||||
- Social preference
|
||||
- Accessibility needs
|
||||
- Parent budget
|
||||
- Past registrations
|
||||
- Parent saved camps
|
||||
- Provider categories
|
||||
- Provider availability
|
||||
- Provider capacity
|
||||
|
||||
### 9.3 Matching Outputs
|
||||
|
||||
- Recommended camps
|
||||
- Fit explanations
|
||||
- Similar camps
|
||||
- Saved searches
|
||||
- Alert when a matching camp opens
|
||||
- Waitlist suggestions
|
||||
- Seasonal recommendations
|
||||
|
||||
### 9.4 Fit Explanation
|
||||
|
||||
Each recommendation should explain why it was shown, for example:
|
||||
|
||||
- “Good match for ages 9–12.”
|
||||
- “Matches soccer interest.”
|
||||
- “Available during your selected week.”
|
||||
- “Within 8 km of your location.”
|
||||
- “Has full-day programming.”
|
||||
|
||||
---
|
||||
|
||||
## 10. Provider Operations
|
||||
|
||||
Required modules:
|
||||
|
||||
- Organization management
|
||||
- Provider profile
|
||||
- Locations
|
||||
- Programs
|
||||
- Seasons
|
||||
- Sessions
|
||||
- Pricing
|
||||
- Capacity
|
||||
- Registration setup
|
||||
- Forms
|
||||
- Waivers
|
||||
- Payments
|
||||
- Rosters
|
||||
- Waitlists
|
||||
- Attendance
|
||||
- Check-in/check-out
|
||||
- Pickup authorization
|
||||
- Staff accounts
|
||||
- Roles and permissions
|
||||
- Communication
|
||||
- Reporting
|
||||
- Growth automation
|
||||
|
||||
---
|
||||
|
||||
## 11. Payments and Billing
|
||||
|
||||
### 11.1 Payment Philosophy
|
||||
|
||||
CampReg should not store or process raw credit card data. Payment compliance should be handled by payment processors such as Stripe. CampReg stores references, transaction status, invoices, ledger entries, and reconciliation data.
|
||||
|
||||
### 11.2 Required Payment Capabilities
|
||||
|
||||
- Deposits
|
||||
- Full payment
|
||||
- Payment plans
|
||||
- Installments
|
||||
- Autopay
|
||||
- Promo codes
|
||||
- Discounts
|
||||
- Financial aid discounts
|
||||
- Refunds
|
||||
- Failed payment handling
|
||||
- Family ledger
|
||||
- Provider payout tracking
|
||||
- Tax/fee support
|
||||
- Invoice receipts
|
||||
|
||||
### 11.3 Marketplace Payment Model Options
|
||||
|
||||
- Provider-owned Stripe account using Stripe Connect
|
||||
- Platform-managed payment flow with provider payouts
|
||||
- External payment link for link-out providers
|
||||
- Manual payment recording for providers not ready for online payments
|
||||
|
||||
---
|
||||
|
||||
## 12. Communication
|
||||
|
||||
Required capabilities:
|
||||
|
||||
- Email
|
||||
- SMS
|
||||
- Push notifications when app/PWA supports them
|
||||
- Portal announcements
|
||||
- Session-specific messages
|
||||
- Roster-specific messages
|
||||
- Waitlist messages
|
||||
- Payment reminders
|
||||
- Form reminders
|
||||
- Emergency announcements
|
||||
- Marketing campaigns through VibnAI/Missinglettr
|
||||
|
||||
Communication must respect user consent, opt-out rules, and the distinction between operational messages and marketing messages.
|
||||
|
||||
---
|
||||
|
||||
## 13. Mobile Experience
|
||||
|
||||
Mobile is required for parents and staff.
|
||||
|
||||
Parent mobile must support:
|
||||
|
||||
- Search
|
||||
- Compare
|
||||
- Register
|
||||
- Pay
|
||||
- Complete forms
|
||||
- Upload documents
|
||||
- Sign waivers
|
||||
- Manage schedule
|
||||
- Manage waitlists
|
||||
- Receive updates
|
||||
- Manage pickups
|
||||
|
||||
Staff mobile must support:
|
||||
|
||||
- Roster views
|
||||
- Check-in
|
||||
- Check-out
|
||||
- Authorized pickup verification
|
||||
- Emergency contact access
|
||||
- Allergy/medical flags based on permission
|
||||
- Incident logging
|
||||
- Attendance notes
|
||||
- Announcements
|
||||
- Offline/degraded-mode workflows for critical roster access
|
||||
|
||||
---
|
||||
|
||||
## 14. API and Integration Strategy
|
||||
|
||||
CampReg should be API-first because providers will increasingly expect integrations with marketing systems, accounting systems, CRMs, analytics tools, and custom workflows.
|
||||
|
||||
Required API resources:
|
||||
|
||||
- Organizations
|
||||
- Providers
|
||||
- Locations
|
||||
- Programs
|
||||
- Sessions
|
||||
- Families
|
||||
- Parents
|
||||
- Campers
|
||||
- Registrations
|
||||
- Enrollments
|
||||
- Forms
|
||||
- Form submissions
|
||||
- Payments
|
||||
- Invoices
|
||||
- Ledger entries
|
||||
- Attendance records
|
||||
- Pickup authorizations
|
||||
- Staff
|
||||
- Roles
|
||||
- Messages
|
||||
- Leads
|
||||
- Marketplace listings
|
||||
- Campaigns
|
||||
- Webhook subscriptions
|
||||
|
||||
Required webhooks:
|
||||
|
||||
- provider.claimed
|
||||
- listing.updated
|
||||
- lead.created
|
||||
- registration.started
|
||||
- registration.completed
|
||||
- payment.succeeded
|
||||
- payment.failed
|
||||
- waitlist.joined
|
||||
- waitlist.opening_available
|
||||
- camper.checked_in
|
||||
- camper.checked_out
|
||||
- form.completed
|
||||
- message.sent
|
||||
- campaign.created
|
||||
- campaign.scheduled
|
||||
|
||||
---
|
||||
|
||||
## 15. Reporting and Analytics
|
||||
|
||||
Required analytics:
|
||||
|
||||
- Listing impressions
|
||||
- Listing clicks
|
||||
- Leads
|
||||
- Registration starts
|
||||
- Registration completions
|
||||
- Conversion rate
|
||||
- Revenue
|
||||
- Outstanding balances
|
||||
- Capacity fill rate
|
||||
- Waitlist size
|
||||
- Underfilled sessions
|
||||
- Parent reactivation opportunities
|
||||
- Campaign performance
|
||||
- Year-over-year enrollment
|
||||
- Search demand by category/location/age
|
||||
|
||||
---
|
||||
|
||||
## 16. VibnAI Growth Automation
|
||||
|
||||
VibnAI should operate as a growth assistant for providers.
|
||||
|
||||
Required capabilities:
|
||||
|
||||
- Improve provider listings
|
||||
- Generate camp descriptions
|
||||
- Create FAQs
|
||||
- Suggest photos/content gaps
|
||||
- Generate landing pages
|
||||
- Create local SEO pages
|
||||
- Generate social campaigns
|
||||
- Send campaigns to Missinglettr API
|
||||
- Detect underfilled sessions
|
||||
- Suggest reactivation campaigns
|
||||
- Recommend promotions
|
||||
- Analyze marketplace demand
|
||||
|
||||
Human approval should be required before outbound marketing campaigns are published or scheduled.
|
||||
|
||||
---
|
||||
|
||||
## 17. Compliance and Security
|
||||
|
||||
Required security foundations:
|
||||
|
||||
- Role-based access control
|
||||
- Permission-scoped health data
|
||||
- Parent consent capture
|
||||
- Child data protection
|
||||
- Audit logs
|
||||
- Encryption in transit and at rest
|
||||
- Secure file uploads
|
||||
- Payment tokenization through processor
|
||||
- Data deletion/export workflows
|
||||
- Breach response procedure
|
||||
- Consent distinction between operational and marketing messaging
|
||||
|
||||
Required regulatory areas to account for:
|
||||
|
||||
- Canada: PIPEDA and provincial privacy considerations
|
||||
- Quebec: Law 25 considerations
|
||||
- United States: COPPA, state privacy laws, HIPAA-aligned controls where health data is handled
|
||||
- Payments: PCI scope reduction through third-party payment processor
|
||||
- SMS/email: consent and opt-out requirements
|
||||
|
||||
---
|
||||
|
||||
## 18. Success Metrics
|
||||
|
||||
### Parent Metrics
|
||||
|
||||
- Search-to-listing click rate
|
||||
- Listing-to-registration-start rate
|
||||
- Registration completion rate
|
||||
- Mobile completion rate
|
||||
- Form completion time
|
||||
- Parent support requests per registration
|
||||
- Repeat registration rate
|
||||
|
||||
### Kid Fit Metrics
|
||||
|
||||
- Saved camp rate
|
||||
- Repeat attendance
|
||||
- Parent-reported fit score
|
||||
- Post-camp feedback
|
||||
- Interest-to-registration conversion
|
||||
|
||||
### Provider Metrics
|
||||
|
||||
- Listing claim rate
|
||||
- Time to publish registration
|
||||
- Registration volume
|
||||
- Capacity fill rate
|
||||
- Revenue processed
|
||||
- Underfilled session recovery
|
||||
- Campaign adoption
|
||||
- Provider retention
|
||||
|
||||
### Marketplace Metrics
|
||||
|
||||
- Organic search traffic
|
||||
- City/category search demand
|
||||
- Provider listing coverage
|
||||
- Search result click rate
|
||||
- Lead volume
|
||||
- Full registration conversion
|
||||
|
||||
### Growth Automation Metrics
|
||||
|
||||
- Campaigns generated
|
||||
- Campaigns approved
|
||||
- Posts scheduled through Missinglettr
|
||||
- Reactivation conversion
|
||||
- Underfilled sessions improved
|
||||
- Cost per registration
|
||||
|
||||
---
|
||||
|
||||
## 19. Reference Products and APIs
|
||||
|
||||
### CampMinder API
|
||||
|
||||
Useful as a reference for camp data syncing, marketing integrations, and guided API services. Public materials describe integrations with tools such as Mailchimp, Constant Contact, Salesforce, Google Sheets, and financial/accounting systems.
|
||||
|
||||
Reference: https://campminder.com/features/api/
|
||||
Reference: https://campminder.com/features/api-services/
|
||||
Reference: https://help.campminder.com/en/articles/6988427-get-to-know-campminder-api
|
||||
|
||||
### CampSite API
|
||||
|
||||
Useful as a reference for a REST API covering families, campers, staff, groups, guests, donors, medical, reports, financial transactions, enrollment, custom fields, bunking, and transportation.
|
||||
|
||||
Reference: https://support.campmanagement.com/hc/en-us/articles/6375219096205-What-can-we-do-with-CampSite-s-API
|
||||
Reference: https://support.campmanagement.com/hc/en-us/articles/4405656076557-Does-CampSite-integrate-with-any-third-party-softwares-e-g-QuickBooks
|
||||
|
||||
### ACTIVE Network API
|
||||
|
||||
Useful as a reference for public activity discovery. ACTIVE’s Activity API is read-only and exposes public data for events and activities, including youth camps.
|
||||
|
||||
Reference: https://developer.active.com/docs/read/Activity_APIs
|
||||
|
||||
### eCamp v3
|
||||
|
||||
Useful as an open-source reference for camp planning, scheduling, activity plans, responsive camp tools, and printable plans. It is not a registration/payment system, but it can inform future scheduling/planning workflows.
|
||||
|
||||
Reference: https://www.ecamp3.ch/en/
|
||||
Reference: https://github.com/ecamp/ecamp3
|
||||
|
||||
### Hi.Events
|
||||
|
||||
Useful as an open-source reference for event registration, ticketing, checkout, analytics, product add-ons, promo codes, webhooks, and self-hosted event infrastructure.
|
||||
|
||||
Reference: https://github.com/HiEventsDev/Hi.Events
|
||||
|
||||
### Attendize
|
||||
|
||||
Useful as an older open-source reference for event ticketing, custom questions, checkout, payment gateways, attendee management, messaging, affiliate tracking, and QR-based check-in.
|
||||
|
||||
Reference: https://github.com/Attendize/Attendize
|
||||
|
||||
---
|
||||
|
||||
## 20. Open Questions
|
||||
|
||||
- Should CampMatch and CampReg share one login system from day one?
|
||||
- Should parents be able to create child preference profiles before any provider is onboarded?
|
||||
- Should providers pay for CampReg separately, or should monetization be tied to marketplace transactions?
|
||||
- Should CampReg use Stripe Connect as the default payment architecture?
|
||||
- Should provider listing claims require manual review?
|
||||
- Should kids ever have direct accounts, or should all child interaction remain parent-mediated?
|
||||
- Should Missinglettr campaigns be included in provider plans or charged as an add-on?
|
||||
- Should CampReg offer a public API to all paid providers or reserve API access for higher-tier accounts?
|
||||
- Should mobile begin as responsive web + PWA, or should staff workflows justify native app development earlier?
|
||||
|
||||
---
|
||||
|
||||
## UI Requirements Reference
|
||||
|
||||
Detailed UI requirements for the provider desktop SaaS, parent portal, parent mobile experience, staff mobile experience, provider mobile control panel, CampMatch marketplace flows, and cross-product marketplace-to-registration flows are documented in:
|
||||
|
||||
- `campreg-ui-requirements.md`
|
||||
|
||||
This UI requirements document should be treated as a companion product specification to the master PRD. It references Campium, CampMinder, CampSite, UltraCamp, ACTIVE Network, eCamp, Hi.Events, and Attendize as market and open-source design inputs.
|
||||
Reference in New Issue
Block a user