CCC Youth Discipleship Hub
One place to run the whole discipleship journey: sign-up, onboarding attendance, families, the six-month modules, town halls, the internship, the group project and certificates. This brief is for the person managing cccyouth.org, to understand the tool, see it demonstrated, and decide how to host it properly.
- 1Register interest
- 2Onboarding month, 6 classes
- 3Exam and selection
- 4Five families formed
- 5Six months of modules
- 6Internship, 4 weeks
- 7Group project
- 8Certificates
Town halls run through the whole programme, about once a month.
Where things stand
Who uses it
| Role | What they do in the hub |
|---|---|
| Student | Registers, checks in to classes and town halls with a code, sees their family, modules, recordings, attendance, internship and certificate. Can send feedback, anonymously if they choose. |
| Supervisor | Oversees everything across all families. Approves staff, creates classes and families, sets selection rules, turns the internship and project phases on, builds project groups, issues certificates, reads feedback. |
| Team Lead | Runs one family. Logs family classes and attendance, passes concerns to the Discipler, requests cover from another Lead, ticks internships, and submits project folders for the groups they handle. |
| Team Support | Supports the Team Lead in the family with the same day-to-day tools, and can also submit project folders for assigned groups. |
| Discipler | Teaches the family for the six months, usually not in the family’s WhatsApp group. Sees the roster, the module calendar, absences and the notes the Lead passes on, and writes the module expectations. |
| Onboarding Teacher | Temporary. Teaches the onboarding class only. Access is switched off when the supervisor ends onboarding. |
How each stage works
Onboarding (one general class, six sessions)
Classes run Mondays and Thursdays, 8:00 to 10:15 PM, on Google Meet or WhatsApp calls. The admin opens a start check-in and reads a four-digit code on the call, then does the same at the end. A student counts as fully present only with both check-ins, which replaces the shared tick-sheet that people could mark for each other. Recording links go on each class so students can catch up.
Selection
Supervisors enter exam scores and set the rule. The default is at least 5 of 6 classes fully attended and a 50% pass mark. Any individual can be overridden, then the list is confirmed.
Families
Five families: Light, Righteousness, Power, Love and Wisdom, with 5 to 7 students each. Each has a Team Lead, a Team Support and a Discipler. The Lead or Support logs each family class (date, module, topic, recording link, who attended, concerns for the Discipler).
When a Lead cannot attend
The Lead picks another Lead to stand in. The stand-in must accept before they get access to log that class, and the record shows who covered. Supervisors get a warning if a class in the next two days still has no accepted cover.
Modules and town halls
Ten modules (1A, 1B, then 2 to 9) with key scripture, focus, content, sound doctrine, practical questions and an assignment, plus a recording or document link. At least two classes a week. The monthly town hall is general, not by family, and compulsory. It uses the same two check-ins, and attendance is counted per family so Leads can follow up.
Internship and project
The internship runs 4 weeks and starts a week after the families finish their teachings. The supervisor switches the internship and then the project on, which alerts everyone in the hub. Project groups mix students from different families. Team Leads and Team Support are assigned across the groups, and only they submit each group’s final Google Drive folder.
Certificates
Eligibility combines family class attendance (default 75%), town hall attendance (default 75%), internship completed and the group’s project submitted. Supervisors can certify or withhold individuals, for example for an excused absence, and issue certificates in one click.
Proposed production setup
The prototype’s screens and rules carry over. What changes is where it runs and how people log in.
- Sign-in: email or Google, with each person approved into a role. Avoid phone-number codes, since they cost money per message.
- Access rules (the main improvement): a student sees only their own record, family and group. A Lead sees only their families. Feedback marked anonymous stays unreadable to everyone except supervisors.
- Hosting: the subdomain
discipleship.cccyouth.org, pointing to the hub with one DNS record. The existing site stays as it is. - Service options: a hosted database with built-in sign-in, such as Supabase, plus any simple static host. These are suggestions, not fixed choices.
- Low-data design: the pages are light and mobile-first, since most people will arrive from a WhatsApp link.
Records the database would hold
| Table | Holds | Who can change it |
|---|---|---|
| profiles | Name, WhatsApp number, role, approved or not | The person at sign-up; supervisors approve |
| sessions | Onboarding classes and town halls: title, date, meeting and recording links, check-in codes | Supervisors, Leads, Support, Onboarding Teachers |
| attendance | Person, session, start and end check-in times | The person, with a valid code |
| selection | Exam score, override, status | Supervisors, Leads, Support |
| families, family_members | The five families, their Lead, Support, Discipler and students | Supervisors |
| modules | Scripture, focus, content, doctrine, questions, assignment, resource link | Supervisors, Disciplers |
| family_sessions | Date, module, topic, recording, who attended, notes | Lead, Support, or an accepted cover |
| cover_requests | Family, date, requester, stand-in, status | Requesting Lead; the stand-in accepts |
| internship | Student, completed or not | Lead, Support |
| project_groups | Group, members, assigned Leads and Support | Supervisors |
| project_submissions | Group, Google Drive link, who submitted | Assigned Lead or Support |
| certificates | Override, issued | Supervisors |
| feedback | Message, anonymous flag, author | Anyone writes; supervisors read |
| settings | Internship and project dates, attendance thresholds, onboarding ended | Supervisors |
What we need from the website manager
- What is cccyouth.org built on (WordPress, Wix, Squarespace, custom), and who owns the hosting and domain?
- Can a subdomain such as discipleship.cccyouth.org be added, and can someone add a DNS record for it?
- Is there an existing email setup (for example Google Workspace) that sign-in emails and notices can use?
- Is a hosted service like Supabase acceptable, or is there a preferred or required provider?
- Who will own the accounts for the database and hosting, so the programme is not tied to one person?
- Privacy: the hub stores names and WhatsApp numbers. What is the age range of participants, and does the church need parental consent or a privacy notice for anyone under 18?
- Backups: who is responsible for keeping a copy of the records after each cohort?
How to demo the prototype
Open the prototype: claude.ai/artifact/UMDxA3jZiX3WSxUZxwhnCD. It opens only for people the owner has given access to, so ask the programme lead to share it with you first. The owner has a “Test as” switch to view every role from one account.
- Register and approve a few test people in the People tab.
- Onboarding: open a start check-in on Class 1, check in as a student with the code, then close it and repeat at the end.
- Selection: enter exam scores and look at the Programme tab’s results and overrides.
- Families: assign a Lead, Support and Discipler to one family and add students. Log a family class.
- Cover: as one Lead, request cover from another, then accept it as the other Lead.
- Calendar: open a town hall check-in and watch the per-family counts.
- Final phase: turn on the internship, see the alert, create a mixed project group, assign a Lead, submit a Drive link, then issue a certificate.
Notifications and certificates
- PDF certificates: built. Students download their own certificate, and supervisors can download any one or all issued certificates as a single PDF.
- WhatsApp and email messages: built as one-tap sending. The hub writes the message (class reminder, “we missed you”, internship started, project started, certificate ready, or custom), picks the people (everyone, a family, absentees from a session) and opens WhatsApp or the email app with it ready. A person presses send. Nothing is sent automatically.
- Fully automatic sending is not built. It needs the WhatsApp Business platform (approved message templates, a registered number and per-message costs) and a small server for email. It belongs in the production setup above.
- Still to come in production: proper sign-in and enforced role access.