Chat qualification and booking for multi-location owner-led services

TaskChad sells the $250 Business Diagnostic Session and the $2,000 14-Day Implementation Sprint described on this page. This is provider-written implementation guidance from TaskChad's own product team, not independent research, a franchise-industry benchmark, or a customer case study. The path below is a scoping hypothesis until a real multi-location operator pays for a Session, accepts a scope, and TaskChad has terminal evidence for the result.

The expensive problem inside a chat that doesn't know which branch it's talking about

An owner running six gym locations under one brand, a four-site med-spa group, a cleaning company covering a dozen territories, or a multi-shop auto-detailing chain usually has one website and one chat widget, wired to a single knowledge base that describes the business as if it operated out of one address. A visitor opens that chat from a corporate homepage, a location-specific landing page, or a paid-search ad for one branch, and types something location-dependent: "do you have anything open this week at the one on Route 9," "is my membership good at a different branch," "what does a deep clean cost near me." The chat has to decide which physical location that message belongs to before it can say anything true, and most widgets were never built to make that decision correctly.

The failure is not that the chat answers rudely. It answers confidently, using whichever location happens to be hard-coded into the script, whatever the visitor typed, or whatever page the widget was embedded on that day — none of which is guaranteed to match. A caller who says "the one on Route 9" might mean a cross street shared by two branches in different towns. A visitor lands on a location's page from an old bookmark or a syndicated listing after that location closed or moved. A member asks about "my location" and the chat, with no membership lookup behind it, quietly assumes whichever branch hosts the widget instance is correct. Each of these produces the same downstream failure: a confirmed appointment gets written to the wrong branch's calendar, at a location that cannot actually deliver the requested service, or under the wrong person's account.

This lane measures a narrower event than "make the chat smarter." It measures whether a visitor with a real booking, account, or availability question left the conversation with a confirmed appointment at the correct branch — never a name captured with no location attached, and never a slot offered at a branch the roster cannot verify.

What "one source-grounded inquiry-to-booking path" means for a multi-branch chat

This lane builds one thing: a single source-grounded inquiry-to-booking path, scoped to one inquiry type across the operator's branches, not a rebuild of every conversation the chat could ever have. Source-grounded means every factual claim — an address, a set of hours, a service menu item, an open slot — traces to content synced from the location roster or each branch's own booking system, never to a model's general assumption about what a similar branch "usually" offers. Inquiry-to-booking means one acceptable ending: a confirmed appointment, class reservation, or callback written into the correct branch's system of record. A captured lead with no branch attached is not a booking.

The realistic candidate list is short, and each one already has a de facto owner today, even if that owner is inconsistent:

Visitor message and location signal	Current owner today	Booking destination	Blocking exception
New prospect names a location informally ("the one by the mall") and wants to book	Front desk or call center at whichever branch answers	Appointment at the correctly resolved branch	No canonical roster check confirms the named branch is real, current, and offers the requested service
Visitor arrives on a specific branch's landing page and books from there	The branch whose page hosts the widget, assumed by default	Appointment at that branch's calendar	Page context is trusted as the destination with no cross-check against the visitor's actual request or membership record
Existing member or customer asks about "my location" without naming one	Whichever staff member picks up the chat	Account lookup and appointment at the member's home branch	No membership or account lookup ties the visitor to a specific branch before a reply is sent
Visitor wants whichever branch has the soonest opening, regardless of which one	Front desk, checked branch by branch, manually	Appointment at the first available branch meeting a distance or service constraint	No shared, real-time view across branch calendars; availability is checked one call at a time
Franchise, vendor, or out-of-territory service inquiry	Owner or operations lead, ad hoc	Routed to a person, not booked	Not a booking scenario; requires a judgment call the chat should not make

Baseline and the KPI that decides whether this worked

Before any build starts, TaskChad writes down the baseline using evidence the operator can already produce: how many chat conversations opened across all locations in a defined window, how many contained a genuine booking-relevant request, and how many of those already had a location, stated or inferable, before the conversation ended.

A conversation counts as qualified only when three conditions hold. The message was a real booking-relevant inquiry, not a vendor pitch or a question the FAQ page already answers. The branch was resolved through a check against the location roster, not accepted at face value from a single unverified signal such as a caller's phrase or the page the widget happened to sit on. The requested service was confirmed as actually offered at that resolved branch before a slot was ever presented. Conversations failing any of those three route to a person and do not count toward the KPI denominator.

