Ruitong Tang

Work / Story 3 of 5

Sorting up to 3,000 applications in seconds, with a person deciding

A rule-based tool that reads every application and explains its verdict, so people spend their time on the decisions.

Role. Designer and builder of the pipeline; supervisor decidedPeriod. March to August 2026
  • Marketing operations
  • Process automation
  • Python
  • Applicant screening
  • Human review
  • Responsible AI use
  • Data protection by design
  • Knowledge transfer
To be added: 19 courtesy notice to Suci before launch
The screening process drawn as one picture. Leaves pour into a funnel and split three ways: a bundle tagged Rejected into a closed box, a smaller group tagged Flagged, and the rest onto a balance scale tagged Specificity. The flagged leaves fall into a Watch list basket and the weighed ones into a Shortlist basket. Both baskets lead down to a pair of open, lamp-lit hands tagged A person decides.
  1. Applications
  2. Round 1 eligibility
  3. Round 2 ranking
  4. Human review
  5. Shortlist

The sieve sorts, the scale weighs, a person decides.

The problem

Reading every application by hand took about two weeks per scholarship, and it was easy to miss things in long, similar-looking essays.

What I did

I wrote a two-round Python tool with AI-assisted development. Round one checks eligibility and writes a reason on every row. Round two scores how specific each essay is. Unclear cases go to a person, and the supervisor makes every final call. No AI decides anything about an applicant.

The result

Reused across 5 scholarships. Two weeks of reading became a run measured in seconds, with human review after. My manager said publicly that it saved the team hours every week.

B. Context

educations.com is a study abroad search platform within Keystone Education Group. It runs several scholarships a year, each with a public eligibility page and an application form that mixes fixed and open questions. During my digital marketing internship from March to August 2026 I owned the scholarship programme end to end: screening, finalist interviews and the published finalist and winner articles. Screening had to fit around the rest of the marketing work. This case covers how I rebuilt the screening step and reused it across five scholarship cycles in 2026.

C. The problem

Each cycle meant reading every application by hand, with pools of up to about 3,000 applicants per scholarship. Eligibility sat inside free text answers (a “Yes, I will apply” next to a plain “no”), country names arrived in many spellings, and a public page could list two different closing dates. The slowest part was the essays: long and fluent, but often without one concrete fact, so substance and filler looked alike. Manual reading took roughly two weeks per cycle.

D. My role and the team

I owned the design: which rules applied, what counted as ambiguous, how points were earned and where a person had to step in. I wrote the scripts with an AI assistant (AI-assisted development; no LLM in the decision path), tested them on synthetic edge cases, ran them on the real exports and reviewed the rejected and flagged rows myself. My supervisor reviewed each shortlist and made the final selection. Flagged cases were read by a person and recorded on a watch list; the final shortlist was drawn from applicants who passed eligibility cleanly. At offboarding I handed the last cycle to a colleague with a one-page runbook so the final run could happen on company devices after my access ended.

E. Key decisions

  1. Decision: Route ambiguous cases to a Manual Review label instead of auto-rejecting them (a two-tier filter). Why: Blank answers, unusual programme names and near-identical country spellings are where a script is most likely to be wrong, and a wrong rejection is the costlier error. Alternative I rejected: A single pass or fail rule, simpler to write, which would have silently cut eligible applicants.

  2. Decision: Score essays with a reward-only specificity score: half of each essay’s points for length, half for concrete evidence (numbers, named places, activity-specific terms). The score rates the submission, not the person. Why: Vague answers do not earn the evidence half, which keeps them below the top tier without any negative score; plain but concrete English is not penalised. Alternative I rejected: A penalty for suspected AI-written text, which no tool detects reliably and which would fall on non-native writers first.

  3. Decision: Remove attributes unrelated to the application (social media handles, following the brand) from scoring, and never infer attributes the form did not ask for. Why: Points should rest on what the applicant wrote for this application. When a form had no gender field, inferring it from names would have been automated profiling, so that check stayed with a person at a later verification step. Alternative I rejected: A small social media bonus, which I used in early cycles and then dropped.

  4. Decision: Match column headers by fuzzy keywords so one script pattern ran across five different forms. Why: Headers varied by curly apostrophes, line breaks and wording; one such variant silently zeroed a whole scoring dimension before it was caught. Alternative I rejected: Hard-coded column letters per form, quicker to write and fragile.

  5. Decision: Produce two outputs per cycle: an English file for the supervisor (all applicants, shortlist highlighted, a written reason per row) and a Chinese checklist for my own review of flagged rows. For handover I switched everything to English and made the scripts path-independent for macOS and Windows. Why: Each reader gets only what they need, in the language they read; a successor can run it from any folder without editing a path. Alternative I rejected: One bilingual file, which mixes audiences and clutters the supervisor’s view.

