Index of everything the software does

It names which database is yours. It is not a trial limit and not a licence check you have to chase.

The four steps of the summer rollover: carrying rooms, lecturers and programmes into next year's university scheduling, and what is deliberately left behind.

Live, next year and a sandbox, each with its own menu slot, so nobody edits the wrong one.

Forty-five minutes against your own scheduling problem rather than a scripted tour.

From the installer to a working schedule: what to run, in what order, and what the server needs.

Who does what, in which weeks, between signing and a published schedule.

The keys that drive university scheduling without the mouse: the four view keys, the Alt jumps, and F12 to edit whatever is selected.

One key writes a password for every lecturer or group that has none, into a CSV that opens in Excel. Existing ones are left alone.

What the desktop application does when it cannot check in, and why it keeps working.

A real schedule in a browser, and the same one in the installer. Nothing to request first.

How long each stage of a first scheduling cycle really takes, from data to publication.

The full desktop application with a sample timetable. No key, no database and no form before you start.

Every import format documented in full, published free, so you can check the column layouts before committing.

CSV, Excel, a database view, the API or manual entry — and you can mix them in one installation.

Ready-made shapes for the usual cases, and a mapping step for a file that is yours alone.

Lecturers enter their own free hours in a browser; scheduling then runs against what they actually said.

A guided interface for institutions starting fresh, or for the parts an import never covers.

The order to do it in, so a first automated cycle does not depend on everything being ready at once.

What has to exist before course scheduling can run, and what can wait until the second year.

Two routes: student-level checking on the groups you already have, or building groups from an enrolment list.

One operation once the inputs are right, and what “right” means before you press it.

Place the hard sessions by hand, generate the rest around them. Neither mode locks the other out.

Merging cohorts into one class, with the room size worked out from the real total rather than by hand.

Room, lecturer, group, travel, contact hours, gaps — the rules course scheduling has to respect.

The distinction most tenders get wrong, with the practical test for which one a rule really is.

Scheduling that runs against the free time lecturers entered themselves, not against a guess.

What each setting trades away, so a second run improves something specific rather than everything vaguely.

What the engine does with your constraints, in plain terms, and why they matter more than the algorithm.

How to find which rule is the one making it unsolvable, rather than relaxing all of them.

One person, one minute, once — and then several planners work on the same schedule at the same time.

Compare variants on measured numbers instead of arguing about which one feels better.

Who holds what, how it is claimed, and why nothing pops up to ask you.

Where a group stops being a good approximation of a person, and what to do about it.

The whole cycle from structure to publication, and where the time actually goes.

What to do when a colleague still holds something and has gone home.

Why it is a hard constraint rather than a footnote, and how it is expressed.

Optional: a request queue for the rooms that need one, direct booking for the rooms that do not.

Every date a repeating booking would fall on is checked against every room, lecturer and group first.

Per room and per role, so self-service does not become a free-for-all.

Seating, invigilators, minimum gaps and student-level clash rules across the whole cohort.

The constraints an examination schedule cannot break, and why they are stricter than teaching.

Holding the big hall for a conference in an academic year the database does not have yet, where everybody can see it.

Rooms yes, lecturers and groups no — because a room is the one thing a year transition leaves unchanged.

Staff reserve labs, meeting rooms and consultation slots themselves, inside the rights you set.

What to count, over what period, before deciding a building is full.

Two different numbers that get quoted as one, and the decisions each of them supports.

One booking, every week of a term, with the whole range checked before anything is reserved.

Why a seating plan belongs to the schedule rather than to a spreadsheet made the week before.

One address doing two jobs: a schedule anyone can read, and a booking system staff sign in to.

A rotating code shown in the room, reconciled against the schedule automatically. No hardware, no register call.

When the code is live, how long it lasts, and what happens to somebody who arrives late.

Rooms, lecturers and sessions changed by the office, with the effect visible immediately and no IT ticket.

In rising order of embarrassment, and which of them only student-level checking will catch.

Every clash surfaced the instant it is created, across room, lecturer, group and student.

