Placements were running on Google Sheets and WhatsApp.
Once EVA started screening and admitting students at scale, Emversity had a new bottleneck. There was no structured system to actually run placements — just spreadsheets, shared inboxes, and broadcast messages, each one slightly out of sync with the others.
Nobody could answer "what's our placement rate right now" without opening four different sheets and hoping they agreed with each other.
Chaos in the back office
Student lists, company contacts, job openings, application statuses, drive schedules — all manually updated across disconnected sheets. Students got missed. No single source of truth.
No self-serve, no visibility
Students heard about companies through WhatsApp or email. They didn't know their own eligibility, couldn't track applications, and had nowhere to prep for the interview ahead.
The question wasn't "can we digitise the sheet." It was whether we could build a proper placement operating system — one interface that gives the admin team control and visibility, and an entirely different interface that gives the student agency over their own journey.
I owned both sides, end to end — but built them in sequence, not parallel.
I defined what each side needed, designed the full feature set for both, and worked with engineering to ship it. The management side came first — the admin team's chaos was the more acute, more upstream problem. The student side followed, once the data underneath it could be trusted.
A command centre with eight modules, built for one job: replace the sheet.
The dashboard is the command centre — a live snapshot of the active cycle, quick actions for the placement team's most frequent tasks, and the recent job profiles table at a glance.
The same eligibility data, rebuilt as something a student actually wants to open.
Where the admin side reads like an operator's console, the student side reads like a product a placed student would open on their own — gamified progress, streaks, a resume builder, and an application tracker that removes the anxiety of "did they even see my application."
A guided, step-gated resume builder; an AI mock interview reusing EVA's original screening engine; eligibility-aware company listings; and a funnel — Applied → Shortlisted → Screening Test → HR Interview → Offer → Decision — with real offer letters attached as documents. Even the decline flow is rate-limited to 3 per student, which quietly discourages offer-hopping past companies that showed up for the drive.
The choices that mattered more than any individual screen.
What actually changed for each side.
| Before EVA 2.0 | After EVA 2.0 |
|---|---|
| Student data in Google Sheets, manually updated | Live directory with CGPA, backlogs, offers tracked centrally |
| Companies emailed to a shared inbox, no CRM | Employer CRM with tier, contact, and outreach status |
| Students found out about drives via WhatsApp | Multi-channel announcements with delivery logs |
| No one knew the actual placement rate | Real-time funnel and department-wise breakdown |
| Students applied manually, status unknown | Self-serve applications, eligibility filtering, live status |
| No interview prep beyond what a senior batch shared | AI mock interviews calibrated to the target role |
Two things I'd fix if I rebuilt this cycle.
Build the eligibility engine before launching the cycle.
Showing "Eligible: 0%" was the right transparency call, but it meant the admin team had to configure eligibility criteria after students were already enrolled. I'd put an eligibility step inside the cycle-creation flow itself — you shouldn't be able to open a cycle without setting the criteria first.
Add employer outreach tracking from day one.
The Employer CRM showed "Not contacted" across all 8 companies — the gap was visible, but there was no workflow to close it. No reminders, no next-action field, no follow-up prompts. The data existed; the action layer didn't.