Frequently asked questions
Questions universities ask us
Collected from twenty-three years of implementations and procurement processes. If yours is not here, ask us directly — we will answer it properly and add it to this page.
Implementation and rollout
What is the usual implementation time for Wise Timetable?
It varies with what you need. Our cloud services can be set up within a single day, but the full process involves several collaborative steps and the timeline is usually driven by your side rather than ours. Integration with external systems — especially ones we have not encountered before — extends it, though our integration interface covers most common setups.
Training typically takes three to five days of hands-on work with your team. After go-live, support continues for as long as you need it.
What level of engagement is required from our university?
Implementation is genuinely collaborative. We can deploy cloud services in a day, but your involvement is essential for configuration, data preparation and integration with your existing systems. Where third-party systems are in play, expect some coordination effort from whoever owns them.
Budget three to five days for training. Beyond that, the ongoing burden is low — see the next answer.
Is Wise Timetable difficult to manage after implementation?
No. We describe it as an IT-less system. Once implemented, core operations are handled by the server and by our team, which keeps your IT department out of day-to-day scheduling entirely. Administration staff run the system themselves, with our support available whenever they need it.
This matters more than it sounds. A scheduling system that requires standing IT involvement quietly consumes staff budget every year it runs.
Can we migrate from our current timetabling system?
Usually, yes. If your current system can export to Excel, CSV or XML — and almost all can — we can map that into Wise Timetable. Where an API exists, we can often read directly.
Send us a sample export before you commit to anything and we will tell you honestly what transfers cleanly, what needs mapping work, and what will have to be re-entered.
Data, scale and scheduling
We want to use our existing data. How do we avoid extensive manual input?
Wise Timetable supports a range of automated import methods. Excel and CSV cover most cases; XML is supported; and there are documented REST API libraries for direct integration with external systems.
Automated import and manual adjustment can be combined at any point, so you keep full control over the final dataset. Many ready-made templates exist, and where your setup is unusual, imports can be tailored precisely to your file format.
What if we want to keep some hours fixed and generate the rest automatically?
You have full control over manual scheduling. Set specific sessions and lock them in place so automatic generation cannot move them. If you have built a substantial part of the timetable by hand, you can lock all of it in a single action.
Locked sessions are marked with a key icon so they are obvious at a glance, and the system generates the remainder around them. This hybrid approach is how most of our institutions actually work.
What if the timetable cannot be completed because of constraints?
In rare cases, constraints are strict enough that no complete solution exists even in theory. When that happens, Wise Timetable displays all unallocated sessions clearly rather than failing silently. You then have two options: place the remaining sessions manually into the free slots the system shows you, overriding a constraint where you judge that acceptable; or relax a constraint and re-run generation.
Because even large and complex timetables regenerate in under a minute, iterating is cheap. You will not be starting from scratch.
What are the size limits of the system?
There are virtually no limits on programmes, sub-programmes, modules, classrooms or lecturers. Technically the only constraint is available memory, and that supports extremely high volumes.
Wise Timetable was originally designed for enterprise-level universities, which is why it scales; it stayed easy enough to use that smaller organisations run it with a single administrator.
Can lecturers enter their own availability?
Yes, and this is the single biggest time saving most institutions report. You open the web booking system to your teaching staff; each lecturer signs in through a browser and books the hours they are free to teach. No installation, no training, no form to email back.
The administrator watches a live completion dashboard and sends automated reminders to whoever has not responded. Then generation runs directly against that availability from the admin console. There are no phone calls to make, no spreadsheet to reconcile, and no transcription step where errors get introduced — which removes both the delay and the most common source of scheduling error.
Is it possible to make the internal timetable available for lecturers to verify?
Yes. Wise Timetable supports an unlimited number of internal published timetables. Most institutions maintain three: one for the current academic year, one for the upcoming year during the transition period, and one for internal verification and review.
You can also create and save unlimited timetable simulations with different parameters or constraints, stored locally through the administration console, so you can test scenarios without touching the live schedule.
Building the timetable in a browser
Do we have to install anything?
No. The timetable office can do its whole job in a browser: reading and building the week, placing lessons, moving and swapping them, availability, bookings and approvals, courses and their teaching plans, programmes, groups, lecturers, rooms and students, the hour ladder, the academic year, reports, the generator and the bulk operations.
We say this plainly because it is increasingly a procurement requirement rather than a preference. If your IT policy or your tender forbids installed software, that is not an obstacle here — see the web administration and the desktop planner.
There is also a desktop program. Which one do we need?
The desktop planner came first and many long-standing customers still prefer it: a timetabling officer who knows its keyboard is fast in it, and we are not in the business of taking a working tool away from somebody who is good with it. New institutions generally start in the browser and never install anything.
A school is set to be administered from one side or the other, so there is never a question about which of the two owns the data. Both can be in use at once, and the guide sets out exactly what that means.
Can several people build the timetable at the same time?
In the browser, yes, with nothing to configure: there is no document to open, no lock to wait for and nothing to publish. What one person saves the others see.
If you also use the desktop planner, multi-user mode covers the same ground for it — see the multi-user planning manual.
Who is allowed into the administration, and who decides?
You do, from inside the application. A lecturer record carries an Administrator tick; the people who have it are the people who can sign in and change the timetable. Your own office grants and removes it, and the screen refuses to remove the last one, because nothing inside the application could put that one back.
Signing in also needs a password, which the same screen grants. A person who has the tick and no password cannot get in, and the screen says so rather than leaving you to find out from them.
Is there an undo?
One step, yours, where your faculty switches it on: after a change the bar above the screen names what you just did and offers to put it back. It is not a history of the screen and it does not reach into anybody else's work.
Beyond that step, the operations that change many lessons at once each count what they are about to change and ask with the number before they do it. That question is the safety, and it is worth reading.
Automatic generation
How long does generation take?
Under a minute for most institutions, including large and complex ones. That number matters less for the waiting than for what it makes possible: when a run is cheap, you can try a constraint, look at the result, and change your mind, which is how a good timetable is actually produced.
How automatic timetable generation works explains what the engine is doing in that minute.
Can we keep part of the timetable and generate the rest?
Yes, and it is how most of our institutions work. Lock the sessions that must not move — individually, or all of your hand-built work in one action — and generation fills in around them. Locked sessions carry a key icon so they are obvious.
Unticking a programme protects its lessons as well: they are held aside and put back unchanged rather than deleted.
Can we try a run without committing to it?
Yes. The result is reported and nothing is written unless you ask for it to be saved over the current timetable. That is the honest shape of “try it and see”, and it is a tick box rather than a separate mode.
You can also keep unlimited saved simulations with different parameters, so two approaches can be compared on their utilisation and workload figures rather than on impression.
What is the difference between a hard and a soft constraint?
A hard constraint must hold in any valid timetable — a lecturer cannot be in two rooms at once. A soft one is a preference you would like satisfied. Declaring every preference inviolable is the single commonest reason a timetable turns out to have no solution at all.
Hard vs soft constraints works through real examples and how to classify your own rules.
Can we generate a personal timetable for each student?
Yes, where students choose their own combinations of modules rather than moving as fixed cohorts. The generator can work from actual enrolments so that no student is given two classes at once.
There are two guides, depending on whether you already have groups: generating a timetable per student and per student with existing groups.
Does it handle exams as well as teaching?
Yes, including the parts that make exam scheduling its own problem: room capacity against cohort size, spacing between a student's papers, and invigilator allocation.
Students, lecturers and publication
What do students actually get, and do they need an account?
A web page showing their week, with no sign-in for the timetable itself. They filter to their own programme, year, branch or group and read it on a phone as easily as on a laptop.
There are free apps for Android and iOS as well, and a student can subscribe to their timetable so it appears in the calendar they already use — see calendar subscriptions.
Can lecturers book rooms themselves?
Yes. A lecturer signs in on the public pages and books a room, and nothing else on those pages changes for them. Where your faculty wants bookings checked first, the timetable office approves them from its own screen, and the person who made the booking is told what was decided.
Recurring room bookings covers the bookings that repeat.
Can we put the timetable on screens in corridors?
Yes. A display is configured once and shown on any screen with a browser; there is no separate player to install and no per-screen licence.
Timetables on digital signage shows what the displays look like and how a school sets one up.
Can the timetable appear inside our VLE or our own website?
Yes, both. Ready-made pages are served by the application and can be linked or embedded in an iframe so they read as part of your own site, logo included.
For the VLE specifically, timetables in your VLE sets out the options, and the REST API is there where you would rather render it yourself.
Can lecturers be emailed their week automatically?
Yes. Once a week each lecturer receives their own timetable, attached as a PDF, in their own language, and the school writes the letter itself rather than asking us to change it.
Emailing weekly timetables to lecturers is the overview, and there is a manual for the screen.
Workload, pay and staff records
Can we work out what to pay each lecturer from the timetable?
Yes. Each lecturer carries their own hourly rates, and the rates can differ by the kind of session — a lecture, a laboratory and a seminar need not be paid the same — or by the study programme. Everyone can be on a different contract, because the rate table holds a line per person.
The report then reads what each lecturer actually taught over a period you choose and works out the money, per programme and per kind of session, as a spreadsheet your accounts department can work from. Paying lecturers from the timetable sets out how it is configured and, just as usefully, what it does not do.
Is that a payroll system?
No, and we would rather say so here than in month two. It produces the figures — hours and money, by person, by programme and by kind of session — in a form your payroll or accounts system can take. There is no bank file, no tax calculation, no payslip and no self-service claim form for staff to submit.
A flat one-row-per-session export exists for exactly that handover, where a payroll system would rather read the detail than the summary.
Can a lecturer get a signed record of the work they delivered?
Yes. The web administration prints an evidence-of-academic-work sheet for one lecturer at a time, for a month or any period, split into teaching, consultations, colloquia, exams and other activities, with signature lines for the lecturer and for the office and a heading the faculty writes once and the system then remembers.
Slovenian faculties ask for this one by name — Evalvacija — and it is named that way in Slovenian because that is the word they use in their own reporting.
How do you handle gaps and breaks in a lecturer's day?
Three ways, and they are separate on purpose. Before generation, a break can be made mandatory for a group after so many teaching hours and, separately, for a lecturer; a block of teaching can equally be set to run with no break inside it. After generation, Level pauses redistributes what is left.
And you can measure it. The pauses report counts group gaps, lecturer gaps, and how many of the lecturer ones are long rather than short, so “we fixed the gaps” becomes numbers you can compare between two runs. Optimising for lecturers and optimising for groups are separate commands, because they pull against each other.
Can we see how teaching is spread across staff before we commit to it?
Yes — hours by lecturer, by department and by programme, with the sessions nobody has been assigned to shown rather than quietly omitted. That last list is usually the useful one.
Balancing lecturer workload is the working guide, and reports for university management covers what a dean actually asks for.
Integration with your other systems
Which student information systems do you work with?
We have published notes on Banner, SITS, PeopleSoft, Colleague, Workday Student, Unit-e and Callista, and the general approach in integrating a timetable with a SIS applies to the rest.
Where a system is not on that list it is usually still straightforward: if it exports Excel, CSV or XML, we can map it, and where it has an API we can often read directly.
Is there an API?
Yes, a documented REST API, and the manual is published here rather than being sent out under an agreement. A procurement team should be able to hand it to whoever maintains their systems and get an answer before signing anything.
It is the same interface our own mobile apps and third-party partners use, so it is exercised daily rather than being a side door nobody tests.
Can we move from CELCAT, Scientia, TimeEdit or Untis?
We keep our timetable in Excel today. Is that a problem?
No, it is the commonest starting point we see. The structure in a working spreadsheet is usually sound; what it lacks is clash detection and a way to publish.
From Excel to automated timetabling describes what transfers and what is worth rethinking on the way.
Platforms, security and support
What devices are supported?
The system runs in any modern browser on any platform — Windows, macOS, Linux and mobile. Dedicated apps are available for Android and iOS so students and staff can reach schedules and booking tools on the move.
The administration console is optimised for Windows PCs, any version, and gives full control over scheduling, reporting and configuration. Backend software runs on Windows Server, whether hosted by us or on your own infrastructure.
We have strict security rules. How does your company handle data?
Wise Technologies is certified to ISO/IEC 27001:2022, the international standard for Information Security Management Systems. That means a structured, risk-based approach covering people, processes and technology — not just a firewall.
For cloud-hosted data specifically: sensitive information is encrypted in storage and in transit, backups run regularly, and access controls limit exposure. Where your data governance requires it, we install fully on-premises so data never leaves your own network.
- ISO/IEC 27001 certified Information Security Management System
- Encryption of sensitive information in storage and in transit
- Regular backups against data loss
- Strict access controls limiting exposure
- Full on-premises option for maximum control and compliance flexibility
How does your support system work?
Every university is assigned a dedicated account manager from our support team. In many regions support is also available locally through trusted partner companies or distributors.
Advanced technical issues and feature requests go to second-line support, handled directly by the core development team — so the hardest problems reach the people who wrote the code. Everything runs through a help desk with a trackable ticketing system for all inquiries.
Support is not an optional add-on. It is a fundamental part of how we sell: every Wise Timetable licence includes it in full.
Can we publish everything on our university website?
Yes. Wise Timetable provides ready-made web pages served directly by the application server. Link them from your site or embed them in an iframe and they appear as a seamless part of your own design, including your institution's logo.
For deeper integration, the REST API lets your internal systems read schedule data directly, enabling real-time display, automated reporting and interoperability with the rest of your infrastructure.
Hosting, upgrades and the academic year
Cloud or on our own servers?
Either. Cloud services can be running in a day and we look after them; a full on-premises installation is offered where your data governance requires that nothing leaves your network.
Cloud hosting sets out what we provide and what an institution has to supply.
What happens at the end of an academic year?
Last year's structure carries forward and only the changes need attention, which is why a second year is dramatically quicker than a first. Most institutions keep several published timetables at once — the current year, next year during the transition, and one for internal verification.
Year transition is the manual for the changeover itself.
How are upgrades handled, and will they interrupt us?
For cloud installations we apply them, and the browser application needs nothing installed on anybody's machine, so there is no rollout to organise on your side.
Where a desktop planner is in use it is updated separately, and we say so in advance when a release needs the two to move together.
What about backups?
Cloud installations are backed up regularly as part of the service, with sensitive data encrypted in storage and in transit. On-premises installations back up with the rest of your estate, and we will tell your administrators exactly what has to be in the set.
Our information security management is certified to ISO/IEC 27001:2022, which covers how those backups are handled rather than only that they exist.
Can we see the software before we commit?
Yes, three ways: a trial you download, a demonstration against your own scheduling problem rather than ours, and every manual on this site, free and ungated, including the 278-page one.
We would rather you found a mismatch during an evaluation than three months into an implementation.
Still have a question?
Ask it on a short call. We would rather answer honestly up front than discover a mismatch three months into an implementation.