Jobs & Packages

Every job in Landscapt's crm_jobs table is exactly one job_type:

Dispatch Board, Waiting List, and Snow Jobs each get their own deep-dive guide — this page covers job types broadly, and goes deep on Packages and Projects specifically. See See also below for the others.

Two paths onto the schedule:

• Convert to Job — from an accepted estimate, pick a Job Type of One Time, Recurring, Project, or Waiting List. The estimate's services, quantities, pricing (net of any discounts), and crew size carry over onto the job. See the Estimating guide for the full walkthrough.
• Jobs → Add Job — the direct path for any type. The dialog opens with a Job Type selector (One Time, Recurring, Package, Project, Waiting List, or Snow, as available to your org); switching type swaps in that type's own fields. This is the only way to create a Package or Snow job.

The client picker in Add Job is searchable — type part of a name or an account number to find the account. Only clients appear in it:

What each type asks for in Add Job:

• Recurring — a service, a schedule, a Start Date, and an optional End Date (the season end). When a schedule and start date are set, the visits are generated automatically the moment the job is created — no separate step. Later, Generate Visits on the job fills in anything missing through the End Date (or through the end of the year when no End Date is set), up to 60 visits per run; a job whose End Date has already passed generates nothing.
• Package — pick the package program and a Start Date. Each step's date window and rate are seeded from the package template (rates default from the package or the service's own pricing). Changing the Start Date shifts every step window by the same number of days, so a program that starts two weeks late re-anchors as a whole instead of leaving its steps on the template dates. The dialog shows the billing summary as Monthly $X · Total $Y — the total is the sum of the step rates, spread evenly over the months the program covers.
• Snow — service, days authorized, inch trigger, invoice type, and rate. Picking a service fills in its default rate only while the rate is still blank; a rate you've already typed is never overwritten by choosing a service afterward.
• One Time, Project, Waiting List — a service line (or several), date or date range, crew, and team size.

The Team / Men count entered in the dialog lands on the job's visits, so the Dispatch Board's Men column shows the right headcount from the first visit.

A job's dollar value is the sum of its included service lines. That one number is what the Dispatch Board's AMT column, the visit detail sheet's costing, and the Jobs card on the client record all show — so re-pricing a service line on the job updates every one of those places at once, and the three can no longer drift apart.

The Jobs list has three tabs — Active, Unscheduled, and Completed. The Active tab's From / To date range applies to every job, keyed on the job's next pending visit: a job whose next visit falls outside the window isn't listed, including overdue jobs whose next visit is already in the past. The filter means exactly what it shows.

These are two separate state machines, tracked at two different levels, and it's easy to conflate them:

• Job status — one value on the job itself: scheduled, in_progress, completed, cancelled, skipped, or hold. This reflects the job as a whole — is it still active, done, or paused.
• Visit status — every individual scheduled occurrence of a job (each time a crew is sent out) has its own status: scheduled, dispatched, in_progress, completed, cancelled, or skipped. A recurring job with a season's worth of visits has one row per visit, each cycling through this list independently.

A job in the hold job status pauses future scheduling on that job without cancelling it outright — the CRM Client record itself has a related but separate on_hold value in its own status field, which is about the client relationship, not any one job.

CRM > Settings > Packages bundles a set of recurring services under one named program — e.g. a "7-Step Fertilizer" plan. A package has a name, an internal code, a description, client-facing wording for how it appears on an estimate, separate wording for how its visits appear on invoices, and a visits_per_season count.

The package's Services tab is where each visit in the program is defined, one row per visit. Per visit you set:

• Which service it uses (e.g. "Fert Application 1"), and an optional display name distinct from the service (e.g. "Visit 1")
• A date window (start/end) the visit should land inside
• Minimum days (Min Days) that must elapse between it and the step before it in the sequence
• Default budgeted hours and a default rate, used to seed the job once a client signs up

Until a package job's recurring dates are actually set, it behaves like a Waiting List job — no fixed date, only a range — and surfaces on the Waiting List page the same way.

The Package Summary Report tracks progress per package job by counting visits, not jobs: Total Visits is every visit on the job (cancelled ones included), Completed and Cancelled are counted by visit status, and Remaining is Total − Completed − Cancelled — so a cancelled visit reduces what is left to deliver rather than sitting in Remaining forever. Earned revenue is completed visits × the per-visit amount; Pending is the job total minus Earned, which means a package job with no visits generated yet shows as entirely Pending.

CRM > Scheduling > Projects tracks one-off landscaping jobs — a patio install, a large cleanup — separately from recurring service, for job-level cost tracking and reporting. This is the same project job type described in the table above.

• Dispatch Board — the daily scheduling view where visits get assigned to crews
• Waiting List — the opportunistic-dispatch queue for waiting_list jobs (and unscheduled package jobs)
• Snow Jobs — storm-based scheduling for the snow job type