{
"icp": "home-services field teams already running on Jobber — HVAC, plumbing, electrical, cleaning, landscaping, pest control, and handyman businesses that dispatch crews from a job board",
"capabilities": {
"availability": {
"headline": "Captures the request as a Jobber Client, books the first Visit on the right crew's calendar, and feeds one unified conversion pipe for your website forms AND your AI Receptionist.",
"lede": "Every caller who lands on the line becomes a Jobber Client with a Property attached and a Request on the dispatcher's board. When the call warrants it, AnyCRM books the first Visit on the routed-to crew member's calendar DURING the conversation. AND the same lead event flows through one unified pipe (same shape, same source attribution, same server-side conversion path used by your website forms) so your dispatch board and your Google / Facebook / LinkedIn Ads both stay in sync.",
"cards": [
{
"num": "A.01",
"title": "Every caller becomes a Jobber Client. Not a missed call.",
"body": "The AI Receptionist captures name, primary email, primary phone, service address, and the work they're asking about. Then AnyCRM writes the Client into Jobber with a Property attached and a first Note. All before the call has ended."
},
{
"num": "A.02",
"title": "Opens a Request on the New Requests board",
"body": "When a caller is still describing the work (\"my AC isn't blowing cold\"), AnyCRM opens a Jobber Request. Not a half-formed Job. The service category, the Property, the urgency, and the call summary all land on the dispatcher's New Requests board where Jobber expects intake-stage records to live."
},
{
"num": "A.03",
"title": "Books the first Visit on the right crew member's calendar. Sends the lead event straight to your CRM.",
"body": "When the caller is ready to schedule, AnyCRM creates a Job (if none exists), schedules a Visit on the routed-to crew member's calendar with the right start/end window, and assigns the right team member. Every contact-create and every Visit-book also sends a lead event into your CRM (with source: \"AI Receptionist Call\" or source: \"AI Receptionist Web\") where YOUR business logic takes over. We set up that receiving flow inside your CRM during onboarding. AnyCRM doesn't get in the way of policy you've already encoded."
}
],
"apiSummary": "The AI Receptionist asks AnyCRM for availability against the people on your crew and gets back open Visit slots in the caller's timezone. Existing scheduled Visits and working hours are always respected. Every AnyCRM call prevents duplicate Clients, creates or links the Property at the service address, opens a Request or a Job depending on call intent, schedules the Visit with the right crew member assigned so the mobile app pings them, AND sends the lead event straight into your CRM tagged with AI Receptionist Call or AI Receptionist Web. The same lead feeds the AnyCRM Conversion Lift pipeline (next capability) so your Google, Facebook, and LinkedIn Ads start optimising against the calls and chats that actually book work.",
"tools": [
"getJobberAvailability",
"createJobberContactAppointment"
],
"curl1Path": "/mcp/tools/getJobberAvailability",
"curl2Path": "/mcp/tools/createJobberContactAppointment",
"pipeIntro": "Most home-services businesses run two completely separate conversion-tracking stacks: one for the website (forms, online-booking widgets, page-load pixels) and a totally absent one for the phone and the AI Receptionist. So Google Ads and Facebook Ads only learn from form-fills, the bidding optimises for the wrong audience, attribution is broken, and analytics double-count or miss the real high-intent phone calls entirely. AnyCRM closes that gap by running BOTH surfaces through a single conversion pipe.",
"pipeStages": [
{
"stage": "1. Capture",
"body": "A lead arrives either through your website form / online-booking widget OR through the AI Receptionist on phone / chat. Either way, AnyCRM produces the same clean lead-event shape, tagged at source with either AI Receptionist Call, AI Receptionist Web, or your website's form identifier. One vocabulary across both surfaces."
},
{
"stage": "2. Deliver to your CRM",
"body": "AnyCRM sends the lead event straight to your CRM, into the receiving flow we wired up for you at onboarding. Your business logic decides what happens next: which Request, which Job, which crew, which territory, which follow-up automation. You don't have to maintain two sets of rules. Web leads and AI Receptionist leads both arrive through the same door."
},
{
"stage": "3. Fire server-side conversion to your ad platforms",
"body": "The same lead event fires server-side into Google Ads, Facebook Ads, and your analytics platform, using the origin of the domain you registered with AnyCRM. Server-side means the conversion can't be blocked by ad-blockers, doesn't degrade under iOS / Safari tracking restrictions, and lands with full attribution context."
},
{
"stage": "4. Optimise, attribute, report",
"body": "Because website conversions AND AI Receptionist conversions flow through the same pipe with the same source taxonomy, your Google Ads bid strategy now optimises against real booked Visits (not just form-fill noise), your Facebook Ads campaigns see the high-intent traffic that picks up the phone after hours, your analytics see a single unified funnel, and attribution stops fragmenting between web and voice."
}
],
"outcomes": [
"Higher ROAS. Ad bidding optimises against actual booked Visits and emergency service calls, not against the noisy subset of leads that happen to fill a form.",
"Lower ad costs. Once Google Ads and Facebook Ads learn what a real home-services lead looks like, they stop spending against lookalikes of low-intent form-fillers.",
"Enriched analytics. Every surface (web form, online-booking widget, phone call, AI Receptionist chat) feeds the same event shape into your analytics, so funnels are complete instead of half-blind.",
"Correct attribution. A homeowner who first saw a Google Ad, then called at 7pm three days later, finally gets attributed end-to-end. Voice traffic stops being invisible to your marketing stack.",
"One source of truth for lead policy. Your CRM's flow owns Request / Job / Visit creation rules. AnyCRM doesn't drift out of date because AnyCRM never tried to own that policy in the first place."
],
"whyThisIsBetter": "Most competitor AI Receptionists try to maintain rules for when a Request becomes a Job, which crew gets assigned, and which source tag to apply. That approach breaks the moment your dispatch rules change, and it ignores the conversion-tracking surface entirely. AnyCRM inverts the responsibility. AnyCRM stays focused on the conversation (capture, dedup, route, book, cancel) and delivers a clean lead event to the two destinations that matter: your CRM (for dispatch logic) and your ad platforms server-side (for conversion optimisation, attribution, and ROAS). This is a custom service baked into the AI Receptionist package. We configure the lead-receiving flow inside your CRM AND the server-side conversion tracking at onboarding, matched to your specific trade, ad mix, and analytics setup.",
"honestAside": "We'll be candid: as far as we can tell, none of our competitors have thought of this yet. They sell AI Receptionists as a phone-answering product. AnyCRM treats the AI Receptionist as one of two equally weighted entries into a unified lead-event pipe, and that's where the real compounding value sits for home-services teams running paid Ads."
},
"adsConversionLift": {
"headline": "Turns every call and chat into a real conversion event your Google, Facebook, and LinkedIn Ads can actually optimise against. So Cost per Lead drops, ROAS goes up, and CAC stops being a guess.",
"lede": "If you run paid Ads for your home-services business on Google, Facebook, or LinkedIn, here is the uncomfortable truth: those platforms only get smarter when they see real conversions. Today, a website form-fill counts. A homeowner with a burst pipe who picked up the phone at 7pm does NOT count. So Google bids harder on the audience that fills forms (often the cheaper, lower-intent one) and ignores the audience that actually calls in an emergency. Cost per Lead looks fine. CAC quietly creeps up. ROAS looks misleading. AnyCRM fixes this. Every call and chat the AI Receptionist handles is sent as a real conversion event to Google Ads, Facebook Ads, AND LinkedIn Ads. The bidding algorithm finally sees what's actually working.",
"cards": [
{
"num": "1b.01",
"title": "Every phone call and every chat becomes a tracked conversion. Not just website form-fills.",
"body": "Today, Google Ads and Facebook Ads probably think your only conversions are website form-fills and online-booking widget submissions. That's why your Cost per Lead looks low but your dispatcher complains the leads are weak. The high-intent traffic (the emergency caller, the same-day service request, the after-hours homeowner) is calling you instead of filling a form, and the Ad platforms have no idea. AnyCRM sends every call and every chat the AI Receptionist handles into your Ad platforms as a real conversion event. Suddenly Google, Facebook, and LinkedIn can see the FULL picture of who is converting from your Ads."
},
{
"num": "1b.02",
"title": "Lower Cost per Lead. Better ROAS. Smaller CAC.",
"body": "Once your Ad platforms can see the phone calls and chats as real conversions, they re-train on a better signal. Bidding shifts toward audiences that actually pick up the phone with a real job, not just the audience that loves filling out forms. In practice this means: Cost per Lead drops because you stop overpaying for low-intent form-fills; Return on Ad Spend goes up because the Ads now find homeowners closer to ready-to-buy; and Customer Acquisition Cost shrinks because more of your Ad budget reaches buyers who will actually book a Visit."
},
{
"num": "1b.03",
"title": "The same pipe carries your website forms too. One source of truth across Ads, CRM, and Analytics.",
"body": "AnyCRM doesn't just track AI Receptionist conversions. It also runs your existing website forms and online-booking widget through the same pipeline. So a lead from a Google Ad that books online AND a lead from a Facebook Ad that called the AI Receptionist three days later both end up tagged, attributed, and counted in exactly the same way. Your Ads platform stops double-counting, your analytics stop fragmenting, and your CRM stops being half-blind to where your work actually comes from."
}
],
"apiSummary": "Every Client-create and every Visit-book fires through AnyCRM's Conversion Lift pipeline. The lead event lands inside your CRM for business logic, AND fires a real conversion event server-side into Google Ads, Facebook Ads, and LinkedIn Ads using the verified origin of your registered domain. Server-side means the conversion can't be blocked by ad-blockers, doesn't degrade on iOS or Safari, and arrives with full attribution context so the Ad platforms' bidding algorithms can re-train on it. Your existing website forms and online-booking widget run through the same pipeline, so Web and Voice conversions feed the SAME training signal.",
"businessImpact": [
"Cost per Lead drops. Because Google, Facebook, and LinkedIn stop wasting your Ad budget on lookalikes of low-intent form-fillers, and start finding the homeowners that actually call.",
"Return on Ad Spend (ROAS) goes up. Because the Ads now optimise toward calls that turn into booked Visits, not toward whichever cheap audience generates the most form submissions.",
"Customer Acquisition Cost (CAC) shrinks. Because a higher share of every Ad dollar reaches homeowners ready to schedule work right now.",
"Analytics get a complete funnel. Web bookings and voice leads sit side by side, with the same source taxonomy. You stop seeing \"50% of revenue: unknown source.\"",
"Attribution stops fragmenting. A homeowner who first clicked a Google Ad, then called the AI Receptionist three days later, finally shows up correctly attributed. Today, that homeowner is invisible to your Ads stack.",
"You finally know if Ads are working. Most home-services businesses cannot honestly tell you whether their Google or Facebook spend is profitable. With AnyCRM's Conversion Lift, you can."
],
"plainEnglishExample": "Imagine you spend $5,000/month on Google Ads for HVAC service in your territory. Today, you see 80 form-fills and assume that's the full picture. With AnyCRM running, you'll also see (say) 110 phone calls and 35 web chats the AI Receptionist handled — many of them emergency service calls and same-day Visits — all flowing into Google Ads as real conversions. Suddenly Google sees 225 conversions a month instead of 80. It re-trains on that bigger, better signal. Within weeks, the bidding finds you more of the right kind of homeowner. Same $5,000 spend, more booked Visits, lower Cost per Lead, higher revenue. That is what \"AI Receptionist with AnyCRM\" actually means for the bottom line. Not just \"it answers the phone.\"",
"tools": [
"createOrUpdatesJobberContact",
"createJobberContactAppointment"
]
},
"lifecycle": {
"headline": "Manages the full Visit lifecycle inside Jobber for anyone calling or chatting.",
"lede": "Every \"can we push tomorrow's appointment to Friday?\" or \"actually, cancel that, we got someone else\" lands with the AI Receptionist instead of on the dispatcher's desk. AnyCRM reschedules update the existing Visit in place. Cancellations follow Jobber's idiom. The Visit is marked cancelled with the caller's reason captured on the Job's Notes, instead of deleting the record and erasing the audit trail. The dispatcher sees a freed slot AND why.",
"cards": [
{
"num": "B.01",
"title": "Finds the Visit by email in a single step. No Visit IDs on the call.",
"body": "Homeowners DO NOT quote Visit IDs over the phone. AnyCRM gives the AI Receptionist an easy way to find the soonest upcoming Visit linked to the Client matched on the caller's email or phone. And the AnyCRM response forces the AI Receptionist to be human: it reads back the service description, date, time window, and assigned crew member before changing anything."
},
{
"num": "B.02",
"title": "Reschedules in place. Keeps the Visit record clean.",
"body": "Rescheduling updates the existing Visit in a single confirmation. No cancel-then-rebook round-trip means the Visit history, the Job link, and any line items already attached all stay intact. Failed reschedules leave the original Visit untouched."
},
{
"num": "B.03",
"title": "Cancels without erasing the audit trail",
"body": "When a homeowner cancels, AnyCRM flags the Visit cancelled the Jobber-native way. Then it writes the caller's reason as a Note on the linked Job and Client, instead of deleting the Visit and stripping WHY the slot opened up. The dispatcher sees the freed slot AND the reason in the same view."
}
],
"apiSummary": "AnyCRM's search, reschedule, and cancel all accept just an email. The soonest upcoming Visit linked to the matching Client is resolved inside AnyCRM. No Visit IDs at the AI Receptionist layer.",
"tools": [
"searchJobberAppointments",
"rescheduleJobberAppointment",
"cancelJobberAppointment"
],
"curl1Path": "/mcp/tools/searchJobberAppointments",
"curl2Path": "/mcp/tools/rescheduleJobberAppointment",
"curl3Path": "/mcp/tools/cancelJobberAppointment"
},
"routing": {
"headline": "Routes every caller to the right crew. And respects existing crew assignments instead of randomly reassigning to someone else.",
"lede": "Jobber accounts run on crew members, service categories, and territories. At setup AnyCRM imports your Jobber crew into its database and enriches each crew member with service expertise (HVAC, plumbing, electrical, drain, install, service-call), languages, timezone, territory, and bookable Visit duration per service. The AI Receptionist then routes each caller to the crew who actually handles that service. Existing Client assignments on active Jobs are honoured as the source of truth.",
"cards": [
{
"num": "C.01",
"title": "Routes by service: install vs service-call vs emergency",
"body": "\"My furnace is making a banging noise\" routes to your service technicians. \"I'd like a quote on a new system\" routes to your sales/estimator. \"No heat, it's 10 degrees outside\" routes to whoever is on-call for emergencies. And the Visit duration is set to the emergency window, not the standard service window."
},
{
"num": "C.02",
"title": "Honours existing crew assignments in Jobber",
"body": "If a Client already has an active Job with an assigned crew member, the AI Receptionist doesn't reassign them. New Visits, Notes, and any follow-up Requests all attach to the existing record under the existing crew. The technician who started the job finishes it."
},
{
"num": "C.03",
"title": "Matches fresh inbound callers and chatters to the right crew",
"body": "New homeowners with no existing Jobber Client get matched to a crew member in the right service pool and territory, honouring the criteria you set in AnyCRM for matching a lead to a crew. The AI Receptionist doesn't fight the dispatching rules you already encode."
}
],
"apiSummary": "Crew details live in AnyCRM's database, pulled once from Jobber at setup, enriched with service expertise, languages, timezone, territory, and default Visit duration per service (valuable context for the AI Receptionist that Jobber's user object doesn't carry). At runtime, one read of the crew roster matches caller → service → crew member. New Clients get assigned to the right crew. Existing Clients keep theirs. AnyCRM does NOT cache your Request workflows, your Job templates, or your dispatch automations. That policy stays inside your CRM, where it belongs.",
"tools": [
"listJobberTeamMembers",
"getJobberUserProfile"
],
"curl1Path": "/mcp/tools/listJobberTeamMembers",
"curl2Path": "/mcp/tools/getJobberUserProfile"
}
},
"setup": {
"headline": "Setup in 3 steps. Battle-tested on real Jobber accounts.",
"lede": "You connect Jobber once. AnyCRM imports your crew, your service categories, your territories, and your default Visit durations. AnyCRM also wires up the receiving end inside your CRM so lead events from the AI Receptionist land where your business logic can act on them. Then the AI Receptionist starts capturing inquiries and booking Visits the same afternoon. No middleware. No prompt-engineering by you.",
"steps": [
{
"num": "S.01",
"title": "Connect Jobber (OAuth, 60 seconds)",
"body": "Authorize AnyCRM on your Jobber account via the standard OAuth grant. AnyCRM scopes to the least amount of access needed for the Client + Visit lifecycle. Nothing for invoices, quotes write, payments, or timesheets. You can always revoke access at any time from your Jobber Connected Apps page. Every update to your Jobber is signed with AnyCRM's connected-app credentials so it's easy to track what the AI Receptionist did when you audit."
},
{
"num": "S.02",
"title": "Import the crew. Lock in service categories and Visit durations. Wire up your CRM's lead-receiving flow.",
"body": "AnyCRM imports every active Jobber user as a bookable crew member with service expertise, territory, timezone, and default Visit duration per service. AnyCRM also freezes the service categories so the AI Receptionist can only book services you actually offer, and locks inbound-call source attribution (always AI Receptionist Call or AI Receptionist Web) so reporting stays consistent. During onboarding we set up the receiving flow inside your CRM so the lead events from the AI Receptionist land where your business logic can act on them. AnyCRM does NOT replicate your Request workflows or Job templates. Your CRM decides what happens after a lead is captured. AnyCRM just delivers a clean event."
},
{
"num": "S.03",
"title": "Drop the AI Receptionist on your phone line and your site",
"body": "Forward your business number to the AI Receptionist's number and paste the chat widget into your site. The same AI Receptionist (same crew roster, same Jobber account, same lead-event pipe into your CRM and your ad platforms) answers both voice and web. Live the same afternoon."
}
],
"nativeAlternative": {
"headline": "Why not just use Jobber's own AI Receptionist + Online Booking + Requests form?",
"body": "Jobber's own AI Receptionist (an add-on for the Grow plan, included with Plus) is a real product. It answers calls and texts 24/7, books jobs using your Online Booking form, takes messages, escalates on keywords, and creates follow-up tasks. It's the right starting point if Jobber is the only stack you run paid Ads against and you don't need cross-tool conversion tracking. Where AnyCRM is different: AnyCRM treats the AI Receptionist as one of TWO equally weighted entries into a unified lead-event pipe — the same lead event that fires server-side into Google Ads, Facebook Ads, and LinkedIn Ads using the origin of your registered domain. Jobber's native Receptionist is excellent at the Jobber side of the conversation, but it does not fire server-side conversions into your Ad platforms, doesn't unify web-form and voice conversions on a single source taxonomy, and doesn't expose a customisable receiving flow that runs alongside Jobber for the lead-policy work you might be doing in QuickBooks, in another CRM, or in an analytics warehouse. AnyCRM is the layer that runs in parallel: it picks up the call, asks the right qualifying questions, books the Visit as a native Jobber Visit on the right crew member's calendar, writes a clean Client with the call summary in the first Note, AND sends the same lead event straight into your CRM's downstream business logic plus your ad platforms server-side. So your Jobber dispatch, your analytics, and your Google / Facebook Ads bidding all start optimising on a real conversation, not just on form-fills."
},
"enrichmentSummary": "Every tool the AI Receptionist calls is an opinionated wrapper inside AnyCRM. AnyCRM does the messy work for you. Dedup by primary email then primary phone, Property creation and linking, service-category resolution, Visit duration math, crew assignment, error handling, lead-event delivery into your CRM, and server-side conversion tracking into your ad platforms. All of it happens before the LLM ever sees a response. So the AI Receptionist reasons over clean, AI-aligned payloads instead of raw CRM internals.",
"enrichmentExamples": [
{
"title": "Capturing a new inquiry",
"raw": "Writing a Client straight into Jobber looks simple. But Jobber's data model splits the caller across at least two records: the Client (the person you bill) and the Property (the address you serve). A homeowner with two houses needs one Client and two Properties; a property manager calling about a tenant's unit needs the management company as the Client and the tenant's unit as the Property. A naive Client-create doesn't create the Property — that's a separate operation, and the Property address is geocoder-validated (bad addresses fail). Emails and phone numbers aren't flat strings on the Client; they're structured arrays with a primary flag. And if you want the inquiry to land on the dispatcher's New Requests board, you need a third operation referencing the Client and Property. Nothing in raw Jobber fires a server-side conversion event to your ad platforms, so call-driven and chat-driven leads never get optimised for.",
"mcp": "createOrUpdatesJobberContact accepts name, email, phone, service_address, note, service_category, request_intent, plus the inferred crew member. AnyCRM handles dedup, picks the surviving Client (or creates a new one with properly-shaped email and phone arrays with primary flags set), creates or links the Property at the service address with a geocoder-validated payload, appends the Note, sends the lead event straight into your CRM (with source AI Receptionist Call or AI Receptionist Web), AND fires a server-side conversion event into your ad platforms using the origin of your registered domain. All in one AnyCRM call."
},
{
"title": "Booking the Visit",
"raw": "Scheduling a Visit in Jobber is a two-step dance most integrators get wrong. A Visit cannot exist without a Job. A Job cannot exist without a Client and a Property. Only after the Job exists can you create the Visit with the right start / end window, the right crew assignment, and the right duration for the service. Leave the crew-assignment array empty and the Visit lands on the schedule as unassigned — the crew member's mobile app never pings them. Get the time format wrong and Jobber rejects the input. End-time earlier than start-time silently creates a zero-minute Visit that disappears from the schedule view.",
"mcp": "createJobberContactAppointment takes email, scheduled_datetime (a naive date and time, no offset needed), invitee_timezone, and service_category. AnyCRM resolves the right crew member from the service + territory, creates the Job if none exists, computes the end-time from the service's locked-in Visit duration, converts the naive datetime to the format Jobber's calendar sync requires, assigns the right crew so the mobile app pings them, sends the same lead event straight into your CRM with the booking context, fires the server-side conversion event into your ad platforms, and returns both local and UTC start times in the response."
},
{
"title": "Cancelling with a reason",
"raw": "There is no Visit-cancel mutation in Jobber. To preserve the audit trail, cancellation has to flag the Visit cancelled (not delete it), and the caller's reason has to be written somewhere queryable — Jobber's own best practice is a Note on the linked Job. Doing that cleanly takes several round-trips: read the Visit, write the Note with the reason, then flag the Visit cancelled. None of these are atomic. If the last step succeeds but the Note step doesn't, the dispatcher sees a freed slot with no explanation. Worse: a hard Visit-delete removes the record from the schedule entirely, erasing the audit trail.",
"mcp": "cancelJobberAppointment takes email and reason. AnyCRM resolves the soonest upcoming Visit, writes the reason as a Note on the linked Job and the Client, then flags the Visit cancelled the Jobber-native way. All in one AnyCRM call. No deletion, full audit trail, the cancelled Visit stays queryable in the crew's reporting, and the response contains the cancelled Visit ID and the recorded reason so the AI Receptionist can read it back to the caller."
}
],
"alignmentSummary": "Every AnyCRM tool for Jobber follows the same AI-alignment contract, so the AI Receptionist never has to think about transport:",
"alignment": [
"Naive datetimes in, Jobber-native shape out. The AI Receptionist passes 2026-05-15T11:00:00 and a timezone string. AnyCRM converts it into whatever shape Jobber's Visit schema requires, on both start and end. AnyCRM also computes the end-time from the service's locked-in Visit duration.",
"Email is the identity. Cancel and reschedule never need a Visit ID at the AI Receptionist layer. Email and soonest-upcoming resolves inside AnyCRM.",
"Service category and Visit duration come from setup, not the LLM. The AI Receptionist can't invent a service category. It inherits the categories you configured at setup; Visit duration is locked per service.",
"Existing crew assignments are sacred. If a Client has an active Job with an assigned crew member, AnyCRM preserves it. New Clients only get the matched crew when no Job exists.",
"Cancellation preserves the audit trail. Jobber's idiom for cancelled-but-tracked Visits is honoured so the dispatcher's reporting stays accurate and the audit trail survives. No hard deletes.",
"Every lead event leaves AnyCRM in two places at once. Your CRM gets the lead event so your business logic can run. Your ad platforms get the server-side conversion event so bidding optimises against real bookings. Both happen on the same AnyCRM call. No race conditions, no missing events.",
"Flat, deterministic shapes. Every AnyCRM response has the same top-level keys across every tool, so the AI Receptionist's prompt never grows with edge-case branching.",
"Errors are messages, not codes. An error from Jobber becomes a one-sentence reason the AI Receptionist can repeat to the caller without translation.",
"Idempotent reschedules. If a reschedule fails mid-flight, the original Jobber Visit is preserved. The homeowner never ends up with nothing."
],
"industryLine": "Currently running for HVAC, plumbing, electrical, cleaning, landscaping, pest control, and handyman businesses. Anyone whose dispatch board is in Jobber but whose phone keeps ringing after the office has gone home.",
"teamsSetup": {
"headline": "Multi-crew setup. Crew roster, services & system-prompt assembly",
"body": "If you run more than one crew member on Jobber, AnyCRM imports the crew roster once, you link each crew member to the services they actually cover (install / service-call / emergency / estimate), and AnyCRM bakes the result into the AI Receptionist's system prompt at setup time. Not at runtime. The AI Receptionist doesn't query your crew roster on every call. It already knows who handles what.",
"steps": [
"Crew roster import. AnyCRM imports your Jobber crew members once and writes each one into its database keyed by crm_user_id (with name, role, expertise, timezone, territory).",
"Per-crew services & durations. For each crew member AnyCRM resolves the services they actually book and the Visit duration per service. One call per person, cached.",
"Service visibility. Each service is flagged Public, Private or Ignored. The AI Receptionist only routes to and books on Public services. You toggle this in the AnyCRM dashboard without re-deploying.",
"Lead-event receiving flow inside your CRM. During onboarding we wire up the flow inside your CRM that receives lead events from AnyCRM. That's where your Request and Job creation policy lives. AnyCRM doesn't try to own it.",
"System-prompt assembly. The cached crew roster, services, and territories JSON is prepended to the AI Receptionist's system prompt before the humaniser splits (personality, etiquettes, tone, speech style). So the AI Receptionist reads the crew before it reads its own instructions.",
"Runtime stays minimal. On a live call the AI Receptionist makes at most one availability call and one booking call. Never a crew roster lookup. Updates to crew, services, or territories re-run the cache. The AI Receptionist picks them up on its next deploy."
],
"note": "The end result: the AI Receptionist can match \"my AC is leaking water onto the floor\" → service category HVAC service-call → the on-call HVAC tech in the caller's territory → that tech's calendar availability → a booked Jobber Visit on that tech's schedule with the Client, Property, and Job already in place → a lead event delivered straight into your CRM → a server-side conversion event in your ad platforms. Without a single crew roster query during the call."
}
},
"privacy": {
"headline": "Your Jobber data passes through AnyCRM. It doesn't stick.",
"lede": "AnyCRM processes your Jobber data to answer the call. Then forgets it. The only thing AnyCRM persists is a conversation history ID so the AI Receptionist can recognise a returning caller. Clients, Properties, Requests, Jobs, Visits, Notes. All of it stays in Jobber, owned by your Jobber account.",
"cards": [
{
"kind": "stored",
"label": "What AnyCRM stores",
"body": "Conversation history IDs only. So the AI Receptionist can pick up where it left off if a caller hangs up and rings back. No call audio, no transcripts of Client records, no caller PII."
},
{
"kind": "not-stored",
"label": "What AnyCRM doesn't",
"body": "Caller names, emails, phone numbers, Jobber Client IDs, your crew roster details beyond identifiers, your service categories, your territories, your job history, your invoice data. None of it. AnyCRM reads what it needs, hands it to the LLM, fires the events, and discards the payload."
},
{
"kind": "data-lives",
"label": "Where data lives",
"body": "In your Jobber account and in whatever systems your CRM's flow forwards lead events to. Clients, Properties, Requests, Jobs, Visits, Notes all live in Jobber. Source-attributed (always AI Receptionist Call or AI Receptionist Web), attributed to AnyCRM in the audit log, revocable. AnyCRM does not build a shadow CRM alongside yours."
},
{
"kind": "revoke",
"label": "Revocation",
"body": "Revoke the AnyCRM connected-app OAuth grant from your Jobber Connected Apps page and the AI Receptionist loses access immediately. There is no \"export your data\" step because there is no data to export. It was never AnyCRM's to hold."
}
],
"scopesSummary": "Jobber uses OAuth via its Developer Center. AnyCRM requests only the smallest set required for the Client + Visit capture lifecycle. Nothing for invoices, nothing for payments, nothing for timesheets, nothing for analytics.",
"scopes": [
"Clients (read + write). Read and write Clients, dedup against existing records, set source attribution and append Notes.",
"Properties (read + write). Create or link the Property at the service address with a geocoder-validated payload.",
"Requests (read + write). Open Requests on the New Requests board for intake-stage calls.",
"Jobs and Visits (read + write). Read availability, create the Job when needed, and write Visits on the routed-to crew member's schedule with the right crew assigned.",
"Users (read). Read your crew roster at setup so the AI Receptionist knows who exists and who handles which service.",
"Not requested: invoices, quotes (write), payments, timesheets, expenses, products & services pricing, your other Jobber integrations."
],
"surfaceNote": "Same OAuth grant any Jobber Connected App uses. Just a smaller surface. AnyCRM holds the access and refresh tokens (every write is signed by AnyCRM's connected-app credentials, so each Visit and Client change is attributable to AnyCRM in Jobber's audit log). The LLM never sees the token, and every tool call is logged with the operation name, never the raw payload."
},
"failureModes": [
{
"title": "Duplicate Clients",
"raw": "Jobber has no implicit dedup. You have to search the Client list by email or phone first and decide whether to update the existing record or create a new one. My AI Front Desk runs on a Zapier-style \"Create Client\" action — a single API call that hands the caller's email straight to Jobber. Same homeowner, slightly different casing? Duplicate. Phone-only? Duplicate. Smith.ai (both human and AI tiers) writes the Client after the call through an integration that does a similar single-step create. Goodcall's connector writes the Client through Zapier-style middleware that does the same. Jobber's own AI Receptionist dedups against Jobber's existing Client list using its caller-ID match, which is good for returning callers it can match by phone — but a homeowner who's never been entered as a Client in Jobber, calling from a new number, still creates a fresh record. None of the Zapier-style competitors can do a \"search-then-write\" because their architecture is one call in, one call out.",
"mcp": "AnyCRM does NOT do a one-shot create. AnyCRM first searches Jobber on a normalised lowercased + trimmed email, then on a normalised phone, then decides whether to update the existing Client or create a new one. A returning homeowner lands on the existing record with a new Note on the timeline, never as a duplicate. This costs us an extra API call per Client-create. We do it anyway, because the alternative is the duplicate-Client mess Smith.ai, My AI Front Desk, and Goodcall users live with. We do two checks where Smith.ai/My AI Front Desk/Goodcall do one.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Visits that don't reach the crew member's mobile app",
"raw": "Writing a Visit to Jobber looks like it creates a scheduled appointment. And it does, but only if the crew assignment is populated correctly. Leave it empty and the Visit lands unassigned — the crew member's mobile app never pings them, no one shows up, the homeowner is sitting at home wondering where the technician is. My AI Front Desk's Zapier-style action list doesn't include a \"Create Visit\" action at all (Visit creation requires the full Client → Property → Job hierarchy assembled first, and a Zapier action surface can't orchestrate that transactionally). Smith.ai doesn't write Visits via Jobber's API at all — its native integration uses Jobber's Online Booking link, which means the booking happens through Jobber's own booking widget surface and depends on whatever crew-assignment rules you set there. Goodcall sends call info into Jobber but doesn't book Visits natively; the dispatcher books manually after reviewing the New Requests board.",
"mcp": "AnyCRM does multiple things in one call: looks up the right crew member from the service + territory + roster cache, filters out inactive users, builds the Client → Property → Job hierarchy, then writes the Visit with the crew assignment populated. The Visit lands in Jobber AND on the crew member's mobile app, with the right duration, in one atomic flow. We do five checks where Smith.ai/My AI Front Desk/Goodcall do one (or zero). That's why a Visit booked through AnyCRM never lands unassigned.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Inventing service categories and Visit durations that don't exist in your account",
"raw": "Jobber's service categories are account-level — the actual values differ from account to account. My AI Front Desk's Zapier-style action takes whatever the AI generates and posts it. There is no \"read your account's real service categories first\" step in a Zapier path; it's a single action. So the AI invents \"Air conditioner repair\" when your account only accepts the categories your admin set up, the write fails (or worse, lands as a free-text tag the dispatcher has to retype before booking), and your reporting silently breaks. Goodcall's connector passes service as free text the same way. Smith.ai works from a generic playbook that doesn't match your account's category list. The Zapier-style architecture is one-shot; there is no \"check the account first\" step.",
"mcp": "AnyCRM reads your account's real service categories at setup, in a separate call to Jobber, and bakes them into the AI Receptionist's system prompt as a frozen table along with the Visit duration per service. So when the AI Receptionist captures a lead, it CAN ONLY pick from services that actually exist in your account, and the Visit duration matches the service. This is API calls at setup time that Smith.ai, My AI Front Desk, and Goodcall don't make — and it's the difference between bookings that always succeed and bookings that silently rot your schedule with mis-sized Visits.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Booking the wrong crew member's calendar",
"raw": "Jobber happily accepts any crew member on a Visit assignment, including deactivated users or crew members from another territory whose mobile app isn't even active. My AI Front Desk's Zapier action takes whichever crew name the AI generates — no \"is this person still active?\" check, no \"does this person handle this service in this territory?\" check. So an HVAC service call gets booked on the plumber's calendar, or on an ex-employee's calendar. Goodcall's integration doesn't assign a crew at the booking layer at all — the Request lands on the dispatcher's board unassigned, and the homeowner never gets a crew-confirmed appointment in the moment. Smith.ai's human receptionists rely on the receptionist's memory of who handles what — fine on a Tuesday morning, less reliable on a Friday at 8pm with a relief receptionist.",
"mcp": "AnyCRM does the heavy work in multiple steps: matches the service category and territory from the call's intent, looks up the right crew member from AnyCRM's roster cache, filters out deactivated users, AND checks whether the existing Jobber Job already has an assigned crew. If the existing crew contradicts the inferred service, AnyCRM refuses to overwrite. The AI Receptionist surfaces the conflict so the call respects the crew already on the Job. Smith.ai/My AI Front Desk/Goodcall can't do this because their architecture is one-shot.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Cancelling by deletion instead of by outcome",
"raw": "A hard Visit-delete in Jobber strips the appointment off the schedule entirely. No reason, no cancellation outcome, no audit trace. My AI Front Desk's Zapier-style cancel action (where it exists at all) issues a single delete — the Visit vanishes, the crew member gets no signal of WHY it fell through, and \"Visits booked vs cancelled\" reporting breaks because the Visit no longer exists to be counted. Goodcall doesn't expose Visit lifecycle (reschedule / cancel) on the integration surface — these get handled manually by the dispatcher, not by the AI on the call. Smith.ai receptionists ask the caller why, but the cancellation lands as a Note rather than as a properly flagged-cancelled Visit, so Jobber's reporting doesn't count it correctly.",
"mcp": "AnyCRM's cancellation is multi-step: find the soonest upcoming Visit, capture the caller's reason, write the reason onto the linked Job AND the Client as a Note, then flag the Visit cancelled the Jobber-native way. The Visit stays on the schedule view, queryable in reporting, with the reason attached. Three operations where Smith.ai/My AI Front Desk/Goodcall do one (and usually the wrong one).",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Encoding your Request-and-Job creation policy in the prompt or in middleware",
"raw": "My AI Front Desk ships a hardcoded \"Create Job\" action that fires on every inbound call. There is no \"only create the Job if the caller is actually ready to schedule\" logic — the action is single-step, so every diagnostic call becomes a Job in the default pipeline, clogging your work board with un-quoted records. Worse, the moment you change your Request workflow or add a new Job template, you have to go back into Zapier and rebuild the zap. Goodcall's connector applies whatever default behaviour the underlying integration shipped with — change your dispatch rules, and the connector keeps doing what it did six months ago. Smith.ai's receptionists work from playbooks that drift out of date as your real dispatch policy evolves. Jobber's native AI Receptionist uses your Online Booking and Request form settings — which is the right call when Jobber owns the whole stack, but it means your dispatch policy is encoded in Jobber's own settings UI rather than in a flow you can extend with logic from other systems (QuickBooks, a marketing automation, an analytics warehouse).",
"mcp": "AnyCRM does not encode your Request-and-Job policy at all. AnyCRM sends a clean lead event straight to your CRM, into the receiving flow we wire up for you at onboarding. YOUR flow decides what happens: new Request workflow? Update the flow. New Job template? Update the flow. New source-tag scheme? Update the flow. AnyCRM's behaviour stays consistent because AnyCRM's job stops at the conversation. Smith.ai/My AI Front Desk/Goodcall can't separate these concerns because their architecture forces dispatch policy into either Zapier middleware or a hardcoded action.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Web leads and AI Receptionist leads run on two separate conversion-tracking stacks",
"raw": "Smith.ai, My AI Front Desk, Goodcall, and Jobber's native AI Receptionist all treat phone and chat conversions as separate from web form / online-booking conversions. None of them fire a real conversion event into Google Ads, Facebook Ads, or LinkedIn Ads when the AI Receptionist closes a booked Visit. So your Ad platforms only see the website form-fills, the bidding optimises for that (lower-intent) audience, your Cost per Lead looks deceptively low, ROAS reporting becomes a fiction, and the high-intent emergency caller who picks up the phone at 7pm stays invisible to your Ad stack. Worse, when any of these competitors DO fire tracking, it's client-side — blocked by ad-blockers and degraded under iOS / Safari tracking restrictions.",
"mcp": "AnyCRM runs your website conversions AND your AI Receptionist conversions through the same Conversion Lift pipeline. Same event shape, same source taxonomy, same delivery to your CRM, AND the same server-side conversion event into Google Ads, Facebook Ads, and LinkedIn Ads — using the verified origin of your registered domain. Server-side means it can't be blocked client-side and doesn't degrade on iOS or Safari. The result is what Smith.ai/My AI Front Desk/Goodcall/Jobber's native Receptionist structurally don't deliver: lower Cost per Lead, higher ROAS, smaller CAC, complete analytics funnels, and attribution that doesn't fragment between web and voice.",
"competitorsAffected": ["Smith.ai", "My AI Front Desk", "Goodcall", "Jobber AI Receptionist"]
}
],
"failureModesMeta": {
"headline": "How most AI Receptionists built on Smith.ai, My AI Front Desk, Goodcall, or Jobber's own AI Receptionist fail for HVAC, plumbing, electrical, cleaning, landscaping, pest control, and handyman businesses that use Jobber. And why AnyCRM can't.",
"lede": "Most AI Receptionists fail on Jobber in the same handful of ways. Duplicate Clients, Visits that never ping the crew's mobile app, invented service categories, the wrong crew's calendar, deletions that destroy the audit trail, hardcoded Request-and-Job rules that drift away from your real dispatch policy, and conversion data that never reaches your ad platforms server-side. AnyCRM can't fail in any of these ways, because each failure was solved one layer down inside AnyCRM. And because AnyCRM delegates Request-and-Job creation policy to your CRM's own flow rather than trying to encode it, AND runs web and AI Receptionist conversions through a single unified conversion pipe instead of two disconnected stacks.",
"closer": "The AI Receptionist is honest because AnyCRM doesn't let it lie. And AnyCRM is sophisticated because it doesn't pretend to own policy that belongs inside your CRM, while quietly fixing the conversion-tracking gap nobody else has thought to close."
},
"comparisonTable": {
"headline": "AnyCRM vs Smith.ai, My AI Front Desk, Goodcall on Jobber",
"columns": [
{ "key": "anycrm", "label": "AnyCRM" },
{ "key": "smithai", "label": "Smith.ai" },
{ "key": "myaifrontdesk", "label": "My AI Front Desk" },
{ "key": "goodcall", "label": "Goodcall" }
],
"rows": [
{
"capability": "Live Jobber Visit booked DURING the call on the right crew's calendar",
"anycrm": "Yes. Native Jobber Visit, crew-matched, Property linked, Job in place, mobile app pinged.",
"smithai": "Partial. Books via Jobber's Online Booking link, not the API. Crew assignment depends on Jobber's booking-widget rules.",
"myaifrontdesk": "No. Zapier-style action list doesn't include Visit creation. Logs a Client + Note.",
"goodcall": "No. Stops at Client + Request on the New Requests board. Dispatcher books manually."
},
{
"capability": "Dedup-before-write on email and phone",
"anycrm": "Yes. Always.",
"smithai": "Manual / receptionist-dependent.",
"myaifrontdesk": "No. Single-step create. Same caller, different casing = duplicate.",
"goodcall": "No published guarantee."
},
{
"capability": "Preserves existing crew assignment on returning callers",
"anycrm": "Yes. Existing crew on active Jobs is sacred.",
"smithai": "Implicit, not API-enforced.",
"myaifrontdesk": "No. Can overwrite via Zapier-style \"Update Client.\"",
"goodcall": "Depends on the underlying connector's defaults."
},
{
"capability": "Routes by service category and territory (HVAC / plumbing / electrical / install / emergency)",
"anycrm": "Yes. Service and territory baked into the AnyCRM crew roster at setup.",
"smithai": "Manual, depends on the receptionist.",
"myaifrontdesk": "No.",
"goodcall": "No structural routing on the call. Dispatcher decides."
},
{
"capability": "Service categories and Visit durations frozen from your real Jobber account",
"anycrm": "Yes. Read at setup, baked into the prompt as a frozen table.",
"smithai": "Generic playbook. Not account-enforced.",
"myaifrontdesk": "No. Writes can fail or land as free-text tags.",
"goodcall": "No structural guard."
},
{
"capability": "Cancellation preserves the audit trail (outcome-flagged, not deleted)",
"anycrm": "Yes. Jobber-native cancellation, reason on the Job's Notes.",
"smithai": "Manual. Cancellation lands as a Note, not a flagged outcome.",
"myaifrontdesk": "No. Delete-style action strips the schedule view.",
"goodcall": "Not exposed in published materials. Dispatcher handles cancels."
},
{
"capability": "Reschedule in place (no cancel-then-rebook)",
"anycrm": "Yes.",
"smithai": "Manual.",
"myaifrontdesk": "No.",
"goodcall": "Not exposed in published materials."
},
{
"capability": "Request-and-Job creation policy delegated to YOUR CRM's own flow",
"anycrm": "Yes. Lead event delivered into the receiving flow we wire up at onboarding.",
"smithai": "No. Policy lives in Zapier or in the receptionist's training.",
"myaifrontdesk": "No. Hardcoded \"Create Job\" / \"Create Request\" actions.",
"goodcall": "No. Connector-default behaviour."
},
{
"capability": "Unified conversion pipe: web forms AND AI Receptionist → CRM + ad platforms server-side",
"anycrm": "Yes. Same shape, same source taxonomy, same server-side delivery to your CRM and your ad platforms.",
"smithai": "No. Web and voice run on separate stacks.",
"myaifrontdesk": "No. Web and voice run on separate stacks.",
"goodcall": "No. Web and voice run on separate stacks."
},
{
"capability": "Server-side conversion events sent to Google Ads, Facebook Ads, and analytics (origin = your registered domain)",
"anycrm": "Yes. Every call and chat lead lands server-side.",
"smithai": "No.",
"myaifrontdesk": "No.",
"goodcall": "No."
},
{
"capability": "Source attribution stays consistent across web and voice",
"anycrm": "Yes. AI Receptionist Call, AI Receptionist Web, plus your web form identifiers.",
"smithai": "Manual / inconsistent.",
"myaifrontdesk": "No standardised taxonomy.",
"goodcall": "Whatever the underlying connector defaults to."
},
{
"capability": "Scale ceiling",
"anycrm": "Bounded by Jobber API limits, not by staffing.",
"smithai": "Bounded by human receptionist staffing (AI tier mitigates but doesn't remove the ceiling).",
"myaifrontdesk": "Bounded by Zapier-style rate limits and action contracts.",
"goodcall": "Bounded by the manual-dispatch hop after intake."
}
],
"footer": "Every row in this table is solved one layer down inside AnyCRM. Not in the prompt. Not by humans. Not by Zapier-style middleware."
},
"faqs": [
{
"q": "Does this actually work with my Jobber account?",
"a": "Yes. AnyCRM uses Jobber's official API via a standard OAuth grant. Every captured caller lands as a Client with a Property at the service address and a first Note from the call. Booked appointments land as native Jobber Visits on the right crew member's calendar, with the Job already created so the Visit shows on the dispatcher's board and pings the crew member's mobile app."
},
{
"q": "How is this different from Jobber's own AI Receptionist?",
"a": "Jobber's native AI Receptionist is a real product — it answers calls and texts, books jobs through your Online Booking form, takes messages, escalates on keywords, and creates follow-up tasks. It's the right starting point if Jobber is your entire stack. AnyCRM is different in one specific way: it treats the AI Receptionist as one of two equally weighted entries into a unified lead-event pipe that ALSO fires server-side conversion events into Google Ads, Facebook Ads, and LinkedIn Ads using the origin of your registered domain. That means your paid Ads bidding finally optimises against real booked Visits and emergency service calls, not just website form-fills. Jobber's native Receptionist doesn't do that. If you're running paid Ads and Cost per Lead / ROAS / CAC matter to you, AnyCRM is the layer that closes the conversion-tracking gap."
},
{
"q": "Will it create duplicate Clients in Jobber?",
"a": "No. AnyCRM resolves the existing Client first (normalising email and phone) before writing. A returning homeowner becomes a new Note on the existing record, never a second Client, and the existing crew assignment on any active Job is preserved."
},
{
"q": "Can it route different inquiries to different crew on my team?",
"a": "Yes. AnyCRM reads your Jobber crew roster once at setup. Every active crew member, with their service expertise (HVAC / plumbing / electrical / etc.), territory, and default Visit duration per service. Service calls, install quotes, and emergencies each route differently, and existing crew assignments on active Jobs in Jobber are always preserved."
},
{
"q": "Where do the appointments actually live, calendar or Jobber?",
"a": "In Jobber, as native Visits. The Visit is created with the right start and end window, the right crew assigned, and the right Job in place. Which means it shows on the crew member's mobile app, on the dispatcher's schedule view, and on the Client's record exactly the way Jobber expects."
},
{
"q": "Can it cancel or reschedule a Visit from a phone call?",
"a": "Yes. The caller gives their email, AnyCRM finds the soonest upcoming Visit linked to the matching Client, the AI Receptionist reads it back, and AnyCRM either reschedules in place or flags the Visit cancelled the Jobber-native way (with the reason captured as a Note on the linked Job and Client). Never a hard delete that would strip the audit trail."
},
{
"q": "What if a caller has two upcoming Visits in Jobber?",
"a": "AnyCRM returns every upcoming Visit for that Client (service, date, time window, assigned crew) and the AI Receptionist asks which one to change before doing anything. It never assumes."
},
{
"q": "Does it handle timezones correctly?",
"a": "Yes. The AI Receptionist confirms the caller's country/timezone, AnyCRM converts the Visit time into the format Jobber expects, and the AI Receptionist reads the time window back to the caller in their local timezone. No customer-facing UTC strings, no off-by-an-hour confirmations on a 9-to-11 window."
},
{
"q": "Does it create Requests or Jobs?",
"a": "Not directly as a hardcoded action. AnyCRM stays focused on the conversation surface: capturing the Client, matching the right crew, booking the Visit when intent warrants. Request-and-Job creation is YOUR business policy, and that policy lives inside your CRM, in the receiving flow we wire up for you at onboarding. Every Client-create and every Visit-book in AnyCRM sends a lead event straight into that flow (tagged with source AI Receptionist Call or AI Receptionist Web). Your flow decides which Request workflow, which Job template, which source tag, which dispatch automation. AnyCRM doesn't try to encode policy that will drift the moment your business changes."
},
{
"q": "How does the conversion tracking work?",
"a": "Every lead event AnyCRM produces (from a phone call, a chat conversation, OR a website form / online-booking widget) flows through a single conversion pipe. It lands in your CRM for business logic. AND it fires server-side into Google Ads, Facebook Ads, and your analytics platform, using the origin of the domain you registered with AnyCRM. Server-side means the conversion can't be blocked by ad-blockers and doesn't degrade under iOS / Safari tracking restrictions. The result: higher ROAS, lower ad costs, enriched analytics, and attribution that doesn't fragment between web and voice. As far as we can tell, none of our competitors have built this yet."
},
{
"q": "What about my existing website forms? Do they go through the same pipe?",
"a": "Yes — that's the whole point. Web forms / online-booking widget AND the AI Receptionist produce the same lead-event shape with the same source taxonomy. They land in the same place in your CRM, and they fire the same server-side conversion event into your ad platforms. So your bid strategy optimises against unified, real conversions instead of fragmenting across web-only and voice-only stacks."
},
{
"q": "How long until it's actually capturing inquiries into Jobber?",
"a": "Most teams are live the same afternoon. The OAuth grant takes a minute. The crew roster, service-category, and Visit-duration import is automatic. We wire up the lead-receiving flow inside your CRM during onboarding. The phone integration is usually under an hour. Web chat is faster."
}
]
}