Snow Jobs & Storm Dispatch

Snow Jobs lives at CRM > Scheduling > Snow Jobs, and everything on that board is organized around a Storm Event — not individual visits. Instead of scheduling each client's plow separately, you create one event for the storm itself, add every client who needs service during it, and dispatch them together in priority order.

A storm event tracks a name, a date, an optional forecast depth, and an optional temperature. It also carries its own status — Pending → Working → Complete — which reflects the storm's actual life cycle: not yet touched, actively being dispatched and pushed, or wrapped up.

1. From the Snow Jobs board, click + New Storm Event.
2. The name defaults to Snow Event plus today's date — rename it if you want something more specific (e.g. "Feb 3 Nor'easter").
3. Set the event date. Optionally set a forecast depth (inches) and a temperature — the forecast depth is used later, when adding jobs, to automatically exclude clients whose contract only triggers at a higher depth than this storm is expected to drop.
4. The event opens on the board with status Pending until you start dispatching.

Click Add Jobs on an open storm event to bring up the candidate list — every client with a snow job, or just the stops on a chosen master route. Each candidate shows its trigger depth, its client's priority, and its assigned crew, and the list filters itself with three controls:

• Max Trigger Inches — defaults to the storm's forecast depth. Any client whose own trigger depth (the snowfall needed before their contract kicks in) is higher than this number is highlighted and excluded by default — this storm isn't deep enough to trigger their service.
• Min Priority — each client has a priority of High, Normal, or Low. Choosing "High and higher" here narrows the list to just your High-priority accounts; "Low and higher" (the default) includes everyone.
• Default Crew — applied to any selected job that doesn't already have a crew assigned.

Jobs are also excluded automatically if today isn't one of the days their contract authorizes service on. Everything not excluded is pre-checked; uncheck or check individual rows before clicking Add to Dispatch.

Once jobs are added, each one becomes a visit row on the board with a status you cycle through by clicking its icon: scheduled → dispatched → in progress → completed → skipped. Use Team Assign to move unassigned visits onto crews — drag a card, tap a card and then tap the crew column it should go to, or click a crew's name on the card for a one-tap assign. Then Dispatch Assigned pushes every crewed, scheduled visit to dispatched at once. Print generates a route sheet per crew with checkboxes for weather and site conditions, full plow, and salt bags, for a paper copy on the truck.

Snowfall depth is not pulled from a weather feed — it's recorded manually, per visit, when the crew's work is closed out. Select one or more completed visits and click Close Out… to enter the actual depth (in), temperature, asset type used, any material (e.g. salt) with quantity and unit cost, and — for hourly-billed jobs — actual hours on site. This is also how a "push" gets logged: if a crew visits a client twice during one long storm (morning and afternoon), each visit is its own row with its own depth reading, closed out separately.

Once every visit for the event is closed out, move the storm event's status to Complete.

1. A dispatcher sees a storm coming and clicks + New Storm Event, names it, sets the date, and enters a forecast depth of 6".
2. They click Add Jobs. With Max Trigger Inches defaulted to 6, every client whose contract needs more than 6" to trigger is auto-excluded. Out of the org's full snow client list, 40 clients qualify and get added to the event, each carrying the priority already set on their client record.
3. The event moves to Working. The dispatcher opens Team Assign, moves the High-priority clients onto the first crews out the door, and dispatches them — hospitals, fire lanes, and SLA accounts get plowed first, before the Normal- and Low-priority stops.
4. As the storm continues, some clients need a second pass. Crews return, and each return visit is closed out on its own with its own depth reading — a morning push logged at 3", an afternoon push logged at another 3" once the storm finishes dropping its full 6".
5. Once every crew has closed out every visit, the dispatcher sets the storm event's status to Complete. The event is now ready for Snow Invoicing.

CRM > Accounting > Snow Invoicing groups a client's uninvoiced storm visits and computes the amount from the job's own invoice type — a flat rate per storm event, a rate per inch of snowfall (charged once per event, or separately per push), or an hourly rate times actual hours logged. Only completed, non-contract snow visits that don't already have an invoice line item appear in the queue, so generating invoices twice never double-bills.

For Per Event and Per Event/Per Inch jobs, every visit on the storm collapses into one charge — a morning push and an afternoon push during the same event are one line, priced off the storm's single deepest reading, not two separate charges. Per Push and Hourly jobs are the opposite: each visit prices and invoices on its own.

A regular Landscapt invoice itemizes a fixed, known job — a monthly mow, a package installment — where the amount is settled the moment the invoice is written. Snow doesn't work that way: a single storm can generate several visits per client over hours or days, and the price isn't knowable until the storm is over and every visit has been closed out with its actual depth or hours. Snow Invoicing exists because that accumulate-then-rate step — grouping a client's visits by storm event, applying the job's own rate type to the group, and only then producing a line item — has no equivalent in the regular Invoicing screen's one-job-one-line model.

Day-to-day, non-snow visit dispatch uses a different screen entirely — see the Dispatch Board guide for how the daily list-view board assigns and dispatches ordinary jobs. Snow storm dispatch is intentionally its own storm-event-centric flow rather than a daily board, since a storm doesn't respect calendar days the way a regular route does.