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. With no route chosen, the list follows your saved master-route order (route by route, stop by stop), with jobs on no route after them, and each stop picks up its route's default crew unless you choose a crew in the dialog. 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.

The dialog always opens on the storm you're viewing: Dispatch Date is that storm's date and Max Trigger Inches its forecast. When you change a filter, any row it newly excludes is unticked, so a highlighted row only goes out if you tick it again yourself.

Jobs are also excluded automatically if today isn't one of the days their contract authorizes service on. A snow job whose contract has ended (cancelled, expired, inactive, deleted or past its end date — unless the contract includes storms outside its dates) no longer appears on this board at all. 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.

The snow dispatch board fits phone widths too: the toolbar scrolls sideways and the controls get bigger tap targets below desktop width, so you can dispatch from a 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 — hours on site (the time the crew was at the property, not multiplied by crew size). Each visit is its own row with its own depth reading, closed out separately.

Adding a push. A Per Push job bills every push on its own depth, so when a crew has to go back during a long storm, click Add push next to the client's name on that job's latest row. It adds the next push (marked Push 2, Push 3…) to the same storm with the same crew and men, at the end of the stop order and dated today, so it shows on the crew's list as its own stop. Close it out with its own depth like any other visit. Only Per Push jobs get extra pushes — a Per Event job is one visit per storm, and Add Jobs never adds a job that is already on the storm.

Skipped and cancelled stops are never closed out: they were called off rather than plowed, so Close Out (and Close Out Selected) leave them alone and nothing is billed for them. Once every visit for the event is closed out, move the storm event's status to Complete.

The Snow Jobs board has the same dark action bar as the Dispatch Board, so a storm can be run from one screen.

• Status tabs and filters. Tabs for All, Scheduled, Dispatched, In Progress, Completed, Skipped and Cancelled (each with a count), a multi-select crew filter that includes Unassigned, and a search box that matches client, address, zip, notes and crew.
• Changing crews. The Crew column is a dropdown on every row. To move several stops, tick them and use Assign crew… in the selection bar. Setting a stop to Unassigned pins it to no crew rather than falling back to the job's crew. A stop shows the crew on its visit, or the job's crew if the visit has none — Team Assign uses the same rule.
• Route order. The # column is each stop's position within its crew's route; the arrows beside it move a stop up or down, and the order is saved. Optimize (next to a Nearest first / Furthest first choice) routes each crew separately by driving time, starting from the crew's own starting address or, failing that, the Company Address in Settings > Organization, and saves the result. With rows selected it routes only those. After optimizing, each row shows the drive time to arrive at it (⌂ from the shop for the first stop, ↑ from the stop above for the rest).
• Actions menu. Dispatch Selected (or Dispatch All Assigned when nothing is selected), Close Out Selected, Skip Selected and Cancel Selected, Team Assign, Optimize Routes, Show Crew Stats, Print Route Sheets, and Clear Filters & Selection.
• Keeping the same order storm to storm. Once you've ordered the stops the way you want them (by hand or with Optimize), choose Actions > Save Order to Master Routes. Each crew's order is written onto its master route (the active route whose default crew is that crew, created and named after the crew if there isn't one), so the next storm's Add Jobs comes up in that sequence. Stops that weren't on this storm keep their place on the route, jobs new to the route go on the end, and a job moved to another crew moves to that crew's route (a job is on only one route). You can also edit the order directly in Settings > Services > Snow Routes.
• Skip and cancel with a reason. Skipping or cancelling asks for a reason — No snow at this site, Client cancelled, Equipment down, Site inaccessible, or your own. It is saved on the visit and shown on the client's timeline. The status icon on a row still just cycles status without asking.
• Crew stats. Show Crew Stats opens a card per crew with stops, done, left, and billable total. Skipped and cancelled stops show a dash in the Amt column and are left out of the Totals row and the crew totals, since nothing is billed for them.
• Notes to crew. A column you edit in place: click the cell, type, Save. It saves on the visit only and shows the job's note until you override it.
• Columns. The column chooser shows or hides Address, City, Zip, Trigger, Crew, Depth, Temp, Notes to Crew and Amt, and remembers your choice.
• Map. The Map button plots the stops currently shown, numbered by route position and coloured by crew.
• Weather. A chip above the storm bar shows the National Weather Service forecast and any active alerts for the storm date (US only, within about a week). It is only a heads-up — depth and temperature on a visit are still entered by hand at close-out.

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. A snow job linked to a contract is billed on the contract's cycle only while that contract is in force; once the contract is cancelled, expired, inactive or deleted, nothing else bills its visits, so they appear in this queue like any other snow visit.

Storms outside the contract dates. A storm visit dated before the contract's start date or after its end date is billed per event here by default. To have those storms covered by the contract price instead, open the contract and set Storms outside the contract dates (under its start and end dates) to Included in the contract. The setting appears once a snow job is linked to the contract, and changing it on a signed contract flags it as changed since signed.

A per-inch visit with no recorded depth (for example one completed from the crew app, where only the office Close Out records depth) is never priced at the bottom range — it shows no depth recorded, prices at $0 and waits in the queue. Type the measured depth into the box under its Billing column and the amount updates. When you Close Out a mixed batch, the hours you enter are split across the hourly jobs only.

Possibly already billed. An invoice made by hand for a snow push has no link back to the visit, so the visit would stay in the queue. When a queued visit's job already has a non-void invoice line for the same service date, the row shows an amber Possibly billed on invoice #N tag (or “a draft invoice” if that invoice has no number yet). If you generate with any of those visits selected, you're asked to confirm — Bill anyway bills it again, or cancel and check that invoice first.

Voided or deleted invoices release their visits. If you void (or delete) a snow invoice because the depth or rate was wrong, the storm visits it billed go straight back into the Snow Invoicing queue so you can bill them correctly — they're no longer treated as invoiced.

Snow invoices carry the client's terms. Each generated invoice takes the client's Invoice terms (or the company default), gets a matching due date so it ages and appears in past-due reminders, and copies the job's PO number and sales rep when the invoice covers a single job.

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.

Many snow contracts price by bands of snowfall rather than a straight rate per inch — for example 0–3" is $165, 3–6" is $299, and 6–9" is $422. That is interval billing, and you set it while creating the job: choose Per Event, Per Inch or Per Push as the invoice type and an Interval Billing — Rate by Inches table appears. Click Add Range for each band (from, to, flat rate). Leave the last range's to blank for an open-ended top band billed per inch (for example 12"+ at $57 per inch). The same table is on the job's Details tab afterwards, with a Save Ranges button.

