Probook AI: a practical guide for home services operators

What is Probook?

A home-services front office does more than answer the phone. Every new request has to become the right job, in the right time window, with the right technician, while existing customers receive updates and open capacity gets filled. When calls, booking rules, and dispatch live in separate workflows, even a captured lead can stall at the handoff to the board.

Probook’s answer is to make dispatch the organizing layer. It describes itself as an “AI operating system” for home services built around dispatch, with lead capture, booking checks, outbound work, customer communication, and technician assignment connected to the same operating flow. The point of that dispatch-led model is that the platform can consider what happens after a conversation: the job context, available capacity, and technician fit that determine whether a booking becomes a productive service call.

The practical thesis is straightforward: evaluate Probook as a front-office and dispatch redesign, not just as an AI receptionist. It is strongest when a contractor wants to reduce manual movement between CSRs and dispatchers, centralize work across locations, and let staff manage exceptions while software handles more of the routine path. If the project is narrower or dispatch should remain largely unchanged, that breadth may be more than the business needs.

What Probook does

Probook’s daily workflow starts before a job reaches the board and continues after it is booked. Inbound voice covers front-line, after-hours, and overflow calls. Speed-to-lead responds to web and aggregator inquiries, while webchat can book customers from the website. Probook then says it checks equipment age, job data, and business logic before a booking is placed.

Once demand reaches the schedule, Probook applies historical data to technician matching and reshuffles the board in real time. Customer updates and chat replies extend that workflow through the service day. When the board needs more work, outbound automation can pursue member visits, targeted promotions, and unsold estimates.

The public platform page specifically names voice, web and aggregator leads, and webchat. It does not specifically list SMS or email as customer conversation channels, so buyers that need those channels should have Probook demonstrate the complete inbound, outbound, handoff, and recordkeeping flow.

Who is Probook for?

Probook is aimed at residential contractors with enough dispatch complexity for these connections to matter. Its featured customer stories center on multi-location HVAC, plumbing, and electrical businesses managing large field teams. The company also says it serves independent shops, but it does not publish a minimum technician count, location count, or call volume.

The clearest operating fit is a business centralizing dispatch, integrating acquired locations, covering after-hours or overflow calls, or trying to fill member visits and unsold estimates in step with board capacity. Operations, call-center, and dispatch leaders should evaluate the system together because success changes all three functions. In the model Probook describes, staff spend less time placing every job and updating every customer, and more time handling exceptions, supporting technicians, or debriefing completed work.

That shift requires more than installing a phone agent. Location rules, technician strengths, job priorities, membership logic, service areas, and escalation ownership must be clear enough to configure. A small shop seeking only basic after-hours answering may not receive the same value from a dispatch-centered rollout.

How Probook connects to your stack

Probook does not publish a named ERP or integration catalog. Its privacy policy says the platform may access data authorized through an ERP API, and it specifically describes Google Local Services Ads access for aggregating leads, displaying lead details, and messaging prospects. It also says some data may flow back to an ERP to maintain integration functionality. Those statements establish that integrations are part of the product, but not that a particular ERP edition, object, field, or writeback is supported.

Before the operating design is final, Probook should map the record created at every step: how a caller is matched to a customer, which equipment and job-history fields are read, how availability is determined, what is written to the board, and what happens when an API is slow or unavailable. Multi-location teams should also confirm how business units, permissions, shared customers, service areas, and reporting roll up.

On data practices, Probook says it does not sell personal information and does not use ERP or Google user data for advertising or unrelated purposes. It says Google user data is not used to train generalized AI or machine-learning models unless explicitly permitted and disclosed. The public policy describes reasonable safeguards, retention, and revocation, but does not name security certifications, data-residency terms, or an uptime commitment. Request the current security and contractual documentation that applies to the proposed deployment.

Pricing and deployment

Probook does not publish pricing. A useful quote should separate the platform and modules from implementation, locations, users, phone or message usage, support, overages, and any minimum commitment. It should also define renewal increases, termination rights, data export, and the cost of adding acquired locations or higher seasonal volume.

The platform page reports 41 days as the average time to full deployment, while Probook says it deploys in person and configures alongside the customer’s team. Its Peterman Brothers story describes several days on site learning the business and mapping products across business units and complex rules. Ask what “full deployment” means for the proposed modules, which preparation belongs to each team, and what acceptance criteria mark the handoff from implementation to ongoing operations.

Ownership after launch matters as much as launch speed. Name who can change booking and dispatch logic, how changes are tested, which exceptions remain human-owned, and how support responds during peak periods. Those responsibilities affect the real staffing and cost model even when the software handles most routine interactions.

Why it matters for operations

Probook’s customer stories show why dispatch can be a higher-leverage starting point than call answering alone. A captured call still needs a clean booking and a field assignment; an open slot still needs demand; and a board change often creates another customer update. Connecting those decisions can reduce repetitive coordination while giving the remaining front-office team more time for work that requires judgment.

The other published outcomes reinforce the connection between call handling and dispatch. In Probook’s Cardinal story, the after-hours and overflow AI CSR booked more than 850 jobs and generated over $715,000 in four months at an 82% true booking rate. The same story reports a greater than 20% year-over-year rise in average ticket across trades during Cardinal’s first six months using Probook. Peterman Brothers reports that about 95% of its dispatch decisions run through Probook, while 414 inbound jobs in one cited month were booked end to end without a human.

