Universities

EzUnihire Team · · 6 min read

How to run a campus placement drive without spreadsheets

A practical walkthrough for placement cells that want one verified record from registration to offer, instead of five versions of the same Excel file.

Students and recruiters at a campus placement drive

The spreadsheet problem, honestly described

Most placement cells in India run a drive the same way. A company sends a job description and an eligibility line such as “B.Tech CSE, IT and ECE, 7.0 CGPA and above, no active backlogs, 60% in 10th and 12th.” Someone in the cell filters the master sheet, exports a list, emails it to department coordinators, collects corrections over WhatsApp, and sends the final file to the recruiter. Then the recruiter sends back a shortlist in a different format, and the whole cycle repeats for the aptitude round, the technical interview, and the HR round.

None of this is anyone’s fault. Excel is flexible and free. The trouble is that by the third drive of the season there are several copies of the truth. A student fixed a CGPA error in one sheet but not the others. A backlog cleared in the June supplementary exams never made it to the master file. A student who already accepted a dream offer still shows up on a list for a mass recruiter, which quietly breaks your one-student-one-offer policy.

The real cost is not the hours spent filtering. It is the drive where a recruiter finds a mismatch between your list and a student’s marksheet, and starts doubting every other row.

Here is how to run the same drive on one governed record instead.

1. Fix the student record before the season starts

Do the verification work once, in June and July, not per drive. Import the full final-year roster with the fields recruiters actually filter on:

  • University roll number, department, course, and graduation year
  • 10th and 12th percentages (or diploma marks for lateral entry students)
  • Current CGPA and the scale it is on
  • Active backlogs and history of backlogs, kept separately
  • Gap years, with a reason field

Then decide which of these fields a student may edit. Contact details and skills can be self-service. Academic fields should not be: a change to CGPA or backlogs should go into a review queue, and the previously verified value should stay in force until someone in the cell approves the new one. In EzUnihire this is how the verification queue works, but the principle holds whatever tool you use.

2. Write eligibility as rules, not as a filtered export

Once the record is clean, each drive’s criteria become a rule set attached to the job: departments, courses, minimum CGPA, maximum active backlogs, percentage cutoffs, and your own policies such as “students already placed in the dream category are not eligible for this drive.” When a student’s record changes, eligibility updates automatically. Nobody re-runs a filter at midnight before the pre-placement talk.

This also makes your policies visible. If your institute allows a placed student one more attempt at a higher-package company, write that as a rule once. It stops being a judgement call made differently by each coordinator.

3. Let students see what they are eligible for

A surprising amount of placement cell time goes into answering “Am I eligible for this company?” If students can see every drive they qualify for, with the reason when they do not, those messages mostly stop. It also removes the suspicion that the cell is picking favourites, because the rule is the same for everyone and is shown to everyone.

4. Run every round on one pipeline

After registrations close, move the shortlist through stages on a shared board: Registered, Aptitude, Technical, HR, Offer. Every move should record who made it and when. When the recruiter shortlists after the aptitude test, they do it on the same record, not in a reply-all email with an attachment named final_shortlist_v3.xlsx.

Two practical tips from placement officers we work with:

  1. Schedule interviews from the pipeline itself. Slots, panel links, and reschedules live next to the candidate, so the student and the recruiter see the same time.
  2. Close the loop on the day. Mark offers and rejections before the recruiters leave campus. Offers entered a week later are the ones that go missing from your season report.

5. Report from the record, not from a new sheet

At the end of the season you still need numbers for the governing council, for NIRF graduation outcomes, and for your accreditation documentation: students placed by department, median package, number of recruiters, offers per student. If every drive ran on the same record, this is a filter and an export, not a two-week reconciliation exercise. Better still, the numbers are live during the season, so you can see in November that one department is lagging and invite recruiters who hire from it.

Where to start this season

You do not have to switch everything at once. A sensible order is:

  1. Clean and lock the academic fields for the final-year batch.
  2. Move the next three drives onto rule-based eligibility.
  3. Run their rounds on a single pipeline and compare the effort with a spreadsheet drive.

If you want to see what this looks like on EzUnihire, the features page walks through the verification queue, the rules engine, and live placement dashboards, or you can book a demo with our team and bring your own eligibility criteria to test against.