How to Schedule a Window Cleaning Round by Van and Territory

Why do window cleaning rounds need territories?

Because route density is where a window cleaning business makes or loses its margin. A van that does thirty houses on four neighbouring streets earns far more per hour than a van doing the same thirty spread across a county. Without territories, every day is planned from scratch, vans cross each other's patches, and the office cannot tell at a glance whether a day makes sense.

Territories also make everything else possible. Top-up, missed-visit rescheduling and placing new customers all need an answer to one question: when is a van next on this street? If vans have no fixed patch, that question has no good answer.

Why should the van be the scheduling unit, not the cleaner?

Because people move between vans and the streets do not. On the morning, two lads might swap vans, someone might be off, a new starter might double up. If the round is assigned to people, every one of those changes breaks the plan.

So the model is two separate mappings:

• Work to van: every visit belongs to Van 1 to Van 8, decided by where the house is.
• People to van: each cleaner's account points at the van they are driving today, and the office can change it in seconds.

A "See the crew" view on each van then answers the office's real question: who is actually on Van 3 right now, and are they signed in?

How do you define a van's territory?

Start with a list of postcodes per van, then add a map-drawn area for anything the list does not catch.

1. Postcode list first. Van 3 covers CF24, CF23 and CF3, for example. It is quick to set up, easy for the office to read, and covers most houses.
2. Map area as the fallback. Draw the van's patch on a map. Any address not matched by the list is geocoded and placed by which area it falls inside.
3. Normalise the input. "CF24 1UQ", "cf241uq" and "CF24 1UQ" must all read the same. Small, but it is the difference between a job landing on the right van and an unassigned job nobody notices.
4. Flag what fits nowhere. An address outside every territory is either a new area or a lead you should not have accepted. Either way it needs a human, not a guess.

In the system I built, matching runs postcode list first, then Mapbox geocoding against the drawn areas, for every visit, so the calendar can be coloured by van and a job sitting in the wrong patch is obvious.

What is the round rule for moving a job?

When a job has to move, it goes to the next day a van is genuinely back in that postcode. Not tomorrow, not the first empty slot, and not a quiet day twenty miles away. A busy day the van is already on beats an empty day that needs a special trip.

"Genuinely back" needs a definition, or the rule fools itself:

• Require a real cluster. At least five genuine jobs in that postcode on a day before it counts as a round day. One or two jobs is a stray, not a round.
• Prefer the same few streets. Look first for a day the van is in the job's own postcode sector (CF24 1, for CF24 1UQ, with at least three jobs there), and only fall back to the wider area if no day in the fortnight has that.
• Ignore jobs that only arrived because of a miss. Otherwise one miss on Thursday makes Thursday look like a CF83 day, the next miss follows it, and within a week you have a busy day no van is actually going to.
• Give it a horizon. If the round is not back within 14 days, a cleaner on the road is told to skip to next cycle or ring the office rather than the system inventing a date.

The important design choice: use one round rule everywhere a date gets picked. Missed visits, the end-of-day roll-over and clearing a broken-down van's day should all agree, or the office will see three different answers to the same question.

How do you do this on Jobber?

Jobber holds the record; the territory logic lives in a layer on top. Jobber stores clients, properties and visits well, and its GraphQL API lets an external system read the day and move visits. What it does not have is the concept of a van owning postcodes or a rule for choosing the next round day.

A practical setup looks like this:

• A small database of vans, each with its postcode list and drawn area.
• A process that reads each day's visits from Jobber and assigns each to a van.
• A calendar with one column per van, so the office plans in the shape the business actually works.
• Every move written back to Jobber, and Jobber webhooks so changes made inside Jobber appear immediately.

One limitation worth knowing: Jobber schedules team members, its vehicles are only available on some plans, and the API cannot create team members, so the van assignment lives in the planning layer rather than inside Jobber itself. That is fine as long as the layer, not someone's memory, is the place the office looks.

Where should you start?

Write your territories down before you build anything. For each van: which postcodes, which days, and where the edges are fuzzy. If you cannot write it down, the software cannot follow it either.

Then colour last week's real jobs by van on a map. The crossings and long legs jump out immediately, and they tell you which territory changes will save the most driving. Only then automate the assignment. The 8-week cycle guide covers how territories and days fit together across 4-weekly and 8-weekly customers.

Frequently asked questions