# Scheduling jobs by the day, not the minute

> Field crews work a day, not a calendar slot. Modelling a job as "happens on this date" instead of "starts at 9:15" removes false precision, kills a class of timezone and drag-and-drop complexity, and matches how routes actually run. Recurring work anchors to an explicit start date, and edits choose between this occurrence and the whole future series.

URL: https://biloh.com.au/docs/concepts/scheduling-jobs-by-the-day
Category: Explanation | Audience: operator | Updated: 2026-06-26

A field-service schedule models each job as *happening on a date*, not *starting at a time*. That single choice — day granularity instead of minute granularity — is what keeps the schedule honest about how the work actually happens, and it removes a surprising amount of accidental complexity.

## Why a day, not a time slot?

A crew rarely keeps a 9:15 appointment the way a dentist does. They take a list of sites and work a route — mowing, cleaning, or servicing several properties across a morning in whatever order is efficient on the day. Pinning each job to a clock time is **false precision**: it implies a commitment the work doesn't make, and it drags in machinery that earns nothing — slot-collision rules, per-job timezone math, a calendar grid fine enough to need zooming on a phone.

Model the job as "on Tuesday" and the schedule says what's true: this is the day it's planned for. The crew owns the order within the day. Rescheduling becomes "drag it to Wednesday," not "find a free 45-minute slot." (And on a phone, dragging a card across a day grid is hard enough — see [drag is a desktop idiom](/docs/engineering-notes/drag-is-a-desktop-idiom) — without also asking the operator to land on a time.)

## How recurring work stays stable

A recurring service — weekly, fortnightly, monthly — is described by a recurrence rule with an **explicit start anchor**: the date the cadence is measured from. The anchor is deliberate, not "whenever this was last regenerated." If the rule re-materialises, a fortnightly job stays on its original week instead of silently flipping to the other fortnight. The anchor is the difference between a cadence that holds for years and one that drifts every time the schedule is rebuilt.

## Editing a series: the calendar model

Recurring jobs borrow the mental model people already have from consumer calendars. An edit asks for **scope**:

- **This occurrence** — move or change a single visit. The rest of the series is untouched. (Use it when one Tuesday is a public holiday.)
- **All future** — change the cadence, rate, or assignment from here on. The rule is re-materialised and future planned visits are respun on the new pattern; visits already done are left alone.

Keeping those two operations distinct is what lets an operator fix one bad date without rewriting the contract, and change the contract without hand-editing fifty visits. Which of those edits *bills* the client, and when, is a separate axis — covered in [when completing a job bills the client](/docs/concepts/when-completing-a-job-bills-the-client).

## Related

- [When completing a job bills the client](/docs/concepts/when-completing-a-job-bills-the-client)
- [Drag is a desktop idiom; the phone wants a tap](/docs/engineering-notes/drag-is-a-desktop-idiom)