Different layouts, one structured collection goal
Data extraction · Quality · CRM workflows
University Course and Intake Data Collection
University information lived across sites with different layouts and behaviors. I built and maintained scripts to collect it, then prepared files for quality checks before CRM import.
UNIVERSITY DATA · EXTRACTION PIPELINE
From university pages to CRM-ready files.
Follow a representative course record through extraction, normalization, review, and import.
course_nameCourse title extracted—intake_datesDate range normalized—attendance_typeStudy mode mapped—durationDuration standardized—campusCampus name prepared—One script per university
University pages presented course and intake information in different structures, so the scripts followed each source’s own layout and navigation.
The scripts gathered course names, intakes, attendance details, duration, and other information used to keep the internal CRM current. The output went through a quality-control step before import.
Match each source page
The work involved browser navigation, page-specific selectors, pagination, dropdowns, dynamic pages, and data normalization. Different site behavior meant each script needed to match its own source.
My contribution
Script creation and maintenance
I created and maintained source-specific extraction scripts, then integrated them with shared normalization functions for intake dates, course level, campus, duration, and attendance type.
Technical context
TypeScript + Playwright
The scripts used TypeScript and Playwright with shared processing and storage components from the wider project.
Why the process mattered
Useful data needed a quality gate.
Preparing generated files for QC kept extraction separate from the final CRM update, so data could be checked before it reached operational records.