Snow Removal Software — Data Model | FieldCamp

How a snow and ice removal business runs in FieldCamp — seasonal contracts, per-event billing, commercial lots as Sites, salt tracking, and a log per storm.

A snow and ice removal business runs on a backbone FieldCamp already gives you: a customer signs a winter contract, you assign sites to plow routes, a storm hits, crews clear and salt, and you bill.

That chain is modeled as Request → Estimate → Job → Visit(s) → Invoice → Payment.

What makes snow different is the storm. Work is triggered by weather, billed in several models at once, and documented per event for liability — because a slip-and-fall claim is won or lost on whether you can prove when you cleared and what you applied.

The setup adds a few records on top of the core: a Site for each commercial lot, a Storm Log for what happened on each property each storm, and a Seasonal Service Agreement that holds the contract and its billing model.

What the core already gives you

Most of a snow operation is covered the moment you sign up. You build nothing to get these.

Routes and recurring visits. A Job set to recurring auto-generates Visits on a daily, weekly, or as-needed pattern — the standing route a crew runs whenever it snows.
Territory and route scheduling. Service Areas group sites by zone so the dispatcher assigns plow trucks and salt routes by geography.
Crews on every stop. Each Visit is staffed by one or more team members, matched by skill and service area, with conflict and capacity warnings.
On-site proof. A Visit captures en route, arrived, working, and done with GPS check-in and check-out, before-and-after photos, and an optional signature — the timestamped record a liability claim turns on.
Structured capture per stop. Job Forms give the crew a per-storm checklist — snow depth, conditions, areas cleared, material applied — filled in on site.
Several billing models. Estimates and Invoices support deposits, Net-30 and Net-60 terms, partial payments, and automatic overdue handling for both seasonal and per-event accounts.
A priced catalog. The price book holds plowing, shoveling, salting, and de-icer priced by the unit, with cost and price separated, plus inventory for bulk salt and bagged ice melt.
Lead intake. A Request captures a new bid and converts into an Estimate, Job, or Invoice.

The Customer record already separates billing, service, and property addresses, and marks each account as residential or commercial — enough for a single-driveway account.

What the core does not express on its own is the shape of a commercial snow account: one account with many lots, a contract whose price depends on the billing model, and a per-storm record on every property.

That is what the snow removal setup adds.

What snow removal adds

The snow setup adds three records, each a custom object built on the same customization engine as the core. Each is a real record with its own fields, its own connections, and its own page layout.

Site — the commercial lot

A Site is a single property you service — usually a commercial parking lot, but it can be any address with its own map, zones, and access.

Each account has many, and each holds its own file: scope, trigger depth, salt plan, and the crew that runs it. A Site is a child of the Customer account.

Field	What it holds
Site name	A label for the property
Site address	The per-lot location with directions and a map pin
Site type	Parking lot, drive lane, sidewalk, residential drive, or municipal
Site map	A marked-up plan showing plow zones, pile locations, and no-plow areas
Lot area	Plowable square footage, for pricing and salt estimates
Linear feet of walks	Sidewalk and walkway length to shovel and de-ice
Trigger depth	The accumulation, such as two inches, that starts service
Salt plan	Whether the site gets salt on every push, on ice only, or never
Priority tier	First-out, standard, or last, for storm sequencing
Access notes	Gate codes, hours the lot must stay clear, fragile landscaping
Default crew	The team members who normally run this lot
Service frequency	The standing route cadence the recurring Job follows

A Site belongs to a Customer, has many Jobs, and has many Storm Logs. Each Job carries a Site link so every work order names the lot it serves, and a Visit inherits the Site through its parent Job.

Its page is assembled from blocks: a header, the link to its parent account, the field group above, an address block with directions, the site map and access notes, the default crew, a table of Jobs at the lot, the list of Storm Logs, and service history.

A Site can carry a light status — Active, On Hold, or Inactive — so a manager sees at a glance which lots are live for the season. For most teams a Site is a reference record, so a simple status is enough.

Storm Log — the per-event service record

A Storm Log is the record of what happened on one property during one storm.

This is the document a slip-and-fall defense rests on: when the crew arrived and left, snow depth and conditions, what was cleared, and exactly how much salt or de-icer went down.

A Storm Log is a child of the Site and ties back to the Visit that produced it.

Field	What it holds
Storm date	When the event was serviced
Snow depth	Accumulation cleared, in inches
Conditions	Snowing, freezing rain, drifting, refreeze, or clear
Arrival time	When the crew reached the lot
Departure time	When the crew left the lot
Services performed	Plow, shovel, salt, sand, or de-ice
Material applied	The salt or ice-melt product used, from the price book
Quantity applied	Bags or tons of material put down at this stop
Photos	Before-and-after evidence of the cleared property
Crew notes	What was done and any conditions worth flagging
Linked Visit	The Visit this log documents

The snow-depth and conditions checklist itself is a Job Form filled in on the Visit; the Storm Log stores the resulting record and the links, so each property carries a stack of dated, photo-backed logs across the season.

A Storm Log page is built from a header, the link to its parent Site, the storm checklist form, the field group above, a photo gallery, check-in and check-out times, and the material applied.

Salt and de-icer live in the price book as priced items with inventory. Quantity applied on the Storm Log feeds the invoice line on time-and-materials work and draws down bulk stock, so a season's salt usage is tracked per property and in total.

Seasonal Service Agreement — the winter contract

A Seasonal Service Agreement is the contract that governs term, scope, and — the part that matters most in snow — the billing model.

Snow contracts are not one shape: the same account book holds seasonal flat-rate, per-push, per-event, per-inch tiers, and time-and-materials deals, often mixed. The agreement holds which model applies and ends as the season closes.

It is a child of the Customer account and a variant of the standard Service Agreement.

