Jobber integrations, from quote to first visit.

Set up customer quote follow-ups before adding another app

For unanswered estimates, Jobber’s native quote follow-ups can send up to two customer reminders on Connect and higher plans. They apply to quotes awaiting response. They differ from the staff reminders on your schedule, which do not contact customers.

Use a message that asks a useful question about the actual scope. Our contractor estimate follow-up templates cover new quotes, delayed projects and older estimates. Assign someone to handle the answers before you enable the reminders.

A custom connection earns its place when the office needs a behavior the native setup cannot demonstrate. Define that gap precisely: coordinated stop rules across systems, a business-specific exception queue, or a report that separates approved work from a scheduled visit.

1. Go to Settings from the gear menu, then Automations. Open a quote follow-up card.
2. Name it for its purpose and choose the delay after the original quote was sent.
3. Edit the message for your scope and reply owner. Save the automation when you are ready for it to run.
4. Check the original recipient’s communication settings: outstanding quote follow-ups must be enabled.
5. Inspect the original quote channel. Follow-ups use that method and the original local send time.
6. Review both follow-up cards alongside any external sequence so the same quote does not receive overlapping messages.

Use staff quote reminders when the next step is a phone call

A quote reminder can mean two different things in Jobber. The Work Settings instructions describe a schedule reminder for a team member. It does not send the customer an email or text. The reminder is assigned to the quote creator and is visible on the Jobber.com schedule rather than the mobile app.

To configure it, open Settings → Work Settings → Quotes, enable the reminder and choose the number of days after sending the quote. Then make the manual contact owner clear in your office process. The quote creator may be an administrator even when a different salesperson should make the call.

For a larger or more complicated scope, an owned phone task can be more useful than another generic email. Ask the caller to record the customer’s question, requested date and outcome against the correct project. If staff reminders and customer messages are both enabled, define how the office prevents a callback and a generic reminder from colliding.

A new automation does not work through your old quote backlog

Jobber’s Custom Automation Builder explicitly says new rules do not apply to past items retroactively. A time threshold is a moment when the rule becomes eligible, not an instruction to contact every quote older than that threshold.

For example, the office enables a 14-day rule on a Monday. A quote sent 40 days earlier is already beyond that point. Treat the future rule and the existing backlog as two separate pieces of work. Inspect the actual behavior in your account; switching on a rule is not evidence that older quotes have been reviewed or contacted.

A practical backlog review starts with current records. Find in-scope unsold work, read the latest customer conversation, and check whether a job or visit already exists. Then assign an action. Keep the real sent and approval dates; changing history to force a trigger can make reporting and later decisions misleading.

Try the existing app before commissioning a new one

A landscaping company wants to see which approved quotes still need a first visit. Before commissioning software, check the existing Jobber workflow and reporting experience. If an app already provides the needed view, test it with one real approved quote and one unscheduled job. Ask what “scheduled” means in that app.

Custom work becomes useful when the destination needs a business-specific rule, a combined report or a handoff an existing app does not cover. The first specification should be narrow: “Show approved landscaping work without a scheduled first visit, with a link to the correct job and a named office owner.” It should not simply say “sync Jobber.”

The Jobber API overview describes GraphQL, OAuth authorization, scoped access and date-versioned requests. These are implementation mechanisms, not evidence that a particular app exposes every field or workflow. Ask the builder to demonstrate the chosen schema and permissions.

Can your account use a custom integration?

Jobber’s Custom Integrations guidance says custom integrations are possible for specific approved customers and developers. It also explains that draft apps are blocked above five paying accounts unless approval is granted. An eligible custom integration staying within that limit can remain draft without requesting marketplace app review.

Those statements answer different questions. Eligibility to build a private integration is one question; the number of connected accounts and need for marketplace review are others. Do not turn “no app review required below the limit” into a promise that every customer or developer can launch any private integration.

Confirm the intended distribution before development. A tool for one landscaping company, an agency tool for multiple clients and a marketplace product have different operating responsibilities. Record the access decision alongside the scope so a successful pilot is not later sold as an approved multi-client product.

Follow the quote all the way to the visit

Illustrative example: Avery approves Q-204 for a seasonal yard cleanup at property P-88. The office creates J-309, then schedules V-410. The report should show each state as it becomes true, rather than labeling the entire chain complete on quote approval.