F. What I built or produced

  • Round 1 eligibility scripts for five scholarships, rules transcribed from each public scholarship page. Every row receives Qualified, Manual Review or Rejected plus a written reason. Closing dates and similar external facts are flagged for human confirmation, not decided by the script.
  • Round 2 ranking scripts: the reward-only specificity score, an exact Top N with a tie-break on the evidence score and a note when the boundary is tied, and, in the last cycle, a watch list of flagged applicants who scored at shortlist level but were not selected.
  • A finalize step: an English supervisor file with a full sheet and a shortlist sheet, plus a Chinese review checklist.
  • A first-person note, written against the company’s AI use policy, explaining step by step where a person reviews and decides. I rewrote it through five revisions to lead with “no LLM in the decision path”.
  • A four-part working ruleset written into the project’s AI instructions, so later cycles inherited the same limits.
  • A one-page handover runbook for a colleague: folder map, commands, output guide, troubleshooting table.

Public pages: Adult Learners Scholarship, Study a Bachelor’s in the USA Scholarship, Women’s Scholarship for International Students (URLs on file); Study a Master’s in Europe and Sustainable Energy and Environment.

G. Result

  • Reused across five cycles: Study a Master’s in Europe, Sustainable Energy and Environment (with IAESTE), Adult Learners, Study a Bachelor’s in the USA, Women’s Scholarship for International Students.
  • Each cycle ended with a ranked shortlist for the supervisor, every rejection and flag carrying a written reason, and no ambiguous field auto-rejected.
  • Screening time per cycle went from about two weeks of manual reading to a run measured in seconds, with human review of the output afterwards.
  • Manager feedback: my line manager, Suci Ariyanti (Brand and Campaigns Manager at educations.com), commented publicly on my LinkedIn post in August 2026 that the work saved the team hours every week (public LinkedIn comment, August 2026, link on file).

H. What I would do differently

  • Sample rejected rows systematically and record a false-reject rate per cycle. I sampled, but did not keep the numbers, so I cannot show how often Round 1 was wrong.
  • Start the policy note at the design stage rather than after two cycles. Writing it exposed a phrase that did not match the real process and had to be removed.
  • Keep a small test set of real header variants and edge rows, and run a short usability test of the runbook with the successor before handover.

I. Evidence assets

  • Two-round architecture diagram with human checkpoints: Anonymised diagram (redrawn from the design; no data, no internal text). Tier B.
  • Synthetic example of the status and reason columns, generated fresh and labelled illustrative: Tier B.
  • Scholarship pages on educations.com: Public link, Tier A.
  • Manager’s LinkedIn comment: Public link, Tier A.
  • CV project card: Public link, Tier A.
  • Handover runbook, policy note, working ruleset, scripts, console output or spreadsheet screenshots: Tier C, not shown; design logic described in words only.

J. Keywords

Marketing operations; Process automation; Python (pandas); Applicant screening; Scholarship programme management; Human-in-the-loop review; Responsible AI use; Data protection by design; Stakeholder documentation; Knowledge transfer; Bilingual communication (English, Chinese); Higher education marketing