Turn an accepted service package into separate scheduled jobs

Find the version the customer actually accepted and give it a stable reference. Copy its service names, quantities, frequency and agreed billing terms into the matrix. Keep the original acceptance available to whoever schedules the work; a calendar entry should not become the only surviving description of the package.

If a detail is missing, record the question rather than filling it with an assumption. For example, an autumn cleanup may be agreed without a specific week. That service can remain accepted while its visit window is still awaiting confirmation. A change to the work or price needs its own recorded agreement, rather than an unnoticed edit to a scheduling row.

Use one row for a recurring mowing series and a different row for a one-time planting-bed visit. Split work when it needs a different frequency, crew, location or completion record. There is no need to create a new customer quote for every row if the existing acceptance already covers the work; check how your current system links jobs to that quote.

In the fictional example, package PKG-104 covers a weekly mowing series, a planting-bed visit and an autumn cleanup. Their shared package reference lets the office trace each job back to the same agreement. The rows remain distinct so that moving a cleanup visit does not silently change the mowing series.

One fictional package produces three scheduling records.

• Service: Mowing; Scheduling record: Recurring series JOB-104-M; Decision still needed: Confirm the first visit
• Service: Planting-bed visit; Scheduling record: One-time job JOB-104-B; Decision still needed: Confirm the visit window
• Service: Autumn cleanup; Scheduling record: Seasonal job JOB-104-C; Decision still needed: Agree the week before dispatch

A weekly visit does not automatically mean a weekly invoice. Copy the agreed billing treatment into each row, whether that is inclusion in a package payment or a charge after the individual job. If the agreement is unclear, resolve the billing question before the office creates an invoice.

The example places mowing inside a monthly package charge, while the other services are billed after completion under their recorded terms. Those are fictional choices, not a recommended pricing model. The matrix does not calculate tax, replace an invoice or decide what the customer owes. Its purpose is to prevent the scheduler and billing person from working from different versions of the agreement.

When weather or access changes a visit, retain its original planned date, add the revised window and write the reason. Check whether the move affects only that visit or creates a conflict with later work. Ask the scheduling owner to decide explicitly; do not move every future visit merely because one job slipped.

Close a visit with a completion date and a short reference to its work record. A scheduled job, a completed job and a billed job are separate states. Before reusing a package next season, check its scope and acceptance again instead of treating last year's rows as a renewed order.

Replace the fictional rows with one real accepted package and ask the person who schedules visits to explain what happens next for each service. Any row they cannot schedule exposes a specific missing decision. Resolve those questions before copying the method across your other packages.

Your existing scheduling system may already connect several services to one package. Check how it represents different frequencies and billing references before adding another register.

Ask Areinum Assistant to organise the accepted package details you provide into a service-by-service scheduling draft. The scheduling owner checks dates, billing references and the accepted scope before updating the job system.