The KPI is qualified conversations reaching a confirmed next step, measured as a rate over a stated window. It is a booking-completeness metric, not a service-delivery or revenue metric — it tracks whether a request ended in a calendar hold at the correct branch, not whether the underlying appointment went well.

Signal	Source of truth
Chat opened with a booking-relevant message	Chat platform transcript log
Branch resolved and confirmed	Canonical location roster, matched against stated location, page context, or address
Service availability at that branch confirmed	Branch-specific service menu synced from the booking or CRM system
Slot checked before it was offered	Branch calendar or shared scheduling system, checked in real time
Booking or handoff confirmed	Branch's booking system, CRM, or vendor-scheduling tool, with a required branch identifier

No improvement percentage gets published before that baseline is dated and written. A chat that sent a location a lead notification is not the same as one that booked a confirmed, branch-verified appointment.

Why the chat cannot decide on its own which branch owns a booking

Whichever inquiry type the Session ranks first to build, one rule does not move: the branch a booking belongs to is resolved by the server against the canonical location roster, never accepted at face value from whatever a visitor typed, whatever page hosted the widget, or whatever a script last hard-coded. This mirrors how the CRM platforms multi-branch operators already run are documented to work. Salesforce's REST API reference for the Assignment Rule Header describes this mechanism directly for a Lead, Case, or Account: a client request carries a header telling the server whether to apply the org's active assignment rules, and when that header is omitted the default is to apply them anyway — the server evaluates the assignment against its own criteria, not a value the client submitted (Salesforce Developers — Assignment Rule Header, REST API Developer Guide).

The same discipline holds independent of any single CRM vendor. OWASP's Authorization Cheat Sheet states that access and destination decisions must be enforced server-side, because any client-supplied value — a caller's stated branch, a page's default location, a cached widget setting — can be wrong, stale, or manipulated before it reaches the system of record (OWASP Cheat Sheet Series — Authorization Cheat Sheet). Applied to this cell, a visitor's stated or inferred location is a hint the chat can use to narrow a search; it is never the final booking destination. Whichever inquiry type gets built first, its design has to resolve branch ownership against the roster on the server, and route anything ambiguous to a person rather than guessing.

Where a human has to confirm the facts before anything ships

Three roles carry standing approval authority on every TaskChad Sprint: a scope owner who decides what gets built, a data owner who confirms which system is authoritative, and an executive sponsor accountable for the outcome. A fourth role sits beside them here: the location roster owner, the operations lead, franchise manager, or owner who maintains the current list of active branches, addresses, hours, and service menus, and who confirms that list is accurate before the chat is allowed to read from it.

A second, separate approval covers pricing and promotions. Many multi-location, owner-led businesses set pricing or run promotions independently by branch or franchisee. The chat's grounding rule already blocks it from inventing a price or package it cannot source, but the specific person who confirms each branch's current pricing feed stays named in the brief, because a stale or shared price list across branches produces the same wrong-answer risk as a stale location roster.

A third boundary is a disclosure requirement, not a judgment call. California's B.O.T. Act makes it unlawful to use a bot to communicate with a person online with the intent to mislead them about its artificial identity, for the purpose of incentivizing a sale in a commercial transaction; a person using a bot avoids liability under the statute by disclosing, clearly and conspicuously, that it is a bot (Cal. Bus. & Prof. Code § 17941). A chat that qualifies and books across several branches is squarely the kind of commercial, sales-directed interaction the statute describes, and a public website is reachable from California regardless of where an operator's branches physically sit — so Open is the state where that disclosure has to happen, every time, at every branch's chat instance, not just the one an operator happens to review.

The eight-state path from an open chat to a confirmed, branch-verified booking

A chat meant to resolve a branch and stop at multiple checkpoints needs named states, not good intentions:

State	What happens	Evidence required
Open	Source page, channel, and timestamp captured; bot identity disclosed	Logged event with source, timestamp, and disclosure flag
Identify	The request type is classified: new booking, account or membership question, cross-branch transfer, or out-of-scope inquiry	Request-type flag attached to the record
Locate	The branch is resolved against the canonical roster, using the visitor's stated location, page context, or address as inputs, never any one alone	Branch match logged against the roster, with the signals used
Ground	Informational replies pull only from that resolved branch's synced hours, address, and service menu	Reply linked to a branch-specific source entry
Qualify	The requested service is confirmed as offered at the resolved branch, and any membership or account fit is checked	Eligible, not-eligible, or escalate flag
Check availability	The resolved branch's calendar, and any shared resource, is checked live before a slot is offered	Availability check logged with a timestamp
Offer	A specific slot at the confirmed branch is presented and selected	Slot logged with date, time, branch identifier, and destination system
Confirm or escalate	The booking is written to the branch's system of record with a required branch field, or the visitor is handed to a person	Disposition recorded

