A proposal
Students, cohorts, trainers, mentors, alumni, placements and payments — every part of the agency you already run, connected underneath by a single record that captures everything as it happens.
The Application Co-Pilot — applications filled from each student’s answer bank, approved, and submitted on their behalf — is already built.
Where things stand
Every week the agency takes job seekers, groups them by the job they are aiming for, trains them, pairs them with mentors and placed alumni, markets their professional profile, places them into work — and collects a monthly payment once they are earning.
All of that is happening right now, across inboxes, spreadsheets, chat threads and people’s heads. Which means the raw material of a remarkably well-instrumented operation already exists. It has simply never had one place to live.
Nothing here needs to change how people work. It needs a memory underneath the work.
The core idea
Every training session, networking call, questionnaire, application, placement and payment is recorded once, in one place, as it happens — and everything the agency runs is built on top of that record. The briefs, the dashboards and the automation are only possible because nothing is ever written down twice, or nowhere.
The system proposes. A person decides.
Every capability in this proposal carries one of four levels of authority, agreed before anything is built. The mapping is deliberate — and it is the reason staff and students can trust what the system does.
The centrepiece
This is the whole business in eight stages. Open any stage to see what happens, what the system does on its own, where a person makes the call, and what the student sees throughout.
Scope
Five areas, each carrying the same authority markings from the idea above — so it is always visible where the machine runs alone and where a person makes the call.
The highlight · already built
Everything so far tracks your students’ applications. This is the engine that actually submits them — a working system that applies to jobs on each consenting student’s behalf, on the platforms where their roles are posted, and slots directly into the platform this site proposes.
Watch one application happen
A real form, filled from the student’s answer bank — then it waits for a person.
Answer bank · Meera Iyer · illustrative
Application form · Data Analyst · Helios FinTech · illustrative
Awaiting approval
Ready to submit. Nothing goes out without a person’s approval — and on submit, a screenshot and every field value are recorded exactly as sent.
The student’s answers to the questions application forms ask are collected once, then matched to every new form — exact matches first, then close matches, then meaning-based matching for questions worded differently. The student stops re-typing the same answers into every portal.
If a form asks something the answer bank does not cover, the system does not guess. It asks the student, once — and keeps that answer for the next form.
An approvals queue shows what is about to be sent. Approve one at a time or in batches, with the level of autonomy set per platform — more relaxed on one portal, stricter on another.
Before anything is submitted, the system captures a screenshot and the full set of field values. Nothing is sent that is not on record, exactly as it went out.
The Co-Pilot knows what has already been applied to and recovers cleanly if interrupted, so the same job is never applied to twice. Sensible daily limits and natural pacing keep applications going out steadily.
Every student’s queue, answer bank, approvals and status in one place, with an alert when a student’s session needs attention. Consent gates every pipeline in code — a student who has not consented has no pipeline.
The intelligence layer, in motion
An alumni networking call ends. Before anyone has opened a notebook, the transcript has already been read — and drafted into material the agency can use.
Transcript · alumni networking call
Tara (alumni): When I interviewed at Meridian Health, the first round was all SQL window functions.
Tara: They care less about syntax and more about whether you can explain your reasoning out loud.
Student: Should we be practising that in sessions?
Tara: Yes — talk through a query while you write it. It feels strange for a day, then it clicks.
Tara: Happy to do a mock round with anyone from this cohort next week.
Student: That would help a lot.
Training material
Session draft · “Explaining SQL aloud”
Alumni-call pointers
For the placement team
Questionnaire themes
Across the cohort
Access
Not three systems — one record, with the view shaped by who is looking. A trainer never browses the finances; an executive is never reading a student’s inbox; a student can always see exactly what the agency did on their accounts.
Sample view · illustrative data
Meera Iyer
Data Analysts · Evening cohort
Today
SQL practice set due
Session 18:00 · with Arjun Rao
Needs your approval
Application ready to submit
Data Analyst · Helios FinTech · filled from your answer bank — nothing goes out without you
Applications
| Helios FinTech | Awaiting you |
| Bluepeak Systems | Submitted |
| Meridian Health | Interview |
Access log
| Post draft created | Today |
| Mailbox triaged | Today |
| Application logged | Yesterday |
Sample view · illustrative data
Trainer & mentor view
Two cohorts assigned
Today’s sessions
| Data Analysts · Evening | 18:00 | 11 of 12 in |
| QA Engineers · Weekend | 10:00 | scheduled |
Your queue
| Enrolment · Sana Qureshi | review |
| Application · Meera Iyer → Helios FinTech | approve |
| Answer needed · Vikram Shah | ask student |
Applications across your students
| Submitted this week | 6 |
| Awaiting approval | 3 |
| Interview invites flagged | 2 |
Cohort health
| Data Analysts · Evening | steady |
| QA Engineers · Weekend | watch attendance |
From the transcripts
Window functions
Weakest theme across this cohort’s questionnaires — material drafted for the next session
Sample view · illustrative data
Owner view
Aggregate first · exceptions surfaced
Cohorts
| Data Analysts | 2 running | steady |
| QA Engineers | 1 running | watch |
| Frontend Developers | 1 forming | filling |
Placements this month
| In interviews | 5 students |
| Offers in hand | 2 students |
| Started work | 3 students |
Collections
| Agreements current | 14 |
| Instalments due this week | 4 |
| Needs a conversation | 1 |
Application pipeline
| Submitted this week | 9 |
| Awaiting approval | 4 |
| Interviews from applications | 3 |
Exception feed
| QA cohort attendance dipping | flagged early |
| Employer links concentrated with one manager | review |
The foundation
“Show every student who was borderline in week two, and whether they placed.” — a query, not a research project.
Two layers work together. Current state answers where is this student now. The record of events answers what happened, and when — every session attended, call held, application sent, score recorded, payment received, approval granted, and by whom.
That second layer is what makes the questions worth asking answerable: which cohorts place fastest, which sessions end in offers, where a struggling student first becomes visible. None of these can be answered from a snapshot of today — the history is the information.
And placed students are proof, network, mentors and a payment stream at once. Because the model keeps all four on the same person, whether alumni involvement makes the next cohort stronger is something the system measures — not something anyone has to assert.
Sequence
Six phases, each ending with something working and a decision point. The agency is never committed to the next step — every phase earns the one after it.
A structured questionnaire and one working session with the agency, plus short conversations with staff and with students. The stages a student passes through, the payment arrangement in complete detail, and where the staff hours actually go — measured, not recalled.
Delivers: the build order, decided on answers rather than guesses.
People, cohorts, sessions, attendance, progression, the record of events and the approval mechanism — with one real cohort running on it alongside the tools the agency uses today.
Delivers: intake, approval, session and daily brief, working end to end on a real cohort.
Fees, the post-placement payment agreement, instalments and arrears position, trainer and mentor payouts, and membership following payment standing — every consequential step passing a named person’s decision.
Delivers: the payment machinery checked against real historical cases before it touches anyone.
The dedicated mailbox, application tracking and interview-invite detection — and the Application Co-Pilot itself, which already exists as a working system. This phase connects it to the platform rather than building it from nothing: each student’s answer bank, the per-platform approval levels, the approvals queue, and the complete record of every submission.
Delivers: the students’ job search not just instrumented but actively run — applications going out approved, recorded and steadily paced.
Transcript capture, training-material drafting, alumni-call pointers, questionnaire themes, and the daily, weekly and monthly student briefs.
Delivers: conversations becoming material, on a schedule, with sign-off where it belongs.
The three views, cohort health signals, and outcome analysis across cohorts — built on data the system has been capturing since the first cohort, so the dashboards have something real to say.
Delivers: answers to the questions the agency actually asks, from its own history.
What happens next
The next step is one working session with you, shorter ones with your staff and a few students, and a discovery questionnaire covering the things that decide what gets built first.