These are individual customer accounts published by Probook, not guaranteed outcomes. Business mix, seasonality, staffing changes, acquired locations, and implementation quality can all affect the result. Their best use is to set hypotheses for a pilot: dispatcher workload, booking quality, schedule use, customer containment, average ticket, and front-office capacity.

What to confirm before you buy

Start with product boundaries. Confirm which Probook modules are in the proposal and whether voice CSR, speed-to-lead, webchat, booking checks, outbound campaigns, customer communication, and dispatch optimization can be purchased or deployed independently. If SMS, email, payments, multiple languages, or a particular lead marketplace is required, put that entitlement and workflow in the order form rather than inferring it from a broader product description.

Then define the safety net. Probook should demonstrate transfers, emergencies, cancellations, customer disputes, duplicate records, low-confidence assignments, capacity limits, and an ERP outage. The operating plan should show when a person takes over, what context they receive, how the board is corrected, and how missed work is reconciled after recovery.

Finally, align the commercial and governance terms with the workflow. Agree on definitions for booking rate, containment, dispatch automation, and attributed revenue. Document support hours, severity targets, data retention and deletion, subprocessors, incident handling, release notice, and rollback assistance. That makes the eventual result easier to manage and compare with the customer outcomes Probook publishes.

Where Probook fits

Probook deserves a close look when technician assignment and board performance are at the center of the project. That includes a regional operator consolidating several dispatch teams, a home-services platform absorbing new locations, or a large call center that needs inbound and outbound work to respond to field capacity. The stronger the relationship between demand, job value, technician fit, and schedule changes, the more relevant its dispatch-led design becomes.

It is a less obvious first step when the business only needs after-hours coverage, cannot commit operations and dispatch leaders to implementation, or must select from a pre-approved ERP and security catalog before a sales process begins. Those constraints matter because Probook’s broad operating scope depends on deeper process alignment, while its integration and security details are not fully available online.

How to evaluate Probook

Build the evaluation around one full service day, not a staged call. Send representative front-line, after-hours, web, and aggregator leads through the system. Include a membership, old equipment, an emergency, a cancellation, a caller outside the service area, a full board, and a failed transfer. Follow each interaction through customer matching, booking cleanup, technician assignment, customer updates, and the final ERP record.

Dispatchers should review why a technician was selected, how a board change affects later jobs, which decisions they can override, and how the audit trail appears. CSRs should score booking accuracy, transfer context, and correction effort. Operations leaders should measure schedule utilization, booked jobs, abandonments, containment, overrides, complaints, average ticket, and the staffing needed for exceptions.

Set the baseline and success thresholds before the pilot starts. A phased rollout by location or workflow makes it easier to compare against the prior process and gives the team a clear rollback path. References are most useful when they resemble your trade mix, call volume, technician count, ERP, and centralization plan.

Where Broccoli fits relative to Probook

Broccoli gives home-services operators an all-in-one lead-management platform built for the trades. It spans inbound and outbound voice and SMS, AI chat, speed-to-lead response for sources such as Google LSA, Yelp, Angi, Thumbtack, and Meta, booking and emergency dispatch, estimate and membership follow-up, appointment reminders, QA and CSR coaching, and multi-location reporting. That makes Broccoli a compelling choice when the goal is to manage the lead lifecycle from first contact through booked work, follow-up, and conversion accountability in one operating view.

The concrete distinction is dispatch depth. Probook explicitly centers historical-data-based technician matching and real-time board reshuffling, so it should lead the evaluation when board-wide optimization is the project. Probook’s public pages do not name supported ERPs or specifically list SMS, while Broccoli names ServiceTitan, Housecall Pro, AccuLynx, Salesforce, and Sera and presents inbound and outbound SMS as core channels. Broccoli shows direct booking, on-call technician assignment, and manager escalation, but does not describe board-wide optimization at the same depth as Probook. Test the level of dispatch control your operation actually needs.

Read the Probook vs. Broccoli guide for a focused comparison. If lead conversion, follow-up, and front-office visibility are the immediate priorities, book a Broccoli demo and bring the calls, dispatch rules, lead sources, and location structure you want the platform to run.

Bottom line

Choose Probook when dispatch is the transformation: technician matching, real-time board changes, booking cleanup, customer updates, and schedule-filling work need to operate as one loop. Its customer stories make a credible case for large, multi-location teams, but ERP fit, commercial terms, security documentation, and deployment ownership still need direct validation.

Choose Broccoli when you want an all-in-one trades lead-management platform to capture and convert demand across voice, SMS, chat, speed-to-lead, booking, outbound follow-up, QA, coaching, and multi-location reporting. Book a Broccoli demo to see that lifecycle run against your actual customer conversations and operating rules.

Sources

1. Probook homepage — Company positioning and high-level workflow
2. Probook platform — Capabilities, channels, platform metrics, and deployment timeframe
3. A Letter to the Operator — Company history, market focus, and deployment context
4. Probook privacy policy — ERP and Google data access, retention, sharing, and safeguards
5. Del-Air customer outcome — Dispatch consolidation and inbound-call results
6. Cardinal customer outcome — AI CSR bookings, true booking rate, and dispatch results
7. Peterman Brothers customer outcome — Centralized dispatch and no-human booking results