How to use a Righthand with ServiceM8

Quick answer

Use Righthand to organize a ServiceM8 job follow-up list from approved job and activity records. Distinguish operational completion from invoicing or customer acceptance.

Start with a reviewable deliverable, keeping ServiceM8 as the accepted home for its records. This guide uses an explicitly approved snapshot or browser read; it does not assume that every provider API action is exposed by your Righthand connection.

Evidence and access

ServiceM8 provides a developer portal for connecting apps to its service workflows. See the official ServiceM8 reference. Provider capabilities and Righthand's available tools are separate checks.

Use one approved dispatch packet with job IDs, client details needed for review, technician assignment, visit times, and completion evidence. Verify the required tools and owner-approved scope through Righthand integrations; use the supplied packet when a native read is unavailable.

Define the objects and authority

Include these fields in the working input: job UUID, customer reference, status, appointment, recent note, attachment reference, next owner. These are the requested review columns, not a promise that every provider endpoint returns them under those exact names.

A job status should not independently determine invoice treatment or accepted completion. Keep customer communication and state changes with staff.

Illustrative first-run brief

Use the owner-provided ServiceM8 snapshot or approved read-only view. Review ten supplied recently completed jobs. Identify missing completion notes or unassigned follow-up questions. Return a staff checklist without changing jobs. Run once for the agreed sample, using America/Los_Angeles for the review deadline and preserving source timestamps separately. Return the draft in this conversation by Friday at 3 PM Pacific for the service manager to review. Include source references and missing fields. Do not write records, spend money, change permissions, or send external messages. Stop and report an unavailable source rather than substituting another account.

Expected result and verification

A completed status with no supporting note becomes a documentation check, not a claim the technician failed to work.

Open a sample job UUID and inspect the latest relevant note and attachment. Record the source cutoff, applied filters, and items excluded from the sample. The reviewer should be able to follow each consequential finding back to an original object. A well-written summary is not evidence that a proposed action happened. If a later write is authorized, verify its specific result separately before changing the task's status.

Illustrative input and draft output

These synthetic entries show the requested review, not live account results or a provider field schema.

Common failure and recovery

A cached job export can omit a recent staff update. Refresh the affected job and record its observation time.

If a technician note conflicts with the dispatch status, preserve both and ask the dispatcher to validate the actual visit outcome.

FAQ

What should the reviewer verify first?

Verify job identity, assigned technician, appointment timezone, required checklist, and completion evidence. A dispatch assignment is not an attended or finished visit.

How should a repeat run be scoped?

Preserve job IDs, schedule cutoff, and checklist versions. Refresh cancellations and technician changes before recurring reviews and hold completion claims without the required evidence.

For connection and permission details, use Righthand Docs. Review Pricing alongside any separate provider charges before expanding the workflow.