No state lets the chat self-approve a branch match it cannot verify against the roster, and Check availability sits after Locate and before Offer, so a slot is never presented at a branch that turns out to be the wrong one.

Failure tests the path must survive before launch

A path is accepted because TaskChad tried to break it and watched it fail safely:

• Stated location trusted without a roster check. A visitor names a location informally, and the chat books there without confirming it is an active branch offering that service. Escalates to a person instead of guessing which branch was meant.
• Wrong branch from page context alone. A widget embedded on one branch's page books at a different branch because of a copy-paste configuration error or a hard-coded branch ID. Locate has to confirm the page's stated branch against the roster, not trust it silently.
• Double-booked slot across branches. A shared resource, such as one technician or instructor covering two nearby branches, gets booked twice because each branch's calendar was checked in isolation. Check availability has to see the shared resource, not just one branch's calendar.
• Closed or relocated branch offered. The chat offers a slot at a location that has closed, moved, or not yet opened, because the roster used to build Locate was out of date. This is treated as a roster failure, not a chat failure, and routes back to the roster owner.
• Service not offered at the resolved branch. A slot gets booked for a treatment, class, or service the confirmed branch does not actually provide, because Qualify never checked the branch-specific menu before Offer.
• Cross-branch account exposure. A member's account lookup at one branch surfaces membership, payment, or history data tied to a different branch. The field map has to be scoped per branch before launch.

Each test has to produce a visible failure state, an untouched source record, and a named next action. Silence is not an acceptable outcome for any of them.

The 14-day Sprint scope for this multi-location cell

Once the Session names the accepted path, the $2,000 14-Day Implementation Sprint builds it inside a fixed 14-day window.

Days	Phase	What happens
1–3	Preflight and baseline	Confirm the location roster's owner and current state, each branch's booking or calendar system, and baseline chat-open and booking counts by inquiry type
4–7	Build	Implement the one chosen inquiry-to-booking path end to end, using the systems in the agreed scope
8–11	Failure and approval tests	Run the six tests above, plus the roster-confirmation and bot-disclosure checks named during the Session
12–14	Release and handoff	Ship with a safe-disable switch, an operator runbook, the baseline receipt, and the KPI observation window

For this technical example, the working scope is one inquiry-to-booking path, one branch-resolution rule, at most two connected systems, one KPI, one owner, one release, one acceptance decision. A full booking-platform migration across every branch, standardizing all locations onto one calendar system, franchise-wide pricing changes, and any workflow letting AI approve a cross-branch membership transfer or invent a branch's price sit outside this technical example. When a real request exceeds that boundary, TaskChad narrows scope or declines rather than absorbing unpriced work into a fixed fee. The purchased Sprint is scoped to the agreed business result, which may address one big problem or several connected problems.

Fit conditions and wait conditions

This Session fits an operator already running at least two active branches under one brand, with a public-facing chat widget in place or committed to launching one, a booking or scheduling system per branch (shared or separate) that can be checked in real time, a person willing to be named location roster owner within about a week, and chat volume across branches high enough for a confirmed-next-step rate to mean something over a short window.

Waiting is right in a few cases. If the location roster itself is inconsistent — different branch lists depending on who you ask, or addresses and hours that are not centrally maintained — building that canonical list becomes the Session's first recommended output, not something the chat can be trusted to read from yet. If no branch has any real-time calendar or scheduling system, Check availability has nothing to check against, and that gap closes before a build starts. And if the actual request is for AI to set independent branch pricing, approve a cross-branch membership transfer, or resolve a franchise territory dispute, that sits outside every offer on this page; the Session names that boundary rather than delivering around it.

Terminal evidence: what "booked" is allowed to mean