Field	What it holds
Agreement name	A label for the contract
Billing model	Seasonal flat, per-push, per-event, per-inch tier, or time-and-materials
Season start	When the term begins, such as November 1
Season end	When the term ends, such as April 15
Seasonal fee	The flat amount, for seasonal contracts
Per-push rate	The charge per qualifying push, for per-push contracts
Trigger depth	The accumulation that starts a billable service
Per-inch tiers	The rate steps for 1–3, 4–6, 7–12, and 12-plus inches
Salt billing	Whether salt is included or billed per application
Contract value	The total or estimated seasonal amount
Auto-renew	Whether the agreement rolls into next winter
Signed contract	The signed agreement document
Sites covered	The lots this contract spans, one or many

A Seasonal Service Agreement belongs to a Customer, covers many Sites, and spawns the recurring route Job that fulfills it. The Invoices billed under it — a monthly seasonal draw, or a per-event charge after each storm — link back to it.

Its page carries the field group above, terms and conditions, the signed-contract attachment, signature capture, the table of Jobs it spawned, the tiles of covered Sites, a financial summary, and a status banner showing active, expired, or renewal.

Billing models and the storm cycle

The billing model on the agreement decides how a storm turns into money. A seasonal flat contract bills on a calendar regardless of snow; a per-push or per-event contract bills only when service happens; time-and-materials bills the labor and salt logged on the Storm Log.

The cycle below shows how one storm flows through the records.

Weather does not start the cycle automatically. FieldCamp has no weather trigger, so a forecast or a measured accumulation cannot itself fire a stage change and dispatch crews — the four automation rule types react to record stage changes, not external weather data.

In practice a dispatcher activates the storm: recurring route Jobs and Visits keep the standing assignments ready, and storm response is started manually or through the separate workflow automation and dispatch tools.

The data model documents and bills the storm; it does not watch the sky.

Residential drives vs commercial lots

The same records serve both sides, but they are used very differently. The split is between a light residential driveway route and a documentation-heavy commercial lot contract.

Residential drives

Usually one customer to one driveway, so the Site record is optional — the Customer's property address often suffices. Contracts are commonly seasonal flat or per-push, a recurring Job covers the route, and completion is light, with a photo optional. Dense same-day routes are sequenced with Service Areas and the dispatcher. A Storm Log is usually overkill for a $40 driveway push.

Commercial lots

One customer to many lots, so the Site record is essential — a property manager may hold dozens of lots under one account, each with its own map, zones, and trigger depth. Contracts mix billing models, and every storm is logged per lot with GPS times, before-and-after photos, snow depth, and salt applied, because the liability exposure on a public parking lot is the whole reason the documentation exists.

You build the records once. Residential accounts lean on recurring Jobs and skip the heavy layer; commercial accounts use Site, Storm Log, and the agreement in full.

The completion difference does not need a second workflow. The same Visit workflow can require photos and a completed storm form on commercial lots and leave them optional on residential drives — one pipeline, configured per account.

Built on the customization engine

Every record on this page is built with the same tools your account already has.

The Site, Storm Log, and Seasonal Service Agreement are custom objects with their own fields; the agreement's draft-to-expired path is a custom workflow; and each record page is assembled from building blocks.

That means you can extend any of it — add a field to a Site, rename a billing model option, or rearrange a Storm Log page.

Start with custom objects and fields, shape the lifecycle in stages and workflows, and lay out each page from record layouts.

You can also add snow fields directly to core records without a new object: a trigger depth and salt plan on a Job, or a residential-or-commercial marker on a Customer for routing and reporting.

Built for any size. A one-truck operator plowing residential drives runs on the core records as-is. A commercial snow contractor holding dozens of lots adds the Site, Storm Log, and Seasonal Service Agreement layer — on the same backbone, no rebuild.

Coming from Service Autopilot

Many snow contractors run on Service Autopilot, which is strong for snow — pre-built master routes, a snow dispatch board, and flexible per-event billing. Others come from a lighter tool like Jobber.

Either way, most of that structure has a home in FieldCamp.

The difference is that in FieldCamp you own and shape the model, rather than fitting your operation to a fixed one.

In Service Autopilot	In FieldCamp	Notes
Client	Customers	The party responsible for billing. FieldCamp keeps billing, service, and property addresses on one record.
Property / Site	A Site, built as a custom object under the customer	One account holds many lots, each with its own map, zones, trigger depth, and crew.
Seasonal contract	Service Agreements	The winter contract that holds the term, the covered sites, and the billing model.
Master route	Service Areas	The zones that group lots into plow and salt routes for the dispatcher.
Snow service / job	Jobs and Visits	A recurring route Job spawns the Visits a crew runs each storm, with GPS, photos, and sign-off.
Per-event service record	A custom Storm Log object	The dated, photo-backed record of what was cleared and salted on each lot per storm.
Salt and material tracking	Price Book	Bulk salt and bagged ice melt as priced items with inventory and cost-versus-price.
Crew	Team Members	Assigned to routes by skill and service area, with conflict and capacity warnings.
Invoice	Estimates & Invoices	Seasonal draws and per-event charges, with terms, partial payments, and overdue handling.

What you gain. In Service Autopilot the structure is set for you — the objects, their fields, and how they relate.

In FieldCamp every one of those records is yours to rename, extend, restage, and relayout, so you can match your old setup first and then go past it with custom objects and fields and your own stages and workflows.

One honest difference. Service Autopilot triggers work from the forecast and runs seasonal billing on its own schedule.

FieldCamp's automations react to record changes, not weather data, so a storm is dispatched manually or through the standing recurring route rather than fired by a forecast. Seasonal billing runs through the standard invoice flow under the agreement.

If forecast-driven dispatch is central to how you run a storm, plan that part of the move deliberately.