How to use a Righthand with Jobber

Quick answer

Use Righthand to prepare a Jobber visit-readiness briefing for the dispatcher. Match client, job, and visit records before summarizing tomorrow's work.

Start with a reviewable deliverable, keeping Jobber 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

Jobber documents OAuth access with configured scopes and a versioned GraphQL API. See the official Jobber reference. Provider capabilities and Righthand's available tools are separate checks.

Use the approved client, quote, job, and visit packet with stable relationships and current statuses. Do not treat every quote as accepted work. 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: client ID, job ID, visit date, assigned staff, address, confirmed status, preparation note. These are the requested review columns, not a promise that every provider endpoint returns them under those exact names.

Client, quote, job, and visit are different objects. Dispatch changes, quotes, and customer messages require separate approval.

Illustrative first-run brief

Use the owner-provided Jobber snapshot or approved read-only view. Review the supplied next-day visits. Flag missing access notes, uncertain assignments, and mismatched addresses. Draft an internal readiness brief without scheduling or quoting. 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 dispatcher 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 job can exist while a particular visit has no confirmed staff assignment. That visit stays an exception.

Match one visit to its job and client reference, then check the actual service address. 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

Insufficient scopes or expired account access can leave a partial list. Report the scope gap rather than declaring no visits exist.

When a quote and job disagree, ask the service owner which accepted scope applies and hold the affected customer draft.

FAQ

What should the reviewer verify first?

Check quote version, accepted job ID, visit date, and customer context. Quote approval, scheduled work, and verified completion answer different questions.

How should a repeat run be scoped?

Keep quote and job relationships, visit IDs, and status cutoff between reviews. Re-read current scope before any authorized follow-up; a changed quote can invalidate an earlier draft.

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