A chat transcript with a location mentioned in it is not booked. A lead notification sent to a branch's inbox is not booked. A promised callback with no calendar hold is not booked. The only terminal evidence this cell recognizes is a disposition logged in the resolved branch's own booking system, CRM, or scheduling tool — a confirmed appointment, class reservation, or vendor slot, carrying a required branch identifier, tied to the original chat session, inside the agreed observation window against the dated baseline. A completed chat with a branch confirmed is a leading indicator that can justify continued work, not a claim of value on its own; publishing a booking-rate improvement before that baseline exists is the kind of unsubstantiated AI claim the FTC's guidance on AI marketing claims warns against, and separately, the FTC has flagged that chat-based tools built to appear more human or more authoritative than they are can cross into deceptive territory on their own, independent of any specific claim made about results (Federal Trade Commission, "Chatbots, deepfakes, and voice clones: AI deception for sale").

The three demonstrations and the Revenue Leak Score

TaskChad publishes three controlled demonstrations. The lead-to-booking demonstration shows the same capture, qualification, approval, and receipt sequence this path uses, applied from a different starting channel and a single-location context. The AI Workflow Audit demonstration shows how a candidate list like the five inquiry scenarios above gets scored for grounding risk and branch-resolution exposure before a Sprint is recommended. The SEO and GEO improvement loop demonstration is not part of this lane's build, but shows how TaskChad treats a measurement claim generally, which matters when an operator is comparing performance across branches.

Before booking a Session, an operator can run the Revenue Leak Score, a short directional diagnostic covering visibility, trust, capture, response, follow-up, and owner dependency. It is not a revenue forecast or a guarantee — a reasonable starting point for deciding whether a misrouted chat, an unmaintained location roster, or a manually checked calendar is the biggest leak across the portfolio.

Questions multi-location operators ask before booking

Does the chat ever guess which of our locations a visitor means?

No. Locate resolves every request against the canonical location roster using the visitor's stated location, the page they arrived from, or an address as inputs — never any single one of those signals accepted at face value. If the roster cannot confirm a match, the conversation routes to a person instead of guessing, and the operator keeps ownership of the roster, updating it as branches open, close, or move.

Will visitors know they're talking to a bot instead of a manager at their branch?

Yes, at Open, before any qualifying question is asked. This is not a style choice; California's B.O.T. Act requires clear, conspicuous disclosure when a bot communicates with someone online for a commercial purpose, and a public chat widget is reachable from California regardless of where the branches themselves are located (Cal. Bus. & Prof. Code § 17941).

What is the difference between the $250 Session and the $2,000 14-Day Implementation Sprint?

The Session is diagnostic: within two business days it delivers a written brief covering the accepted inquiry-to-booking path, the location-resolution rule, the baseline and KPI source, the roster and pricing approval points, the failure tests, and one recommended Sprint. It does not touch production systems. The Sprint builds the agreed solution, with acceptance tests and an operator handoff. The Session fee credits toward an accepted Sprint for 30 days.

How does the chat handle a visitor who just wants whichever location has the soonest opening?

That is one of the candidate inquiry types the Session can rank and scope, not something a first build should assume. It requires checking availability across every relevant branch's calendar at once, against a distance or service constraint the operator defines, before a slot is offered — a materially different build than resolving one visitor to one named branch, which is why the Session treats it as its own candidate rather than folding it into a simpler path by default.

Sources

• Salesforce Developers — Assignment Rule Header, REST API Developer Guide — documents that a CRM platform resolves record assignment server-side against active rules, the basis for treating branch destinations as server-owned rather than client-supplied.
• OWASP Cheat Sheet Series — Authorization Cheat Sheet — states that access and destination decisions must be enforced server-side, independent of any CRM vendor, the general principle behind this cell's server-owned-destination invariant.
• California Business and Professions Code § 17941 — the B.O.T. Act's requirement that a bot communicating online for a commercial purpose must clearly disclose that it is a bot, the basis for the Open-state disclosure requirement.
• Google Business Profile Help, "Bulk location management overview" — describes how a multi-location operator organizes and centrally manages its branches as a business group, the model this cell assumes for a canonical location roster.
• Federal Trade Commission, "Chatbots, deepfakes, and voice clones: AI deception for sale" — warns that chat tools designed to appear more human or authoritative than they are can themselves be deceptive, informing this cell's disclosure and grounding requirements.
• Federal Trade Commission, Advertising and Marketing — guidance that AI-related marketing claims need substantiation before publication, why this page states a baseline and a KPI instead of a promised result.

Book the Session for this exact cell

Discuss a real location-routing question with Pedro: an informal branch name, a booking from a branch page, or a member asking about another location. The $250 Business Diagnostic Session includes a written recommendation within two business days after the call. We contact you within one business day after payment to schedule.

Book the $250 Business Diagnostic Session for multi-location owner-led services