Scheduling that holds up.

Almost nobody double-books on purpose. It happens in three places, and all three are about where the plan lives rather than about how careful the planner is.

The plan is a file. Whoever has the file has the truth. The change made at seven in the morning sits in a version somebody else never opened, and two fitters drive to the same address. The spreadsheet is not the problem; the copy is.

The change arrived by phone. A customer moves Tuesday to Thursday, the planner writes it on a note, and the board still says Tuesday. The person who is now free on Tuesday gets booked again that afternoon by somebody who read the board.

The job moved, and nobody re-checked the people on it. This is the one that survives a move to software. Dragging a job to a new time is not the same act as assigning somebody, so a system that only checks at assignment lets the move through unexamined. Moving a job into somebody's afternoon is the same mistake as booking them there directly, and it has to be checked the same way.

How a double booking actually forms walks through the sequence one step at a time.

The tempting design is to make a clash impossible. It is the wrong one. A planner who is refused outright writes the job on paper instead, and the schedule stops being where the truth is, which was the only thing it was for.

So the check produces a list of findings rather than a yes or no. Four checks, two severities:

• Double booked — the person is already on another job in that window. An error.
• Not employed on that date — before they started or after they left. An error.
• Absent — holiday, sick, leave or training covers the time. A warning.
• Outside working hours — the booking falls outside the hours recorded for that weekday, or on a day they do not normally work. A warning.

An error interrupts the save once: the request comes back with what it clashed with, by job number and time, and the planner can confirm and send it again. A warning never stops anything, and it is returned alongside the job that was saved, so the planner still sees that they have booked somebody through their holiday.

Two details keep the warnings worth reading. Overlap is half-open at both ends, so a job finishing at 12:00 and one starting at 12:00 do not collide. And a cancelled job is not work, so a rescheduled visit does not report a clash with the booking it replaced.

There is also a read-only sweep of a date range, which is what the banner above the calendar is drawn from: the double booking you made yesterday is worth knowing about without having to drag anything to find it.

Two hours of work in Nacka and two hours in Täby is not four hours. It is four hours plus whatever the E4 is doing, and the gap is where a plan goes wrong first.

Three things in the schedule are about that gap, and it is worth being precise about which is which.

The plan and the promise are separate fields. A job carries a planned start and end, and separately the customer's window: the earliest it may start and the latest. "Any time Tuesday" and "at nine on Tuesday" are different promises, and squeezing both into one field costs you the slack you needed.

An estimate is on the job. The service catalogue carries a default duration, and the job carries its own estimate in minutes. That is the number to pad, not the one on the board.

Travel is a kind of reported time. A crew clocks in on travel rather than work, and it stays travel all the way through: it starts out unbilled, on the invoice basis it becomes a Restid line rather than a labour line, and it never carries a ROT or RUT deduction, because travel to the site does not qualify.

What is not there: route optimisation. It is on the roadmap and not in the product, so nothing sorts your day by driving distance today. Route planning for a small team is about the version you do by hand, which for five vans is usually the right version anyway.

Most scheduling advice assumes the work is already on the board. The hard part is the pile that is not: the job booked yesterday with no day on it, the callback somebody promised for "next week", the visit that depends on a part arriving.

A job with no planned start is filterable as exactly that, and the queue is the list a planner works from. Three rules keep it honest.

You can reserve a person before you have a day. Assigning somebody to unplanned work is allowed, and the job stays unplanned until it has a start. That is how a planner holds the one person who can do it while the customer decides.

Placing work is what makes a job scheduled. A booked job becomes scheduled when somebody is assigned to it with a time. Nobody has to remember a second step, because the status follows the act.

Taking the last person off puts it back in the queue. A scheduled job with nobody on it is not scheduled, so it drops back to booked and reappears in the list that still needs placing. Leaving the status alone would hide it, and the queue would quietly stop being complete.

The crew is told when there is something to be told: the assignment notification goes out by email on a genuinely new pairing, and only when the job has a day on it. Re-assigning the same person while dragging a job around all morning does not send anything, and "you have a job, at no particular time" is the kind of message that teaches people to ignore the next one. Assignment texts are off by default; a text message is billed at 0,89 kr.

From a work order to a finished job follows one job through the whole lifecycle.

"Anna knows the heat pumps" is a fact about your business that lives in one person's head until it is a row in a table. Free text on an employee card cannot be compared against anything, so it is a table.

A competence is a named thing. A person holds it at a level from 1 to 5, so the planner can see who is good at it and not only who is qualified; the scheduler itself does not rank people by level or warn on it. A service in the catalogue requires zero or more of them, and a service that requires none is one anybody can do, which is the common case and must not be mistaken for one nobody can.

From there, both directions are filterable while you plan: show me the people who hold this competence, show me the services this competence is required for.

