Job Scheduling Software

Job scheduling means assigning work to people and times where the work happens somewhere. That is the shape of trades, field service, installations, deliveries, and inspections, and it is different enough from shift rostering or appointment booking that tools built for those disappoint.

We sell source code you clone and run yourself, so there is nothing hosted here. For most businesses this is a buy, and the sections below are about what makes the category distinct.

Three scheduling problems that get sold as one

The last row is the defining property. In job scheduling the day is a chain, and a delay propagates. Any tool worth using has to make rescheduling the rest of a day cheap, because it happens constantly.

What job scheduling has to handle

Skills and certifications decide who can do which job, and a scheduler that treats engineers as interchangeable will send the wrong one. Parts availability decides whether a job can proceed at all, and dispatching somebody without the part wastes two visits instead of one. Travel time between consecutive jobs is real working time and leaving it out produces schedules that look full and are impossible.

Then there is the customer, who was given a time window and needs telling when it changes. Notification is not an extra here; it is what prevents the phone call that costs more than the job.

Estimated durations are the quiet problem

Job scheduling depends on knowing how long work takes, and that estimate comes from somebody's judgement. It is systematically optimistic, and the effect compounds across a day.

The fix is measurement rather than better guessing. Recording actual duration against job type, and letting the estimate follow the history, is the single improvement that makes schedules more realistic. It requires the completion data to be captured properly, which brings the usual field constraint: technicians close jobs standing up, often without signal, and a system that makes that hard gets fed guesses instead of times.

Automatic optimisation, honestly

Route and schedule optimisation is heavily marketed and genuinely useful when there are enough jobs and enough people for the combinatorics to beat a human. Below that scale, an experienced dispatcher with a map usually does better, because they know things the model does not.

The version that works in practice is assisted: the system proposes an order, the dispatcher adjusts, and the reasons for adjustment gradually become constraints. When evaluating, ask what happens to a manual override when the schedule is recalculated, because a system that discards overrides will be abandoned.

When businesses build

Rarely for a standard trade or service operation, because field service management products cover it and the mobile half is substantial.

The build case is a marketplace or platform: matching independent tradespeople to customer jobs, coordinating subcontractors across clients, or a vertical where the scheduling is part of a product you sell. Those need multi-tenant isolation and often payments between parties, and the field service products are built for a single operator.

What you would start from here

There is no job scheduling in this stack. No jobs, no dispatch, no skills matching, no route optimisation, no mobile app, and no offline capture.

What the Open Calendar template provides is the surrounding application: organizations so each operator or client is isolated, roles and invitations, and a calendar with five views, drag to reschedule, and working hours built on a CalendarEvent with a start, an end, an organiser, and attendees. Underneath is a Hono backend with Prisma and Kysely on Postgres, an admin app, and Stripe billing. The notifications pack handles in-app and email delivery for the customer updates described above; text messages would be a separate integration with its own bill.

Two gaps to plan for. There is no recurrence rule, so recurring maintenance visits are a model you add. And a job is a richer record than an event with attendees, since it carries a location, a skill requirement, parts, and an estimated duration, so expect to write that model rather than adapt the calendar one.

For a single operation, buy a field service product. The packs below are for the platform case.