Wise Timetable

Booking

What a recurring room booking really is

You describe it the way a person says it — every second Tuesday until May. What gets stored is something else, and almost every surprise afterwards comes from the gap between the two.

First: a booking is not a lesson

They sit side by side on the same grid and they come from opposite directions. A lesson is an output: it exists because a timetable was built, and it moves when the timetable is rebuilt. A booking is an input: somebody decided that this room is held at this hour, and nothing regenerates it.

That difference is why a room-booking system that is merely a calendar bolted to the side of a timetable causes trouble within a term. The two have to live in the same place, because they compete for the same rooms — but they are not the same kind of object and a system that pretends otherwise will eventually regenerate somebody's exam away.

One booking can become several, and that is correct

A repeating booking is stored as a rectangle: a stretch of teaching weeks, by a set of weekdays, at one time. Monday to Friday for three weeks is a single rectangle and a single row. Monday and Wednesday is two rectangles, because one rectangle covering Monday through Wednesday would also book Tuesday — which nobody asked for and which somebody else would have wanted.

So one click can produce three bookings, and each of them is then a booking in its own right: separately visible, separately editable, separately cancellable. That is worth knowing before you cancel the booking and find that two thirds of it is still there.

The honest version of this, which vendors rarely volunteer: there is usually no such thing as a series. Ask what happens when somebody deletes one occurrence of a twelve-week booking, and then ask what happens when they want to move all twelve.

The patterns, and the trap in each

PatternWhat it meansThe trap
Every weekThe same weekdays in every teaching week of the range.Reading week. A pattern that runs across one will book straight through it unless non-teaching weeks are excluded.
Every second weekAlternate teaching weeks, counted from the first week of the range.Counted from the RANGE, not from week 1 of the year. Two fortnightly bookings that start a week apart never collide and never coincide.
Same weekday each monthThe third Tuesday, say.The ordinal is usually taken from the start date and never asked for. A booking starting on the last Tuesday of the month means LAST — not fifth, and not third.
Same date each monthThe 15th, the 31st.A month too short for the date should be SKIPPED, not folded back. If your system books the 30th of April on behalf of a 31st, it is making a decision it was not asked to make.

Times land on the institution's own lines

Teaching hours are not a free grid. An institution runs periods — 08:00 to 09:30, or six fifty-minute lines with a ten-minute gap — and a booking has to start where one starts and end where one ends, or the grid stops meaning anything.

A system that silently snaps 08:15 to 08:00 is storing something the person did not enter. The better behaviour is to refuse it and say which times are available, which is the same principle as everywhere else here: do not quietly correct somebody, tell them what is in the way.

One related detail that catches every new integration: consecutive is not overlapping. A session ending at 09:00 and one starting at 09:00 do not clash. If your system reports that they do, half your rooms are unbookable for no reason.

A clash check has to see what the public cannot

This is the part that is most often quietly wrong.

When a booking form asks is this room free, it must count everything that actually holds the room: lessons, other people's bookings, and bookings that are still waiting for approval. A room held by a request nobody has approved yet is not free; it is pending, and offering it to somebody else creates the argument the approval step existed to prevent.

The same goes for rooms an institution does not publish. A departmental meeting room kept off the public list is still occupied when it is occupied.

So availability is a fact about the room, not a view of the timetable — which is exactly why it should require the person asking to be signed in. A check that is open to anybody either lies about pending bookings or leaks their titles.

Who may book what, and what a clash should cost

  • Room permissions belong to the room, not to the screen. Some institutions let anybody book a seminar room and nobody book the lecture theatre without asking. That rule has to be enforced where the booking is written, or it is a suggestion — book an allowed room, then edit it to a forbidden one, and the rule has been walked around.
  • A clash should be refused with its reasons attached, not with a flat no: which dates, and whether it was the room, the lecturer or the group that was busy. Two of those three are often fixable by moving one week.
  • And a planner who means it should be able to book over it. Deliberate double-booking is normal — a room split between two groups, a lecture that overlaps a drop-in session on purpose. What matters is that the system records that the clash was a decision, so whoever sees it in March knows it was not an accident.
  • Approval is a state, not a separate queue. A booking awaiting approval should already be visible to the people who need to plan around it.

Where this lives in Wise Timetable

Bookings sit in the same document as the timetable, so availability is computed against everything at once rather than against a second calendar that has to be reconciled. The room booking system covers what a timetabling office sees; the web booking module is the self-service side, for institutions that want staff to book their own rooms without going through the office.

For anybody building their own booking screen, the whole surface is documented in the public REST API manual — including the availability check, which returns the clashing dates and the nearest free alternatives rather than a yes or a no.

Want to see this working?

Book a 45-minute online presentation and we will walk through it against your institution's own scheduling problem.