Built for semesters, not just for classes

Faculties, programmes, batches, semesters and phases as the enrolment structure, so a college is not describing itself in a model built for a primary school.

Book a demo

What this usually looks like today

A college evaluates school software and finds it assumes classes and sections. So a programme becomes a "class", a semester becomes a "term", and the registrar spends the first year explaining to everybody what the labels actually mean.

Then a student repeats one semester while progressing in another, or transfers between programmes carrying credit. The model has no way to express it, so the real record moves into a spreadsheet.

When the structure matches the institution, none of that translation happens.

What it handles

Grouped by the job it does rather than listed as one long set of features.

Faculties and departments

The organisational shape a higher education institution actually has, rather than a flat list of classes.

Programmes

Degree and diploma programmes with their own duration, structure and session fees.

Programme schemes

Cloneable between intakes, so a new cohort starts from last year rather than from a blank structure.

Batches and intakes

The cohort a student belongs to, which is how a college actually thinks about who is where.

Semesters

Enrolment, teaching and assessment organised by semester rather than by an academic year that does not describe the institution.

Phases

Sub-divisions within a programme with their own student lists, for institutions that need them.

Session fees

Fee structures attached to the programme and session rather than to a class, so billing follows enrolment.

Progression and transfer

Moving between semesters, repeating one, or transferring programme without losing the record.

Academic reporting

Enrolment and progression by faculty, programme and intake, current rather than compiled.

The cases most systems get wrong

The programme called a class. School software with no concept of a faculty forces a college to relabel everything. Every new member of staff then has to be taught the translation before they can use the system.

The student repeating one semester. Progressing in some subjects, repeating another. Systems built around a single year-group cannot express it, so the truth moves to a spreadsheet.

The transfer that lost the credit. A student moves programme and their completed semesters do not follow, because the record was tied to the programme rather than to the person.

The fee tied to a class. Session fees belong to the programme and intake. Billing built around class-level fees cannot charge two students in the same room different amounts for different programmes.

These are the cases worth testing in a demo. Bring the messiest one you have.

Who touches it, and what they see

The same records, presented differently depending on the job.

The registrar

Defines faculties, programmes and semesters, manages progression and keeps the structure current.

Teaching staff

See their own programmes and cohorts rather than the whole institution.

Students

See their programme, semester and progression in their own portal.

Leadership

Enrolment and progression by faculty and intake, which is what planning actually needs.

What it shares records with

The academic structure is what the rest of the institution attaches to. A student belongs to a programme and a semester rather than to a class, so fees, attendance and examinations all read that shape.

Timetabling works against programmes and cohorts. Session fees bill through the same fee structure. Results attach to the semester they belong to, so a transcript reflects progression rather than a flat list of years.

That is the difference between software a college can use and software a college has to translate.

Questions we get asked

Is this built for schools or for higher education?
Both, with a structure that matches each. A college works in faculties, programmes, batches and semesters rather than classes and sections, and those are real structures here rather than relabelled school concepts.
Can a student repeat one semester while progressing in another?
Yes. Progression is recorded per semester rather than as a single year-group step, which is the case most school-shaped systems cannot express and where the real record usually moves into a spreadsheet.
What happens when a student transfers programme?
Their completed semesters follow them, because the record belongs to the student rather than to the programme they started in.
Can fees differ by programme rather than by class?
Yes. Session fees attach to the programme and intake, so two students sitting in the same room on different programmes are billed correctly.
Do we rebuild the structure for each intake?
No. Programme schemes clone between intakes, so a new cohort starts from the last one and you adjust what changed.
Can we run both a school and a college?
Yes. Institutions running both alongside each other use the structure that fits each part rather than forcing one shape on the whole organisation.

Bring your programme structure

The repeat, the transfer, the programme that runs across three semesters. If the model does not fit, we would rather know now.

Book a demo