Plumbing AI booking: define the visit before opening the calendar

Before allowing an AI receptionist to reserve time for a plumbing customer, define what the visit promises. An appointment to assess a reported problem, a slot for an already defined service, and a request waiting for a dispatcher are different commitments. The customer-facing wording, calendar record and person reviewing the work should all describe the same one.

This guide is for a plumbing owner or dispatch lead deciding which requests an intake system may book. It provides an original booking-permission worksheet and a demonstration plan. It does not diagnose plumbing faults, establish emergency response, promise repair completion or endorse a vendor. We have not tested these products or measured their call accuracy.

What current products document, and what that leaves to you

ServiceTitan describes AI Virtual Agent as using its customer and scheduling data, business rules and Adaptive Capacity to book against job type, location and required skills. Its current page lists job-type controls, human escalation and call transcripts. This is documented vendor capability, not evidence that your configuration understands every plumbing request.

The same page carries a named testimonial from Superior Plumbing Services and labels its aggregate booking results as early pilot evidence. That supports distinguishing customer reports and a marketed product from an untested concept. It does not establish a repair-completion rate, a local response commitment or a result for your business. We do not use those marketing figures as a forecast.

ServiceTitan's booking documentation, updated October 15, 2026, says Scheduling Pro submissions may arrive as leads or booked jobs depending on setup, and tells staff to verify the details. This is a scheduling workflow, not proof that every connected voice agent produces the same record. Ask the supplier to show the actual destination in your proposed configuration.

The ServiceTitan marketplace listing for Broccoli AI describes API integration, capacity-aware booking onto the dispatch board and onboarding around the contractor's configuration. A marketplace listing is provider/platform evidence, not an independent integration test. Avoca's Inbound page describes appointment booking, customer-record context and passing information to a human CSR during escalation. These are candidates for a demonstration, not interchangeable promises about the work a plumber will perform.

Write the promise before selecting the action

Use plain language to describe the first visit your team is prepared to offer. For an assessment, the promise might be that an appropriate team member will attend within the agreed window to inspect the reported issue and discuss the next step. That wording should not imply that a particular repair, part or final price has already been approved.

For a defined service, write down the scope that makes it bookable without another decision. An owner might approve a particular service category only when location, access, required information and the available team match a maintained rule. This is a proposed management policy, not a determination that any particular plumbing task is suitable for automatic booking.

Keep requests outside that policy in a named review queue. A customer can receive a clear acknowledgement without being given a reserved appointment. If you offer a provisional window, label who must confirm it and what the customer should expect next. Do not use the same confirmation wording for a reviewed booking and an unreviewed request.

A booking-permission worksheet

The following worksheet is our analysis. Complete it with the owner, dispatcher and technicians who receive these records. Use one entry per permitted visit category, rather than one broad rule called plumbing repair.

Visit purpose and exclusions. State whether this entry allows request capture, an assessment appointment or a defined service booking. Describe the promised output of the visit and what is expressly outside it. Keep the internal job-type label beside the customer wording.
Information required before a slot is offered. Identify the service address, contact route, access information and customer-reported details that your team needs. Mark which omissions require a callback. Preserve the distinction between a customer's description and a technician's later findings.
Capacity owner and record. Name the scheduling system, the person maintaining its availability, and which team or skill rules apply. Record the visit duration assumption and who approved it. A free space in a calendar should not be treated as evidence that the right crew can perform the intended work.
Permitted customer commitment. Write the exact meaning of a confirmed window, a requested time and an assessment. List statements the intake system must leave to staff, including uncertain work scope, unapproved pricing or a completion date that depends on inspection.
Exception and fallback owner. Name the person or queue receiving unclear requests, conflicts, unavailable capacity and failed transfers. Specify the follow-up process your business can actually maintain. Escalation in a product description is not evidence that your nominated person will answer.
Evidence and change control. Keep the approved policy version, example destination record, demonstration result and review date. Name who may change the rule and who checks customer-facing messages after a change. Leave unsupported settings unresolved rather than accepting a supplier's default as your policy.

Try the boundary with fictional requests

Prepare a small demonstration set containing an assessment request with incomplete information, a request inside an approved defined-service category, a request outside that category, an unavailable window and a change to an existing appointment. These are proposed test cases, not observations about how the products perform. Use fictional customer information in the initial supplier demonstration.

For each case, write the expected action first. Then inspect what actually appears in the scheduling system. Did it create a lead, a job, an appointment or a follow-up task? Does the customer hear the same promise that the dispatcher sees? Can the reviewer find the original description, unanswered questions and any decision still pending?

Include a case where the handoff recipient is unavailable and one where the scheduling connection cannot confirm availability. The aim is to see the unresolved work and its owner. Do not mark a transfer or booking successful merely because the conversation ended politely. Record an unobserved path as unobserved and ask for another demonstration where it matters.

Do not let a change create a second promise

Ask the supplier to demonstrate a reschedule against the original record. Inspect the old window, the replacement window, the customer message and the work still assigned to staff. A new appointment alongside an unchanged old one leaves two commitments to reconcile.

ServiceTitan's booking guide distinguishes leads, jobs and appointments and describes adding appointments to an existing job. It also calls for reviewing inbound booking details. Use those distinctions to frame your questions; do not infer identical behaviour across a portal, an online scheduler and an AI phone integration.

The same review should cover a request that changes from assessment to quoted work. Name who approves the changed scope and how the later visit is linked to the first record. Keep any customer commitment that still needs a person's decision visible to that person, rather than burying it in a transcript.

Count the work that remains after the call

In a later authorized pilot, review the complete handoff. Record whether required information was captured, which record was created, whether the intended booking boundary held, whether a person corrected it and what callback work remained. Compare the same request categories and operating periods against your existing process. Choose the sample and acceptance limits before interpreting the result; this article supplies no invented threshold.

Keep dispatch review, technician preparation, customer clarification and policy maintenance in the comparison. A higher booking count alone cannot tell you whether those bookings match available staff or the promise the customer heard. The practical outcome is a smaller set of permitted actions that your team can explain, inspect and maintain.

What this review does not establish

These sources describe marketed products and vendor-reported workflows. They do not establish your local telephone availability, language performance, subscription entitlement, service coverage, integration permissions or the conduct of an actual call. Verify those for the proposed package before a live trial. Human staff retain decisions about uncertain scope and requests outside the approved policy.

Use the AI receptionist comparison to shortlist integration routes. Use this worksheet to decide what any shortlisted system is allowed to promise. The two documents answer different questions: how the system connects, and which physical-work commitment the business will accept.

Sources & evidence

Official sources reviewed November 4, 2026. Vendor materials establish descriptions, not independently measured performance. Original evaluation criteria are our analysis.

Editorial status. Published November 4, 2026. This is source review and original analysis, not a hands-on test. Read our selection, corrections, and update policy ↗