• Per Event, Per Inch prices the storm's single deepest reading against the ranges. Per Push prices each visit by its own recorded depth against the ranges.
• Start each range where the previous one ends (0–3, 3–6, 6–9). A depth exactly on a boundary bills the lower range — exactly 3" is the 0–3 band, and 3.1" is the 3–6 band. Saving ranges with a gap or an overlap between them is refused with a message saying where. Ranges saved earlier with a small gap (0–3, 3.01–6) still work: a depth inside the gap bills the lower range.
• Pricing bands that end in .99 (0–1.99", 2–3.99", 4–5.99", 6–7.99", where exactly 4" counts as the 4–5.99 band): because a boundary depth bills the lower range and ranges can't have gaps, enter them as 0–1.99, 1.99–3.99, 3.99–5.99, 5.99–7.99. A push recorded at 4" then lands in 3.99–5.99 and bills the 4–5.99 price. Depths above the last range bill $0 unless the last range is left open-ended, so price anything deeper by hand or add a top range.
• A flat price per push (the same amount whatever the depth, for example a drive-lane-only push) is a Per Push job with a single range, such as 0–99" at the flat amount. The visit still needs a recorded depth to price; with none it waits in the Snow Invoicing queue at $0.
• If no range matches a depth (below the first range, or above the last one with no open-ended range), it falls back to the flat Rate Per Inch on the job. Only the last range may be open-ended.
• The Snow Jobs board totals and the Snow Invoicing queue both price from the ranges, and the queue's description column says when a row used them.

A snow job's invoice type decides whether the Services table matters for billing, so the job form limits it. Make one job per service (plowing, sidewalks, de-icing), each with its own invoice type and depth ranges, rather than one job with several services.

• When the price isn't used, the Rate field shows Not used and the job is saved with a $0 service price. Billing never read it, and a price there would only have inflated the job's value in reports.
• The Add Service button is disabled once a one-service type has its service. Choosing such a type after adding several services keeps the first and clears the prices, and the form says so. The same limits apply to the Services tab of an existing job and are enforced in the database, so imports and the API follow them too.
• Monthly Flat Rate does not invoice by itself. It bills only through a linked, active contract that generates invoices automatically, so saving the job requires choosing the client's contract; without one it would never be billed. Its storm visits stay out of the Snow Invoicing queue.

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.

• Status icon. Tapping a stop's status icon steps it forward through Scheduled, Dispatched and In Progress, and asks before marking it Completed (which invoices it) or reopening a completed stop. Skip a stop from the outcome dialog with a reason.
• Reordering. The up and down arrows are disabled while a new order is saving, so two quick taps can't swap the wrong stops.
• Tax-exempt clients. Snow invoices for a client marked tax-exempt carry no tax, even when the job came from a taxed estimate.