Service operations / customer communication

New Service Contact? Check Who Gets the Next Visit Reminder

Update a service contact without changing the wrong property, billing recipient or portal access. Check the next booked job and future contact defaults separately.

The short answer

After a service-contact change, reopen the next booked job and check the technician's contact instructions, intended visit-message recipient and roles that must stay unchanged. Inspect future-job defaults separately. A saved name or number is not evidence that the next reminder recipient changed, a queued notice was rerouted or a customer received anything.

This original proposed workflow separates contact data, recipient selection, billing or approval responsibility and portal access. No customer record, message queue or account was tested. It does not change the booked service date or scope.

Classify the request before editing

Identify whether the same person has new details, a replacement person covers one property, a temporary person handles access for one visit, or billing and approval roles are separately being changed. Use your business's established authorization process and record the customer, property, job and effective date. A role label does not establish legal approval authority.

Keep the instruction narrow enough that another office worker can apply it without guessing. There is no need for a new CRM, bulk import or duplicate client merely to describe this scope. Record references in the shared worksheet and keep phone numbers, emails and private customer details in authorized records.

Copyable scope instruction: editorial aid, not a native control
Change requested by[verified requester / existing record reference]
Effective for[property and booked job, or specified future work]
Contact change[new details / replacement / temporary]
Intended visit-message recipient[person / approved channel]
Leave unchanged[other properties, other contacts, billing and approval]
Portal or account-access decision[separately approved / not needed / unresolved]

A temporary access contact may need only one operational message. Do not assume that adding them to every available contact field is harmless. Pause when the software action would grant broader access than the approved need.

Check the actual contact and recipient selections

Jobber's client documentation says additional client contacts also receive client-hub access and have their own communication settings. Billing selection affects document recipients. Primary contact or number defaults do not establish a sole recipient if other contacts are enabled. Adding an onsite person can therefore change more than the office intended.

The properties guide describes contacts associated with selected properties, including multiple properties, contact methods, selected communication types and an optional billing role. Inspect the exact associations and types. Do not infer isolated portal access from a property-contact label.

Jobber's reminder documentation requires a usable mobile number and text eligibility, with contact communication settings also relevant. Email upcoming-visit settings may be disabled. Storing a number is not proof that it is the configured recipient, that a notice arrived or that the intended communication is authorized. Enabling all notifications is not a scoped fix.

Check the next job against the instruction, including the old primary number and other enabled contacts. Use a supported recipient preview or documented selection where available. Do not send an actual customer reminder as a diagnostic test. Keep pending-message routing unknown unless the product supports and verifies that check.

Separate existing jobs from future defaults

ServiceM8's client-card overview says PrimaryContact is applied as JobContact when creating a new job, with billing separate. It does not establish that changing the client default rewrites every existing job. Reopen the relevant booked job and compare its current contact to the future default.

Smart Contacts documentation describes certain job-card edits updating the client card when the add-on is enabled, and the first contact of each type being auto-saved. That is not universal bidirectional synchronization. Inspect the relevant job and client record separately rather than assuming either side updates all open work.

ServiceM8's booking-reminder guide requires the Automation add-on and Booking Reminder badge. The recipient is Job Contact; missing required contact data means no send. Billing template fields do not redirect the recipient. These facts do not prove a contact edit reroutes a notice already queued. Ask Support for that specific uncertainty rather than promising all reminders are fixed.

Three fictional propagation cases

These are expected checks, not observed outcomes. Leave the actual result blank until an authorized inspection establishes it.

Fictional cases: scope before propagation
CaseProposed inspectionActual result
DEMO-CONTACT-1: same person, new mobileKeep the next booked job unchanged. Inspect actual job contact, old primary number, other enabled contacts and channel settings. Review a supported preview without sending a real reminder. Queued-message rerouting remains unknown unless verified.____________
DEMO-A and DEMO-B: two propertiesAlex replaces Sam for A only; Sam remains on B and Jordan stays billing. Inspect exact property associations and message types. Do not remove Sam globally or add Alex everywhere. Portal access is a separate decision.____________
Temporary neighbour for one visitThe access role does not require invoices, follow-ups or portal access. Because an additional Jobber client contact can grant client-hub access, pause if that action is broader than the approved need and ask for a scoped method. Do not promise property-contact portal isolation.____________

After an authorized edit, compare the actual record with the scope instruction. Check what should remain as carefully as what should change. An unchanged billing contact or another property's contact is a positive preservation check, not an omission to fix.

Keep a short verification record

Contact-change verification: blank original record
FieldYour entry
Request reference, verified scope and effective time____________
Customer, property and booked-job references____________
Existing job contact and technician-visible instructions____________
Intended visit recipient and approved channel____________
Other enabled contacts and roles left unchanged____________
Future-job default inspected separately____________
Portal or account access: approved / unnecessary / unresolved____________
Pending reminder routing: verified evidence or unknown____________
Authorized inspection or change, owner and time____________
Remaining question, next owner and review time____________

Before departure, make sure the actual job instructions point to the intended access person and are visible to the technician through the authorized workflow. Keep billing, approval and other properties unchanged unless separately requested. Assign unresolved questions to someone who can clarify them rather than letting the crew discover the ambiguity at the gate.

Two unsent message drafts

Use only the approved channel. These original drafts are not delivery evidence and were not sent.

Clarify the scope

Hello [name], should [new contact] handle visit updates for [property or job] only, or for future work as well? Please also confirm which existing contact should remain responsible for [unchanged role]. We will review message recipients and account access separately.

Confirm only changes actually checked

Use this second draft only after the named change and inspection occurred. Keep an unresolved item visible:

Hello [name], we have updated [specific contact detail or role] for [property or job]. We have checked [specific recipient settings actually inspected]. [Other property or role] remains unchanged. [Unresolved item, if any] is still being reviewed by [owner]. This message does not change the booked service date or scope.

Configuration is not proof of delivery. Finish with the recorded scope, inspected recipient selection and an owner for anything still unknown. If entry has already failed, use the no-access visit workflow. If the arrival expectation changes, use the late-arrival update guide. Broader product fit belongs in the Jobber review or ServiceM8 review, without borrowing their test results for this contact change.

Sources and evidence

Official documentation reviewed through the verified research handoff on 9 October 2026. Links near claims identify their source. The worksheet, decisions and fictional exercises are original editorial suggestions, not observed product results.

Editorial record

Who reviewed this page and what happens next.

Commercial relationships cannot change the evidence state, fit statement, caveats, or conclusion.

Research and review
Andre Ribeiro
Published
Last material review
Next scheduled review
Evidence scope
Six official Jobber and ServiceM8 documents reviewed on 9 October 2026. Original scope instruction, verification record, three fictional cases and two unsent drafts.
Evidence state
Documentation and original proposed workflow only. No customer record, propagation, portal permission, reminder queue, delivery or account test was performed. Actual results remain blank.