Server-side tasks that email schedules, push changes, serve calendar feeds and refresh signage unattended.

Finding who is genuinely free today, assigning them, and telling everybody in time.

Ask whether an exchange is possible before making it, instead of making it and reading the complaints.

The selection jumps to the first item that contains what you typed, accents ignored — in every list in the product.

The measures worth reporting when somebody says the load is unfair, and what they usually show.

Rooms, lecturers, programmes and courses kept; the schedule, the bookings and the student list dropped; the year advanced by one.

One iCalendar feed each, written nightly for the whole year, so an address issued once keeps working all the way through it.

They look identical the day they are made. One keeps itself right and the other is a photograph of September.

A live feed a student's own calendar app follows, so a room change reaches them without an app.

Only the people a change actually affects are told, which is what keeps anyone reading them.

Screens driven from the live schedule rather than from a playlist somebody has to remember to update.

Personalised timetables and change notices sent from the application, to a programme, a year or one person.

On the room, on the subject, or typed onto a single lesson — and what each of those choices means.

Which address wins when a lesson carries more than one, set per programme because faculties disagree.

Printed and exported schedules with the layout and content you choose, not a fixed template.

Why a calendar feed cannot originate a message and a push notification can. Publishing is not notifying.

Entrance, corridor, lecture room and library each want a different view of the same schedule.

A link, an embedded view or your own page against the API — three ways, one live source.

Two clicks from an empty slot on the week you are already looking at.

Function keys that switch straight to the tutor, room, group, course or student view for whatever is selected.

Signing in adds booking and reports to the page a lecturer was already reading.

Native iOS and Android, personalised, free for everyone at the institution, with push notifications.

The administrator defines what is on offer, students choose in a browser, and the office gets every choice back as a spreadsheet.

Students use the institution's own account, so there is no separate password to issue, reset or remove.

What a student can do with their own schedule once they have found it.

Five ways to fit a week onto a phone, and when each of them is the right one.

How a student narrows the institution's schedule down to their own, with no account at all.

Why a report generated from the live schedule answers a question a monthly export cannot.

The figures that show a second run was actually better, rather than differently arranged.

Room usage, staff load, unallocated sessions — the four or five that get requested every year.

Utilisation, workload, unallocated sessions and custom reports, in the browser or exported.

Every endpoint, parameter and error, published free so a developer can judge feasibility before a meeting.

Schedules, rooms, lecturers, groups and courses, in one request per view rather than a chain of them.

A public endpoint that answers without credentials, so the first evaluation costs nobody a phone call.

The two operations that are not read-only, and why the rest deliberately are.

Both are supported and both are ordinary; the choice is about your policy, not our architecture.

Separate schedules that stay separate, and see each other where they have to.

When two faculties run different hour patterns and a shared lecturer teaches in both.

What a failed API call tells you, and why that matters more than the status code.

A dictionary that maps one faculty's spelling of a room or a course onto another's.

Files, an API, or scheduled synchronisation — and the questions that decide which one you want.

Shibboleth and comparable federated identity, so nobody keeps a second password for the schedule.

The decision to make before any integration work: one owner per kind of data, written down.

The signed certificate, downloadable, from a UK-based certification body.

What you get at any price point, because there is no feature tier to be upsold out of.

Priced per independent schedule rather than per student, per room or per module.

Exactly what the app sends and what it keeps locally. No advertising and no tracking.

What is held, on what legal basis, and who the controller is when your institution runs it.

What we need to know to price it, and what comes back.

A checklist you can lift into a tender document, written so it does not describe only us.

The one that separates a scheduling engine from a system your office can actually run.

The obligations behind the badge, as opposed to the badge.

Data residency, hosting location and the parts of that decision that stay yours.

The questions institutions ask first, about rollout, scale, platforms and support.

Screenshots of the administration console and of the web and mobile output.

Every manual we publish, free and ungated, including the 278-page desktop reference.

What actually changes between a university, a college and a multi-campus institution.

The comparison stated on mechanism rather than on adjectives.