The Catalog Entry for a Multi-Visit Service

Why this matters

Some jobs cannot be done in one visit: a repair waiting on a special-order component, a project phased across multiple days, an install that requires inspection between stages. Pricing and describing these as if they were a single-visit catalog entry creates confusion about what each visit covers, when payment is due, and what happens if a visit gets delayed. A catalog built without a distinct structure for multi-visit work forces every one of these jobs into a custom quote, which is slower for the office and less consistent for the customer than it needs to be.

Why a single-visit catalog structure doesn't fit

A standard catalog entry assumes one visit, one scope, one price, done. Multi-visit work breaks that assumption in three ways:

• The scope of each visit can differ. Visit one might be diagnostic and prep, visit two the actual repair or install, visit three a final check or inspection sign-off.
• Payment timing is not a single event. Customers reasonably expect to know whether they pay at the end, in stages, or with a deposit up front, and a single-visit entry has no field for that.
• Delay and rescheduling risk is higher. A part on order, a permit pending, or weather affecting an outdoor phase all introduce gaps a single-visit entry never has to account for.

What to define for a multi-visit catalog entry

• Name and describe each visit separately, under one parent entry. A customer and a tech should both be able to see "visit 1: assessment and prep," "visit 2: installation," without digging through a single wall of text.
• State what triggers the move from one visit to the next. Is it a fixed number of days, a part arriving, a permit clearing, a customer scheduling the next slot? Name the trigger so nobody is guessing why the job is "waiting."
• Define the payment structure explicitly. Whether it's a deposit at visit one, a milestone payment at each stage, or a single invoice at completion, state it in the entry itself so it is consistent across every job that uses it, not negotiated case by case.
• Note what happens if the job stalls between visits. A part delay or a customer reschedule should have a documented default (does a partial payment already made get held, refunded, applied differently), rather than an improvised answer under pressure.

Communicating the multi-visit structure to the customer

The biggest risk with multi-visit work is a customer who thought they were booking one appointment and is surprised to learn there's a second, or third, required. Set this expectation at the moment of booking, not at the end of visit one:

• State the total number of visits (or a realistic range, if it depends on findings) before work starts.
• State the rough timeline between visits, even if it is only an estimate, so a week of silence waiting on a part does not read as the shop forgetting about them.
• Confirm, in writing, what has been completed and what remains after each visit. This matters even more than on a single-visit job, because there is a gap for memory (the customer's and the shop's) to drift in.

Keep the parent entry and its visit stages in sync

Treat the multi-visit entry the same way you would treat catalog and price-book sync generally: if the scope of visit two changes, the parent entry's total price and description need to reflect that too, not just the sub-entry for that visit. See related: The Catalog and the Price Book: Keeping Them in Sync. A multi-visit job where only one stage got updated is a fast way to end up quoting a total that no longer adds up to its parts.

References

• Trade-standard practice for phased and multi-visit service agreements
• See related: The Catalog and the Price Book: Keeping Them in Sync
• See related: Custom Quote vs Catalog Price Decision Tree