What a job is, and why it never comes back

If you have used field service software before, the word “job” probably meant a ticket that gets reopened, rescheduled and eventually closed. Here it means something narrower and more useful: one visit’s worth of work, at one place, that happened.

What is on a job

• One property.
• One service.
• A set of that property’s items, each with its own status.
• A season and an agreement, if it was generated — or neither, if it is a one-off.

That is the whole thing. There is no assigned technician field and no scheduled date, because neither survives contact with a lake. What decides who does a job is which boat, with which gear, gets to that shoreline.

Two kinds of job

Seasonal jobs are generated from a standing agreement into a season. They are the bulk of your spring and fall.

One-off jobs are everything else: a repair, a relocate, a new install for somebody who is not on an agreement yet. Same table, same screens, same completion and pricing — they just have no agreement and no season behind them. A job is either fully seasonal or fully one-off; there is no half state.

Status is calculated, never typed

A job is pending while every item is untouched, in progress once at least one item is resolved, and completed when they all are. Nobody sets that by hand. The status follows the items, so the two can never disagree — which is a small design decision with a large consequence:

What a job needs, without anyone deciding

LakeOps works out what gear a job requires by asking its items and its property, rather than storing an answer that goes stale. Same for crew size: the job needs as many hands as its most demanding item. That is what lets a deployment tell a crew plainly which stops they are not equipped to finish today — equipment types and what gates a piece of work.

Completing one

Completing a job stamps it, stops any timer still running against it, prices it from your rate card, and — if completion emails are on — sends the customer a link to a page showing what was done. All of that is one action. See charge on completion.

A completed job never comes back

This is the rule worth understanding, because it is the opposite of what most systems do.

When next spring comes round, LakeOps does not find last spring’s job and set it back to pending. It creates a brand new job from the agreement. Last spring’s job stays finished forever, with its own items, its own price, its own timers and its own photos.

The reason is simple: the moment you reuse a row, you have thrown away the answer to “what did we actually do for these people in 2026, and what did we charge?” Once a season, that question is worth real money.

Canceling a job

A canceled job is a stop that is not going to happen — the customer pulled out, the equipment was already gone. It stays in the record and it stops appearing in the crew’s pool. It is not a delete, and it does not touch the agreement: if you want the work to stop happening every year, cancel the agreement instead.