Be clear about what this is not. Competence is not a fifth conflict check. The scheduler will not warn you that you have sent somebody unqualified — the four checks are double booking, absence, working hours and employment dates, and that is the whole list. Matching is something you do while choosing who to drag onto the job, not something that catches you afterwards. If a certification is the thing you cannot get wrong, filter first and make it the first move of the morning rather than the last check before saving.

The hours somebody is normally available are a rule, not a calendar: a weekday, a start time and an end time. "Tuesdays, 07:00 to 16:00" outlives any particular Tuesday.

Those rules carry a validity range, which is the detail that matters later. When a timesheet from March is questioned in June, the rule that applied in March is still there. Editing in place would leave you defending a schedule against hours nobody was working under.

Absence is separate and wins over the weekly rule. Four kinds — holiday, sick, leave, training — recorded as timestamps rather than dates, because half a day off is the common case and a whole-day flag cannot express "leaves at two". Overlap is half-open, so an absence ending at 12:00 does not block a job starting at 12:00. An absence that has been requested and not yet decided still produces the warning; only a rejected one is ignored.

One deliberate silence: somebody with no working-hours rules at all is never warned for not having them. Most organisations will never fill this in, and a schedule that warned on every booking is one nobody reads.

And one deliberate limit. This reports; it does not compute. Absence and hours outside the recorded ones come back as warnings a human reads. Nothing here interprets your kollektivavtal, calculates dygnsvila, or works out an OB supplement. That belongs in the payroll system, and a scheduler that pretended otherwise would be wrong in a way nobody notices until the year-end.

Here is the bug that quietly ruins conflict checking, and it is worth understanding because almost every first implementation has it.

Somebody records their Tuesday as two rules: 08:00 to 12:00, and 13:00 to 17:00. There is a lunch break in the middle. Now book an ordinary job from 09:00 to 15:00.

The obvious check is: does any single rule contain this booking? No rule does. The morning rule stops at twelve, the afternoon rule starts at one. So the system reports an entirely normal day as outside working hours — and it does that for every full-day job on that weekday, for that person, forever. A warning that fires on every ordinary booking is worse than no warning at all: the planner stops reading them, and the double bookings go unread alongside.

The fix is to ask the day's rules together rather than one at a time. Sort the day's spans, merge any two separated by no more than 60 minutes, then ask whether the merged span contains the booking. 08:00 to 12:00 and 13:00 to 17:00 become 08:00 to 17:00, the 09:00 to 15:00 job is inside it, and nothing is reported.

Sixty minutes because that is what a Swedish lunch break is recorded as when anybody records one at all. It is a threshold, not a claim about what the gap was for: nothing knows what somebody did between twelve and one, only that a gap that short is far likelier to be lunch than a second shift.

The case the merge is there to keep still works. Hours of 06:00 to 10:00 and 18:00 to 22:00 are eight hours apart, are not merged, and an afternoon booking is still reported as outside them. That is a genuine split shift, and putting a job in the middle of it is genuinely worth a word.

Roughly a third of the work in a service company is the same work, for the same customer, on the same rhythm. Window cleaning every fourth Thursday. A boiler service every six months. Replanning it by hand every Monday is the kind of task that is never quite wrong enough to fix.

An agreement holds a customer, a template for the job and a recurrence rule, and writes the jobs the rule implies.

The rule language is deliberately small. Weekly, daily or monthly; an interval; specific weekdays; and either a count or an end date. Anything outside that — positional weekdays, BYSETPOS, a week that starts on Sunday — is refused when you save the rule, with the part it did not understand named back to you. That refusal is the point. Recurrence is a large specification with corners where a plausible-looking implementation quietly produces the wrong days, and wrong days here are not a rendering bug: they are jobs that appear on a board, get assigned, and get driven to. Nobody proof-reads a schedule that writes itself.

Generation looks forward only. A rule that started in January does not deposit six months of backdated jobs the first time it runs. Work nobody did is not work, and a board full of overdue phantoms is a board nobody trusts.

It writes to a horizon you set. A lead time between 1 and 120 days decides how far ahead the jobs appear, and the agreement's own end date caps it: a contract that finishes in March does not have April on the board in February.

An occurrence is written once. Not by checking first — by a uniqueness constraint on the agreement and the date, which is what holds when the nightly run and somebody pressing "generate now" overlap. A visit that was cancelled counts as written: somebody who cancelled next Tuesday meant it, and having the generator put it back the following morning is exactly the behaviour that teaches an office to stop using the schedule.

Pause, do not delete. A customer who suspends over the summer wants the same rule back in September, and deleting it would cut the link from every job it ever wrote.

Weeks start on Monday throughout — in the expansion, in the schedule board, and in the reports. One run of one agreement writes at most 200 jobs, which is a mistyped lead time rather than an agreement anybody made.