Jobber’s quote-to-job instructions explain that conversion takes the user to job setup, including timing, team and invoicing. They also note that later quote edits do not automatically update the converted job and that one quote can produce multiple jobs. A report keyed only by quote ID can therefore collapse legitimate work.

Use the business’s reporting grain: one row per job for an unscheduled-work queue, or one row per visit for crew reporting. The customer and property remain context, not substitutes for a job/visit key. Preserve the quote link so the office can trace the approved scope.

1. Open the accepted quote and use Convert to Job; it is the primary action for an approved quote, or available through More Actions.
2. On the job creation page, complete timing, the assigned team and invoicing setup.
3. Save and inspect the job and its visit details. Your office review should confirm the intended property and scheduled window.
4. If work is split into another job, preserve the original quote relationship and the separate job reference.
5. After a later scope change, inspect the job as well as the quote. Conversion does not keep subsequent quote edits synchronized.

Specify what the office exception report should actually show

There are two queues to distinguish: accepted quotes without a verified job, and created jobs without a verified first visit. Use a quote reference for the first and a job reference for the second. Creating a made-up job ID for an approved quote would conceal the very gap you are trying to find.

For the proposed report, an unresolved item remains visible until the office can verify the missing step, close the opportunity or record a deliberate hold. Include the source link and next owner so staff can act from the queue. The report is a view of work to resolve; the dispatcher still owns scheduling in Jobber.

A failed read is not proof that a visit is absent. Use a separate “needs refresh” state when the query did not finish or the necessary permissions are missing. Otherwise a brief outage can flood the unscheduled queue with jobs that are already booked.

A webhook tells you what changed—not the whole record

Jobber’s webhook setup document describes a payload with account and item identifiers rather than the complete object. It calls for the appropriate read scope, signature verification and prompt acknowledgment; it also documents at-least-once delivery and possible repeated events from one user action.

For our proposed report, authenticate the event, preserve it durably, then retrieve the relevant current record in background processing. Match by account plus object ID. Update the existing report entry from the current authoritative state. Do not treat each delivery as a new job to append.

Avoid a permanent “ignore this item ID forever” rule. It would suppress legitimate later changes. Duplicate delivery and a new modification to the same job are different cases. A state-based update can be repeatable while still accepting a changed visit time.

Also plan a reconciliation check appropriate to the business: for example, periodically compare the in-scope open jobs with the report. Label that cadence as your operating choice, not a promise of instantaneous or lossless synchronization. A webhook-only dashboard should not quietly claim completeness after an outage.

A stale report should not look current

The authorization guide describes expiring access tokens, refresh tokens, account association and disconnect handling. A disconnected account is not just another temporary network error. Stop work for that connection and require the appropriate authorization flow before resuming.

For a reporting-first project, request the minimum scopes and keep tokens on the server. If a later phase adds writes, review the scope change and authorization implications. Do not store credentials in the reporting sheet or ship them to the browser.

A healthy-looking chart can be misleading after access is revoked. Include “last successful refresh” and connection state. A stale report should remain available for context but visibly disclose that it is not a current operating view. Test this with the office user who will rely on it, not only the developer.

Price the report and its upkeep separately

The build scope should include account eligibility, field mapping, event handling, reconciliation, visible freshness and reconnect instructions. API-version maintenance and monitoring are ongoing responsibilities. A one-time dashboard fee without an operating owner does not describe the full project.

Use the CRM and spreadsheet ownership guide before allowing the external view to write dates back. If you are comparing platforms, the contractor CRM guide addresses broader fit. For a status-driven production handoff, the JobNimbus native-rule example provides a useful contrast.

Keep the first release read-only if the value is visibility. Add operational writes only when the office can show why they are needed, who approves them and what evidence proves the change reached the correct record.

Use the workflow automation cost guide to compare subscription, usage and maintenance without treating a simple app connection as equivalent to a stateful reporting system.

Before funding a custom report, time the manual check it would replace. An illustrative 30 checks each week at four minutes each totals two hours; it does not prove two hours will be saved. Compare that work with native reporting, an existing app, the custom build and its upkeep. Track unresolved scheduling items and office response time as well as booked work, so the report’s value can be assessed without attributing every approved quote to the integration.

Keep reading