The product, area by area
Seven areas, in the order an institution brings them into service: you set up the reference data, you timetable, you optimise, you steer. What follows is delivered and documented; what is still to come is gathered at the end, in the roadmap.
On this page
Space booking
Your teams look for a free room and book it in two clicks. Your institution’s rules apply on their own — and two occupations of the same room over the same interval are refused by the database, not merely discouraged by the interface.
Search, see, book
Availability search queries a single occupation view, where course sessions, bookings and room unavailabilities live together. What shows as free really is, and availability updates live for everyone looking at the same screen.
Your rules, as data
Eight families of rules combine per user profile: permitted room types, campus or building scope, time window, booking horizon, weekly hour quota, concurrent bookings, maximum duration, mandatory approval. A student books a study room a fortnight ahead; a lecturer does not have the same limits.
The refusal comes from the database, not from the screen
The anti-conflict rule is an exclusion constraint held in the database: two overlapping occupations are impossible, even if two people confirm in the same second. An interface can have a defect; an integrity constraint cannot.
Request, approval, reminder
Where a room requires approval, the request reaches the approvers and the answer comes back to whoever asked. Notifications are delivered in-app, by e-mail and by push, with a reminder before the date.
- Recurrences: a weekly booking is made once
- Every refusal names its cause: quota reached, horizon exceeded, frozen period
- Bookings, courses and unavailabilities: one single occupation truth
Room B-201
One day of room B-201: one slot booked, one refused by the database.
Reference data & administration
The foundation you set up once and everything else feeds on: the estate, the academic year, the teaching reference data, the people and their rights.
Room estate and floor plans
Campuses, buildings, floors, rooms, room types and equipment. Floor plans are interactive: you find a room on its floor, with its availability, from a plain plan image or from a structured vector file.
Academic year and time-slot grid
Years, periods — holidays and frozen periods included —, weeks, and the grid of teaching slots. That grid is what gives the rest its meaning: an occupancy rate is computed over open hours, not over twenty-four.
Teaching reference data
Programmes, cohorts and subgroups, subjects, teachers, and the courses to place with their recurrence, expected headcount and required equipment. Teachers declare their unavailabilities and their preferences; the scorer uses them.
Roles, permissions and audit trail
Permissions are fine-grained and carry a scope: a campus manager administers their own and no other. Each institution’s data is isolated by the database itself, row by row, and sensitive actions leave a trail your administrators can read.
Getting your data in
The CSV import assistant runs in four steps: upload with encoding and delimiter detection, column mapping suggested then remembered for next time, a dry run that validates row by row without writing anything, then the import itself. An error breaks nothing: you correct it and carry on.
- Multi-campus: one institution, several sites, a single reference base
- Every import error names its row, its field and its likely correction
- Audit trail: who did what, and when, on sensitive actions
Timetabling
The week is laid out, filterable by group, teacher, room or building. That is where courses are placed — and nothing is visible to students until you publish.
The weekly grid
Days as columns, your own slots as rows, sessions in their place. The same grid serves to read, to place and to compare; it is fully keyboard-navigable.
Placing a course
When a session is created, only the genuinely eligible slots are offered — the others carry the reason that rules them out. Drag and drop moves a session, and the check is run again on arrival.
Draft first, then publication
You work on a draft for as long as you need, then publish the scope of your choice. Every operation is journalled, and can be undone.
- Room assignment: automatic, forced, or in bulk
- Eligible slots detected before the placement, not after
- Operation history and undo
The weekly grid, coloured by score.
Constraints, scoring and explainability
The heart of the product. Sixteen constraints assess each candidate slot: eight invalidate it, eight cost it points. The resulting score runs from 0 to 100, and it never appears without its breakdown.
The catalogue, in full
Here it is, as delivered. The first eight are hard: violate one and the slot is invalid, and it is not scored. The next eight are soft: each produces a penalty that you weight. A weight of zero neutralises a constraint without removing it from the calculation; deactivating it takes it out.
Hard constraints — they invalidate the slot
| Room already occupied — "Room already occupied" is structural: it is the only one you cannot switch off. |
| Teacher unavailable |
| Group already in class |
| Teacher already in class |
| Insufficient capacity |
| Required equipment missing |
| Room unavailable |
| Unsuitable room type |
Soft constraints — they cost points
| Constraint | Default weight |
|---|---|
| Room oversized | 5 |
| Teacher preferences | 5 |
| Gaps in the group’s timetable | 6 |
| Travel time between buildings | 4 |
| Early or late slot | 3 |
| Gaps in the teacher’s timetable | 4 |
| Capacity too tight | 2 |
| Session spread | 3 |
Where the 78 comes from
The score is 100 minus the share of weighted penalties in the total your active constraints could reach. Concretely: if they allow at most 20 penalty points and the slot accumulates 6, it is worth 70. The formula is the same everywhere — in the grid, in the optimisation, in the summary.
The heatmap, and the room ranking
The week is coloured by score: the best placement shows at a glance, and the scale stays legible in greyscale and with colour vision deficiency. For a given slot, rooms are ranked by score, each with the dominant reason for its gap.
The breakdown, in plain words
Each constraint assessed shows its name, its weight, its penalty and the sentence that explains it: "Room oversized: 280 seats for 32 students." That is what lets you defend a decision in front of a lecturer, and what a spreadsheet will never do.
A slot’s score, constraint by constraint.
Optimisation
Select the courses to place, start the optimisation, watch it work. It proposes; you adjust; you apply — or you do not.
Several courses at once
The solver reasons about the interactions between courses: a placement that suits one group can penalise another, and that trade-off is what it looks for. Placing courses one after another does not give the same result.
Honest progress
While it computes, what you see is the average score of the best solution found at that moment — not a bar advancing on its own. You watch quality rise, and you decide when it is enough.
"Stop and propose"
One button interrupts the computation and hands you the best combination found so far. Another asks for a different one. Neither loses what has already been found.
Nothing is written without your say-so
The proposal arrives row by row, each with its score and its constraints. You change one, you keep the rest, you apply. A combination holding an invalid session can never be applied, and conflicts are checked again at write time.
- Satisfaction rate shown before applying
- Row-by-row adjustment; an adjusted row drops the suggestion’s score
- One computation at a time per institution, so the load stays predictable
The explanations you see come from our own scorer, never from the optimisation engine: the two assess the same thing, independently of each other.
Optimising
94%
An optimisation running, and its satisfaction rate.
Analytics & estate management
The real occupancy of your estate, from campus to room, over the period of your choice. This is the data behind the "optimise before you build" decision — produced by the tool, not by a consultancy.
The rate, defined before it is displayed
It divides occupied hours by open hours — that is, the slots of your own grid outside holidays. It counts published sessions and confirmed bookings, never drafts. That definition is written down, which lets you argue with the figure instead of believing it.
Where, and when
A day × slot matrix shows the quiet hours; the campus, building then room breakdown puts saturated sites next to empty ones. Under-used rooms are listed with their average headcount.
The timetable summary
A satisfaction rate weighted by session duration — a four-hour course weighs twice a two-hour one — and a "courses to review" list ordered by penalty, each row carrying its main reason and a direct link to the session.
- CSV export for your own analyses
- Comparison from one period to another
- Observed average headcount, not just theoretical capacity
Occupancy
Occupancy, from campus to room.
Consultation & integration
What the rest of the institution sees, and where the product connects to your information systems.
"My timetable"
Every student and every teacher sees their week — the published week, never a draft — with nothing to configure. The landing screen follows the role: a planning officer does not arrive where a student does.
In and out
CSV imports cover the room estate, the teaching reference data and people, with a dry run before anything is written; exports come back in the same format. The REST API is described in OpenAPI.
- In-app, e-mail and push notifications
- Real-time updates of availability and of the timetable
- Account management and connected devices
Roadmap
What follows is not delivered. It is written in the future tense and kept apart, so that no line of this page can suggest otherwise.
- Entra ID and Google single sign-on, then academic federation
- An installable mobile application
- Synchronisation with your calendars
- Automatic data migration from your current tools
- An examinations mode and at-the-door displays
For your IT department
The questions an IT department asks, and what the architecture answers.
Multi-institution isolation
Each institution is isolated by the database itself, row by row — not by a condition written in application code. A badly written query cannot cross the boundary.
A documented REST API
The API is described in OpenAPI: an integration can be read and tested without asking us for a document.
Real time
Availability and timetable changes propagate live to open screens, over WebSocket, on channels partitioned by institution.
Deployment and sovereignty
Everything is containerised and hosted at Scaleway, with storage in the European Union. Containerisation keeps the option of a deployment on your own infrastructure open.
Request a demonstration
Thirty minutes, on a complete fictional institution: a heatmap, an explained score, a multi-course placement.
Or book a slot straight away
If you would rather fix the date now, our calendar is open.
See the available slots (new tab)