{
  "icp": "appointment-based small businesses running on Square Appointments — salons, barbershops, spas, tutoring, fitness studios, pet grooming, mobile services — whose phone keeps ringing while the staff are with clients",
  "capabilities": {
    "availability": {
      "headline": "Captures the caller as a Square customer, books the service in the same call, and feeds one unified conversion pipe for your website forms AND your AI Receptionist.",
      "lede": "Every caller who asks about a service lands as a customer in Square (with name, email, phone, and a booked appointment on the right team member's calendar, tied to the correct service variation and location). When they want a booking, AnyCRM writes a native Square booking through the Bookings API. AND the same lead event flows through one unified pipe (with the same shape, same source attribution, and same server-side conversion path used by your website forms) so your CRM business logic and your Google / Facebook / LinkedIn Ads both stay in sync.",
      "cards": [
        {
          "num": "A.01",
          "title": "Every inquiry becomes a Square customer, not a missed call",
          "body": "Caller's name, phone, email, the service they asked about, and any preferences land as a Square customer with source attribution and a profile note. Then AnyCRM writes the record into Square DURING the call."
        },
        {
          "num": "A.02",
          "title": "Books against the right team member's real availability",
          "body": "The AI Receptionist asks AnyCRM for live availability for the routed-to team member at the right location — honouring service duration, buffer times, existing bookings, and business hours — then AnyCRM writes the booking onto that team member's Square calendar in the same conversation."
        },
        {
          "num": "A.03",
          "title": "Sends the lead event straight to your CRM. You decide what happens next.",
          "body": "AnyCRM does not pretend to know your follow-up rules. Every customer-create and every booking sends a lead event straight to your CRM (with <code>source: \"AI Receptionist Call\"</code> or <code>source: \"AI Receptionist Web\"</code>) where YOUR business logic takes over. Send the deposit invoice, fire the loyalty trigger, push to your email tool. We set up the receiving end inside your CRM for you during onboarding, tuned to your industry. AnyCRM doesn't get in the way of policy you've already encoded."
        }
      ],
      "apiSummary": "The AI Receptionist asks AnyCRM for availability against the team members on your roster and gets back open slots in the caller's timezone. No double bookings. Existing bookings are always respected. Every AnyCRM call prevents duplicate customers, resolves the right service variation, sets the matched team member, writes the booking so it lands on the team member's Square calendar, and sends the lead event straight into your CRM tagged with <code>AI Receptionist Call</code> or <code>AI Receptionist Web</code>. The same lead also feeds the AnyCRM Conversion Lift pipeline (covered in the next capability) so your Google, Facebook, and LinkedIn Ads start optimising against the call and chat leads that actually pick up the phone.",
      "tools": [
        "getSquareAvailability",
        "createSquareContactAppointment"
      ],
      "curl1Path": "/mcp/tools/getSquareAvailability",
      "curl2Path": "/mcp/tools/createSquareContactAppointment",
      "pipeIntro": "Most service businesses run two completely separate conversion-tracking stacks: one for the website (booking site visits, form-fills, 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 and online-booking-page conversions, the bidding optimises for the wrong audience, attribution is broken, and analytics double-count or miss real conversations 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 page OR through the AI Receptionist on phone / chat. Either way, AnyCRM produces the same clean lead-event shape, tagged at source with either <code>AI Receptionist Call</code>, <code>AI Receptionist Web</code>, 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 marketing list, which loyalty tier, which follow-up sequence, which staff notification. 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 bookings (not just online-booking-page visits), your Facebook Ads campaigns see the high-intent traffic that picks up the phone, your analytics platform sees a single unified funnel, and attribution stops fragmenting between web and voice."
        }
      ],
      "outcomes": [
        "<strong>Higher ROAS.</strong> Ad bidding optimises against actual conversations and booked appointments, not against the noisy subset of leads that happen to fill a form or click the booking page.",
        "<strong>Lower ad costs.</strong> Once Google Ads and Facebook Ads learn what a real booking looks like, they stop spending against lookalikes of low-quality clicks.",
        "<strong>Enriched analytics.</strong> Every conversation surface (web form, online booking page, phone call, AI Receptionist chat) feeds the same event shape into your analytics, so funnels are complete instead of half-blind.",
        "<strong>Correct attribution.</strong> A caller who first saw a Google Ad, then visited the site, then phoned three days later gets attributed end-to-end. Voice traffic stops being invisible to your marketing stack.",
        "<strong>One source of truth for lead policy.</strong> Your CRM's flow owns deposit policy, loyalty triggers, and follow-up sequences. 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 customer is created, which list to add them to, and which follow-up to fire. That approach breaks the moment your business changes, 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 business 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 vertical, 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."
    },
    "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 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 or an online-booking-page visit counts. A real phone call from a high-intent buyer who picked up the phone at 7pm does NOT count. So Google bids harder on the audience that clicks (often the cheaper, lower-intent one) and ignores the audience that actually calls. 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-page completions. That's why your Cost per Lead looks low but you can't tell which Ads are actually filling chairs. The high-intent traffic is calling you instead of navigating the booking page, 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, not just the audience that loves clicking. In practice this means: <strong>Cost per Lead drops</strong> because you stop overpaying for low-intent clicks; <strong>Return on Ad Spend goes up</strong> because the Ads now find people closer to ready-to-book; and <strong>Customer Acquisition Cost shrinks</strong> because more of your Ad budget reaches buyers who will actually walk through the door."
        },
        {
          "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-page conversions 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 bookings actually came from."
        }
      ],
      "apiSummary": "Every customer-create and booking 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 page run through the same pipeline, so Web and Voice conversions feed the SAME training signal.",
      "businessImpact": [
        "<strong>Cost per Lead drops.</strong> Because Google, Facebook, and LinkedIn stop wasting your Ad budget on lookalikes of low-intent clickers, and start finding the audience that picks up the phone.",
        "<strong>Return on Ad Spend (ROAS) goes up.</strong> Because the Ads now optimise toward conversations that actually book, not toward whichever cheap audience generates the most clicks.",
        "<strong>Customer Acquisition Cost (CAC) shrinks.</strong> Because a higher share of every Ad dollar reaches buyers ready to book a service.",
        "<strong>Analytics get a complete funnel.</strong> Web and voice bookings sit side by side, with the same source taxonomy. You stop seeing \"50% of bookings: unknown source.\"",
        "<strong>Attribution stops fragmenting.</strong> A buyer who first clicked a Google Ad, then called the salon three days later, finally shows up correctly attributed. Today, that buyer is invisible to your Ads stack.",
        "<strong>You finally know if Ads are working.</strong> Most service businesses cannot honestly tell you whether their Google or Facebook spend is profitable. With AnyCRM's Conversion Lift, you can."
      ],
      "plainEnglishExample": "Imagine you spend $3,000/month on Google and Facebook Ads for your salon. Today, you see 60 online bookings and assume that's the full picture. With AnyCRM running, you'll also see (say) 90 phone calls and 30 web chats the AI Receptionist handled, all flowing into Google Ads and Facebook Ads as real conversions. Suddenly your Ad platforms see 180 conversions a month instead of 60. They re-train on that bigger, better signal. Within weeks, the bidding finds you more of the right kind of buyer. Same $3,000 spend, more booked chairs, 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": [
        "createOrUpdatesSquareContact",
        "createSquareContactAppointment"
      ]
    },
    "lifecycle": {
      "headline": "Owns the full booking lifecycle inside Square.",
      "lede": "Every \"can we push my Tuesday cut?\" or \"actually, cancel that\" lands with the AI Receptionist instead of on your front desk. AnyCRM reschedules update the existing booking in place. Cancellations follow Square's idiom (a proper cancel with the reason on the customer profile) instead of leaving the slot in limbo.",
      "cards": [
        {
          "num": "B.01",
          "title": "Finds the booking by email. No booking IDs on the call",
          "body": "Customers DO NOT quote booking IDs over the phone. AnyCRM resolves the Square customer by email, lists their upcoming bookings, and reads back the service, date, time, and team member before changing anything."
        },
        {
          "num": "B.02",
          "title": "Reschedules in place and keeps the booking record clean",
          "body": "Rescheduling updates the existing booking in a single confirmation, preserving the customer link and the team member assignment. Failed reschedules leave the original booking untouched. The customer never ends up with no appointment."
        },
        {
          "num": "B.03",
          "title": "Cancels with the reason on the record",
          "body": "When a caller cancels, AnyCRM writes the customer's reason onto the Square customer profile, then calls Square's cancel endpoint. So the next time the team member opens the customer's record, they know WHY the slot opened up. No silent disappearing bookings."
        }
      ],
      "apiSummary": "AnyCRM's search, reschedule, and cancel all accept just an email. The soonest upcoming Square booking for that customer is resolved inside AnyCRM. No booking IDs at the AI Receptionist layer.",
      "tools": [
        "searchSquareAppointments",
        "rescheduleSquareAppointment",
        "cancelSquareAppointment"
      ],
      "curl1Path": "/mcp/tools/searchSquareAppointments",
      "curl2Path": "/mcp/tools/rescheduleSquareAppointment",
      "curl3Path": "/mcp/tools/cancelSquareAppointment"
    },
    "routing": {
      "headline": "Routes every caller to the right team member. And respects which services they actually perform.",
      "lede": "Square Appointments accounts run on team members, locations, and service variations. A barber doesn't do colour. An esthetician doesn't do massage. The senior stylist's haircut is a different price and duration than the junior's. At setup AnyCRM imports your Square team members and your service variations into its database and enriches each member with qualified services, expertise, languages, timezone, and location assignment (context Square's team member object doesn't carry). The AI Receptionist then routes each caller to a team member who is actually qualified for the requested service at the right location.",
      "cards": [
        {
          "num": "C.01",
          "title": "Routes by service variation, not by free-text request",
          "body": "\"I want a balayage\" only resolves to the team members whose qualified services include balayage. \"A men's cut with Marco\" pins both the variation and the team member. \"Anyone available for a quick beard trim\" assigns across the qualified pool."
        },
        {
          "num": "C.02",
          "title": "Honours existing customer-to-team-member relationships",
          "body": "If a returning customer has a history of bookings with one team member, the AI Receptionist offers that member first. The customer profile, the notes, and any new booking all attach to the existing Square customer record. No orphaned duplicate, no lead poached off a stylist's chair."
        },
        {
          "num": "C.03",
          "title": "Respects location boundaries",
          "body": "Multi-location businesses (two salon branches, two studios) keep separate rosters per location. \"Can I book at the downtown location\" only surfaces team members assigned to that location. The AI Receptionist never books a stylist who isn't actually working at the requested branch."
        }
      ],
      "apiSummary": "Team details live in AnyCRM's database, pulled once from Square at setup (active team members joined against each member's bookable-flag and per-location assignments, and against the Catalog for each service variation the member is qualified to perform). Enriched with expertise, languages, timezone, and display order. AnyCRM keeps the Square team member identifier on the record as the bridge for booking writes. <code>listSquareTeamMembers</code> and <code>getSquareSpecialistServices</code> are hydration and re-sync calls, not per-call lookups. At runtime, one read of the team roster matches caller → service → qualified member at the right location. AnyCRM does NOT cache your follow-up policy or your loyalty rules. That policy stays inside your CRM, where it belongs.",
      "tools": [
        "listSquareTeamMembers",
        "getSquareSpecialistServices"
      ],
      "curl1Path": "/mcp/tools/listSquareTeamMembers",
      "curl2Path": "/mcp/tools/getSquareSpecialistServices"
    }
  },
  "setup": {
    "headline": "Setup in 3 steps. Battle-tested on real <span data-tpl-crm>Square</span> accounts.",
    "lede": "You connect <span data-tpl-crm>Square</span> once. AnyCRM imports your locations, your team members, your service variations, and your booking profiles. 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 appointments the same afternoon. No middleware. No prompt-engineering by you.",
    "steps": [
      {
        "num": "S.01",
        "title": "Connect Square (OAuth, 60 seconds)",
        "body": "Authorize AnyCRM on your Square account via the standard OAuth grant. AnyCRM scopes to the least amount of access needed for the booking lifecycle. Nothing for payments, orders, or payroll. You can always revoke permissions at any time from your Square Dashboard → Apps & Subscriptions → Authorised Applications. Every update to your Square 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 locations, team members, service variations & booking profiles. Wire up your CRM's lead-receiving flow.",
        "body": "AnyCRM imports every Square location, every active team member, every service variation from the Catalog (with the current variation version captured for booking writes), and each member's booking profile so we know who is actually bookable at which location. AnyCRM also freezes the service variations so the AI Receptionist can only book services you actually offer, and locks inbound-call source attribution (always <code>AI Receptionist Call</code> or <code>AI Receptionist Web</code>) 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 loyalty rules, your deposit policy, or your follow-up sequences. Your CRM decides what happens after a booking 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 team roster, same Square 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 Square's <strong>online booking site</strong> + Square Assistant?",
      "body": "Square's online booking site and Square Assistant SMS confirmations are excellent at the steps AFTER a customer has chosen to come to your booking page. Square Assistant is a text-only reply bot. It only replies to SMS appointment reminders to confirm, cancel, or change a booking that already exists. It doesn't pick up the phone, it doesn't qualify a new caller, and it doesn't book first-time customers. A new caller at 7pm gets a missed call, not a customer record. The booking site assumes the customer can navigate a service menu and pick a variation themselves. The AI Receptionist is the layer BEFORE all of that. It picks up the call, asks the right qualifying questions (\"are you looking for the men's cut or the women's cut?\"), books the appointment as a native Square booking on the right team member's calendar at the right location, writes a clean, sourced customer with the call summary in the profile note (with the source set to <code>AI Receptionist Call</code> or <code>AI Receptionist Web</code>), AND sends the same lead event straight into your CRM's downstream business logic plus your ad platforms server-side. So your Square workflow, your analytics, and your Google / Facebook Ads bidding all start optimising on a real conversation, not a missed call."
    },
    "enrichmentSummary": "Every tool the AI Receptionist calls is an opinionated wrapper inside AnyCRM. AnyCRM does the messy work for you. Dedup by email and phone, location resolution, service-variation-version capture, segment assembly, timezone math, 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 Catalog and Bookings internals.",
    "enrichmentExamples": [
      {
        "title": "Capturing a new inquiry",
        "raw": "Creating a customer straight in Square looks obvious. But Square does not dedup for you. Send the same caller twice and you get two customer records with two different IDs, fragmenting the customer's booking history. Square publishes a separate customer-search endpoint with email and phone filters and a merge endpoint for cleanup, but you have to KNOW the duplicate exists, find both IDs, and resolve which side wins. Worse, customer fields are flat strings (no arrays) so a typo on email creates a fresh record the next time the same person calls in. And idempotency keys are required to avoid double-writes on retry. Naive integrations omit them and end up with phantom duplicates on every network hiccup. Nothing in raw Square fires a server-side conversion event to your ad platforms either, so call-driven and chat-driven leads never get optimised for.",
        "mcp": "<code>createOrUpdatesSquareContact</code> accepts <code>name</code>, <code>email</code>, <code>phone</code>, <code>note</code>, plus the inferred source. AnyCRM searches by email then phone, picks the surviving record (or creates a new one with a deterministic idempotency key derived from the call), sets AnyCRM's reference on the customer for attribution, appends the call summary to the profile note, sends the lead event straight into your CRM (with source <code>AI Receptionist Call</code> or <code>AI Receptionist Web</code>), AND fires a server-side conversion event into your ad platforms using the origin of your registered domain. All in one AnyCRM call. Duplicate creation is structurally impossible."
      },
      {
        "title": "Booking the appointment",
        "raw": "Creating a booking directly against Square is deceptively complex. The appointment segments array is required and each segment must carry four bound values: a duration that matches the variation's own duration, a service variation ID that references a live Catalog object, a team member who is ACTIVE and bookable at the booking's location, and a service variation version (an integer that changes every time the variation is edited in the Square Dashboard). Send a stale version and the booking 400s with VERSION_MISMATCH. The start time is RFC 3339 with required timezone. The location must match a location with bookable buyer-timezone capability. Square's own docs flag that pre-checking availability is required. Bookings against an unavailable slot fail late with BOOKING_INVALID_SLOT.",
        "mcp": "<code>createSquareContactAppointment</code> takes <code>email</code>, <code>scheduled_datetime</code> (naive, no offset needed), <code>invitee_timezone</code>, and the service variation key. AnyCRM resolves the right team member from the service and location, refreshes the service variation version from the Catalog on every booking (never cached stale), reads duration from the variation, assembles the full segment array, runs the availability pre-check, converts the naive datetime to the format Square's booking endpoint requires, submits with a deterministic idempotency key, 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. Version-mismatch and invalid-slot errors are structurally impossible."
      },
      {
        "title": "Cancelling with a reason",
        "raw": "Square has no DELETE endpoint for bookings. Cancellation is a POST to the cancel path, which requires the current booking version (and stale-version writes 400 the same way variations do) and an idempotency key. There is no first-class reason field on the cancel call itself. Square's data model doesn't carry cancellation reasons on the booking. To preserve WHY the appointment fell through you'd have to: read the booking to capture the current version, call cancel with the correct version, then write a note on the customer record with the reason. Square has no booking-level notes endpoint. None of these are atomic, and an out-of-band version bump (e.g. an admin edited the booking in the Dashboard) breaks the chain.",
        "mcp": "<code>cancelSquareAppointment</code> takes <code>email</code> and <code>reason</code>. AnyCRM resolves the soonest upcoming booking, fetches the current booking version, writes the reason as a note on the customer record BEFORE the cancel fires, then calls Square's cancel endpoint with a deterministic idempotency key. All in one AnyCRM call. Stale-version 400s are handled with a single retry against the refreshed version. The response contains the cancelled booking ID and the recorded reason, so the AI Receptionist can read it back to the caller. No deletion, full audit trail, the customer profile preserves WHY the slot opened up."
      }
    ],
    "alignmentSummary": "Every AnyCRM tool for Square follows the same AI-alignment contract, so the AI Receptionist never has to think about transport:",
    "alignment": [
      "<strong>Naive datetimes in, Square-native shape out.</strong> The AI Receptionist passes <code>2026-05-15T11:00:00</code> and a timezone string. AnyCRM does the offset math against the location's timezone.",
      "<strong>Email is the identity.</strong> Cancel and reschedule never need a booking ID at the AI Receptionist layer. Email and soonest-upcoming resolves inside AnyCRM.",
      "<strong>Service variation, location, and team member come from setup, not the LLM.</strong> The AI Receptionist can't book a free-text \"haircut\". It resolves caller intent to a real service variation against your live Catalog.",
      "<strong>Existing customer relationships are sacred.</strong> If a returning caller has booking history with a team member, AnyCRM offers that member first. Duplicate customers are structurally impossible.",
      "<strong>Service variation version is always fresh.</strong> AnyCRM re-reads from the Catalog on every booking so version-mismatch can't fire when a stylist edits a price in the Dashboard mid-day.",
      "<strong>Cancellation preserves the audit trail.</strong> Square's idiom (a proper cancel with the reason captured on the customer profile) is honoured so the customer record reflects WHY the slot opened up.",
      "<strong>Every lead event leaves AnyCRM in two places at once.</strong> 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.",
      "<strong>Flat, deterministic shapes.</strong> Every AnyCRM response has the same top-level keys across every tool, so the AI Receptionist's prompt never grows with edge-case branching.",
      "<strong>Errors are messages, not codes.</strong> An error from Square becomes a one-sentence reason the AI Receptionist can repeat to the caller without translation.",
      "<strong>Idempotent reschedules.</strong> Every write carries a deterministic idempotency key. If a network blip retries the call, the booking is preserved. The customer never ends up with two appointments or none."
    ],
    "industryLine": "Currently running for <strong>salons, barbershops, day spas, nail studios, lash & brow bars, personal training studios, pet groomers, and mobile services</strong>. Anyone whose business is in Square Appointments but whose phone keeps ringing while staff are with clients.",
    "teamsSetup": {
      "headline": "Multi-team-member setup. Team roster, services & system-prompt assembly",
      "body": "If you run more than one team member on Square, AnyCRM imports the team roster once, you link each member to the service variations they actually perform (cuts / colour / treatments / training / grooming), 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 roster on every call. It already knows who handles what at which location.",
      "steps": [
        "<strong>Team roster import.</strong> AnyCRM imports every active Square team member once and writes each one into its database keyed by <code>crm_user_id</code> (with name, role, timezone, Square's team member identifier, and per-location assignments).",
        "<strong>Per-team-member services.</strong> For each team member AnyCRM joins the booking profile against the Catalog to return the exact service variations they're qualified to perform, with current variation version, duration, and price. One call per person, cached.",
        "<strong>Service visibility.</strong> Each service variation is flagged <em>Public</em>, <em>Private</em> or <em>Ignored</em>. The AI Receptionist only routes to and books Public variations. You toggle this in the AnyCRM dashboard without re-deploying.",
        "<strong>Lead-event receiving flow inside your CRM.</strong> During onboarding we wire up the flow inside your CRM that receives lead events from AnyCRM. That's where your deposit policy, your loyalty triggers, and your follow-up sequences live. AnyCRM doesn't try to own them.",
        "<strong>System-prompt assembly.</strong> The cached roster, service-variation, and location 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 team before it reads its own instructions.",
        "<strong>Runtime stays minimal.</strong> On a live call the AI Receptionist makes at most one availability call and one booking call. Never a team roster lookup. Updates to team members, services, or prices re-run the cache. The AI Receptionist picks them up on its next deploy."
      ],
      "note": "The end result: the AI Receptionist can match \"I'd like a balayage with someone senior at the downtown location next Thursday afternoon\" → senior colourists qualified for the balayage variation at the downtown location → that member's calendar availability → a booked Square appointment with the full segment array correctly assembled → a lead event delivered straight into your CRM → a server-side conversion event in your ad platforms. Without a single roster query during the call."
    }
  },
  "privacy": {
    "headline": "Your <span data-tpl-crm>Square</span> data passes through AnyCRM. It doesn't stick.",
    "lede": "AnyCRM processes your <span data-tpl-crm>Square</span> 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. Customers, bookings, services, team members. All of it stays in Square, owned by your Square account.",
    "cards": [
      {
        "kind": "stored",
        "label": "What AnyCRM stores",
        "body": "<strong>Conversation history IDs only.</strong> 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 customer records, no caller PII."
      },
      {
        "kind": "not-stored",
        "label": "What AnyCRM doesn't",
        "body": "Caller names, emails, phone numbers, Square customer IDs, your team roster, your service variations, your prices, your booking history. 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": "<strong>In your Square account and in whatever systems your CRM's flow forwards lead events to.</strong> Customers, bookings, profile notes all live in Square. Source-attributed (always <code>AI Receptionist Call</code> or <code>AI Receptionist Web</code>), 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 OAuth grant in your Square Dashboard → Apps & Subscriptions → Authorised Applications 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": "Square uses OAuth scopes. AnyCRM requests only the smallest set required for the booking lifecycle. Nothing for payments, nothing for orders, nothing for payroll.",
    "scopes": [
      "<strong>Customers (read + write).</strong> Read and write customer records, dedup against existing records, append profile notes (the lead-capture work).",
      "<strong>Appointments (read + write).</strong> Read availability and write bookings on the routed-to team member's calendar; reschedule in place; cancel with the reason on the customer profile (the booking work).",
      "<strong>Items (read).</strong> Read your Catalog so the AI Receptionist knows which service variations exist, with current versions, durations, and prices.",
      "<strong>Appointments business settings (read).</strong> Read team-member booking profiles so the AI Receptionist only books members who are actually bookable at the requested location.",
      "<strong>Employees (read).</strong> Read your team roster at setup time, so the AI Receptionist knows who exists and who is currently active.",
      "<strong>Not requested:</strong> payments, orders, invoices, payroll, bank accounts, gift cards, loyalty, marketing campaigns (deposit and loyalty policy stays inside your CRM's own flow), your other integrations."
    ],
    "surfaceNote": "Same OAuth grant any Square 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 customer and booking change is attributable to AnyCRM in Square'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 customers",
      "raw": "Raw Square customer-creates will happily produce a second record for the same caller. Same email, same phone, different customer ID. Square has no implicit dedup. You have to search first, decide whether to merge, then call merge. <strong>My AI Front Desk</strong> runs on a Zapier-style \"Log Customer Interaction\" / \"Update Customer Records\" action list — a single API call that hands the caller's email straight to Square's customer-create endpoint without a search-first step. Same caller, slightly different casing? Duplicate. Phone-only? Duplicate. <strong>Goodcall</strong> writes through a connector that does the same single-step create. <strong>Smith.ai's AI tier</strong> logs the customer through a similar one-shot create after the call. None of these 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 Square on a normalised lowercased + trimmed email, then on a normalised phone, then decides whether to update the existing customer or create a new one. Every write carries a deterministic idempotency key. A returning caller lands on the existing record with a new profile note, never as a duplicate. This costs us an extra API call per customer-create. We do it anyway, because the alternative is the duplicate-customer mess Smith.ai, My AI Front Desk, and Goodcall users live with. We do two checks where they do one.",
      "competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai (AI tier)"]
    },
    {
      "title": "Stale service-variation versions on booking",
      "raw": "Square bookings require the service variation version in every segment. This integer changes every time anyone edits the variation in the Square Dashboard (price tweak, duration change, name fix). Send a stale version and the booking 400s with VERSION_MISMATCH. <strong>My AI Front Desk's</strong> Zapier-style \"Schedule Appointments\" action posts whatever it has straight at Square — no \"refresh the variation version per-call\" step exists in a Zapier path. The version is cached at trigger-setup time, which guarantees a VERSION_MISMATCH the moment anyone edits a service in the Dashboard. <strong>Goodcall's</strong> connector behaves the same way. Its public materials do not describe per-call refresh of the variation version. <strong>Smith.ai</strong> doesn't write Square bookings live from an AI conversation at all — their tier books the public Square Appointments booking page link manually after the call — so they avoid this error only by side-stepping the entire booking write.",
      "mcp": "AnyCRM re-reads the service variation version from the Catalog on every booking. Never cached, never stale. VERSION_MISMATCH is structurally impossible. If a Dashboard edit happens between the availability check and the booking write, AnyCRM transparently retries against the refreshed version. We do two reads where Smith.ai/My AI Front Desk/Goodcall do none.",
      "competitorsAffected": ["My AI Front Desk", "Goodcall"]
    },
    {
      "title": "Booking against an unavailable slot",
      "raw": "Square's booking endpoint doesn't pre-check availability for you. You can send a perfectly-shaped payload for a slot the team member already has booked, and Square will return BOOKING_INVALID_SLOT only after the full validation pass — late in the request. <strong>My AI Front Desk's</strong> Zapier action takes whatever time the AI generates and posts it — no \"is this slot actually open?\" check, no pre-call against Square's availability-search endpoint. The booking either succeeds or fails late, and the caller has already been told their appointment is confirmed. <strong>Goodcall's</strong> connector behaves the same way. <strong>Smith.ai</strong> receptionists check the public Square booking page visually, but on a busy Friday at 8pm with a relief receptionist, that breaks down.",
      "mcp": "AnyCRM does multiple things in one call: looks up the team member's identifier, validates the service variation is bookable at the requested location, runs the availability pre-check against the right team member and location, then writes the booking. The AI Receptionist only ever offers slots that are actually open. We run three checks where Smith.ai/My AI Front Desk/Goodcall do one. That's why a booking confirmed through AnyCRM is never silently rejected after the call.",
      "competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai (human tier)"]
    },
    {
      "title": "Booking the wrong team member's calendar",
      "raw": "Square's booking endpoint happily accepts any team member identifier, including inactive members or members who aren't assigned to the booking's location. <strong>My AI Front Desk's</strong> Zapier action takes whichever team-member name the AI generates and posts it. No \"is this person still active?\" check, no \"does this person actually perform this service variation at this location?\" check. A colour service gets booked on a barber who only does cuts, or worse, on a stylist who is rostered at the other branch. <strong>Goodcall's</strong> connector assigns based on connector defaults rather than the service and location the caller actually asked for. <strong>Smith.ai's</strong> 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 caller's service intent to a real service variation, looks up the right team member from the AnyCRM roster, filters out inactive members AND members not bookable at the requested location AND members whose qualified services don't include the requested variation, then writes the booking. The AI Receptionist can't book on a calendar that isn't currently rostered for that service at that location. Smith.ai/My AI Front Desk/Goodcall can't do this because their architecture is one-shot.",
      "competitorsAffected": ["Smith.ai (human tier)", "Goodcall", "My AI Front Desk"]
    },
    {
      "title": "Inventing services and free-text bookings",
      "raw": "Square service variations aren't free text. The booking write must reference a live Catalog object. <strong>My AI Front Desk's</strong> Zapier-style action takes whatever the AI generates and posts it. There is no \"read your portal's real service variations first\" step in a Zapier path; it's a single action. So the AI invents a service like \"quick trim\" when your Catalog only contains \"Men's Cut – 30 min\" and \"Men's Cut – 45 min\", the write fails with NOT_FOUND (or worse, succeeds with the wrong variation), and the price the AI Receptionist quoted to the caller doesn't match the booking. <strong>Goodcall's</strong> connector hands the value through to Square the same way. <strong>Smith.ai's</strong> AI tier picks values from a generic playbook that doesn't match your Catalog. The architecture is one-shot. There is no \"check the Catalog first\" step.",
      "mcp": "AnyCRM reads your portal's real service variations at setup, in a separate call to Square's Catalog, and bakes them into the AI Receptionist's system prompt as a frozen table — names, durations, prices, qualified team members. The AI Receptionist CAN ONLY book variations that exist in your Catalog, and the price and duration it quotes are the Catalog's, not a guess. Free-text bookings are structurally impossible. This is one Catalog read at setup time that Smith.ai, My AI Front Desk, and Goodcall don't make.",
      "competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai (AI tier)"]
    },
    {
      "title": "Cancelling by DELETE or by walking away",
      "raw": "Square has no DELETE endpoint for bookings. Cancellation is a POST to the cancel path, which requires the current booking version. <strong>My AI Front Desk's</strong> Zapier-style cancel action (where it exists at all) issues whatever Zapier's connector exposes. Most paths either fail because the version wasn't fetched first, or succeed silently with no reason captured because Square's booking object has no cancellation-reason field. <strong>Goodcall's</strong> cancellation goes through the connector's default behaviour — no path to record WHY the appointment fell through, because Square has no booking-level notes endpoint. <strong>Smith.ai</strong> receptionists ask the caller why, but the cancellation lands as a manual note rather than as a structurally captured cancellation, so reporting doesn't reflect it correctly.",
      "mcp": "AnyCRM's cancellation is multi-step: find the soonest upcoming booking, capture the caller's reason, fetch the current booking version, write the reason as a note on the customer profile, AND call Square's cancel endpoint atomically. The reason is preserved on the customer record, the booking is properly cancelled the Square-native way, and stale-version 400s are handled with a single retry against the refreshed version. Four operations where Smith.ai/My AI Front Desk/Goodcall do one (and usually the wrong one).",
      "competitorsAffected": ["My AI Front Desk", "Goodcall"]
    },
    {
      "title": "Location confusion in multi-location accounts",
      "raw": "Square's Bookings API is location-scoped. Every booking carries a location, and every availability search must specify one. A multi-location business that runs two branches has two separate booking calendars, two separate booking-profile sets, and often overlapping team members who work at both. <strong>My AI Front Desk's</strong> Zapier action defaults to whichever location was selected at trigger-setup time — book a downtown customer at the uptown branch, and Square won't catch the mistake because the booking is technically valid. <strong>Goodcall's</strong> connector behaves similarly. Its public materials don't describe per-call location resolution. <strong>Smith.ai</strong> humans usually get this right but rely on the receptionist remembering which branch the caller wanted.",
      "mcp": "AnyCRM imports every location at setup and assigns each team member to the locations they actually work. The booking flow requires location resolution before writing — either from the caller's stated branch or from the team member's primary location — and only surfaces availability at the right location. The AI Receptionist never books a caller at the wrong branch.",
      "competitorsAffected": ["My AI Front Desk", "Goodcall"]
    },
    {
      "title": "Encoding your deposit and loyalty policy in the prompt or in middleware",
      "raw": "<strong>My AI Front Desk</strong> ships hardcoded \"Create Invoice\" and \"Automate Payments\" actions that fire on every inbound call. There is no \"only take a deposit for new clients booking over $80 of services\" logic — the actions are single-step, so either every call gets an invoice (annoying your regulars) or none do (no deposit protection at all). Worse, the moment you change your deposit policy or your loyalty tiers, you have to go back into Zapier and rebuild the zaps. <strong>Goodcall's</strong> connector applies whatever default behaviour the underlying integration shipped with — change your business, and the connector keeps doing what it did six months ago. <strong>Smith.ai's</strong> AI tier and human receptionists work from playbooks that drift out of date as your real CRM policy evolves.",
      "mcp": "AnyCRM does not encode your deposit or loyalty 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: deposit rules? Update the flow. New loyalty tier? Update the flow. New follow-up sequence? 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 business policy into either Zapier middleware or a hardcoded action.",
      "competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai (AI tier)"]
    },
    {
      "title": "Web bookings and AI Receptionist bookings run on two separate conversion-tracking stacks",
      "raw": "<strong>Smith.ai, My AI Front Desk, and Goodcall</strong> all treat phone and chat conversions as separate from online-booking-page conversions and web form-fills. None of them fire a real conversion event into Google Ads, Facebook Ads, or LinkedIn Ads when the AI Receptionist closes a call. So your Ad platforms only see the online bookings, the bidding optimises for that audience, your Cost per Lead looks deceptively low, ROAS reporting becomes a fiction, and the high-intent traffic that picks up the phone stays invisible to your Ad stack. Worse, when these competitors DO fire any 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 structurally can'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"]
    }
  ],
  "failureModesMeta": {
    "headline": "How most AI Receptionists built on <strong>Smith.ai, My AI Front Desk, or Goodcall</strong> fail for <strong>salons, barbershops, spas, fitness studios, pet groomers, and other service businesses</strong> that use <span data-tpl-crm>Square</span>. And why AnyCRM can't.",
    "lede": "Most AI Receptionists fail on Square in the same handful of ways. Duplicate customers, stale service-variation versions, bookings against unavailable slots, the wrong team member's calendar, invented services and free-text bookings, cancellations that destroy the audit trail, multi-location confusion, hardcoded deposit and loyalty rules that drift away from your real 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 deposit and loyalty 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 <span data-tpl-crm>Square</span>",
    "columns": [
      { "key": "anycrm", "label": "AnyCRM" },
      { "key": "smithai", "label": "Smith.ai" },
      { "key": "myaifrontdesk", "label": "My AI Front Desk" },
      { "key": "goodcall", "label": "Goodcall" }
    ],
    "rows": [
      {
        "capability": "Live Square booking written DURING the call",
        "anycrm": "<strong>Yes.</strong> Native Square booking, team-member-matched, location-scoped, calendar-synced.",
        "smithai": "No. Booked manually after the call via your public Square booking page link.",
        "myaifrontdesk": "Partial. Zapier-style \"Schedule Appointments\" action without per-call version refresh or availability pre-check.",
        "goodcall": "Partial. Connector write without published team-member-booking-profile awareness."
      },
      {
        "capability": "Dedup-before-write on email and phone",
        "anycrm": "<strong>Yes.</strong> Always.",
        "smithai": "Manual.",
        "myaifrontdesk": "No. Zapier customer-create is one-shot.",
        "goodcall": "No published guarantee."
      },
      {
        "capability": "Preserves existing customer-to-team-member relationship on returning callers",
        "anycrm": "<strong>Yes.</strong> Returning customers offered their previous stylist first.",
        "smithai": "Implicit, not guaranteed.",
        "myaifrontdesk": "No. Can overwrite.",
        "goodcall": "Depends on connector defaults."
      },
      {
        "capability": "Routes by service variation, not free-text request",
        "anycrm": "<strong>Yes.</strong> Service variation is part of AnyCRM's frozen Catalog snapshot.",
        "smithai": "Manual, depends on the receptionist.",
        "myaifrontdesk": "No.",
        "goodcall": "No."
      },
      {
        "capability": "Service variations & prices frozen from your real Catalog at setup",
        "anycrm": "<strong>Yes.</strong> Read at setup, baked into the prompt as a frozen table.",
        "smithai": "Not API-enforced.",
        "myaifrontdesk": "No. Writes can fail on unknown variations.",
        "goodcall": "No structural guard."
      },
      {
        "capability": "Cancellation preserves the audit trail (reason on customer profile, not deleted)",
        "anycrm": "<strong>Yes.</strong> Square-native cancel + reason note.",
        "smithai": "Manual.",
        "myaifrontdesk": "No. Reason isn't captured.",
        "goodcall": "No. Connector default with no reason path."
      },
      {
        "capability": "Reschedule in place (no cancel-then-rebook)",
        "anycrm": "<strong>Yes.</strong>",
        "smithai": "Manual.",
        "myaifrontdesk": "No.",
        "goodcall": "No."
      },
      {
        "capability": "Service-variation version refreshed on every booking (no VERSION_MISMATCH)",
        "anycrm": "<strong>Yes.</strong> Re-read from Catalog on every booking.",
        "smithai": "N/A — bookings are manual.",
        "myaifrontdesk": "No. Version cached at Zapier trigger-setup time.",
        "goodcall": "No published guarantee."
      },
      {
        "capability": "Availability pre-checked before booking write (no BOOKING_INVALID_SLOT after the call)",
        "anycrm": "<strong>Yes.</strong> Always.",
        "smithai": "Receptionist checks visually.",
        "myaifrontdesk": "No.",
        "goodcall": "No published guarantee."
      },
      {
        "capability": "Location-scoped routing in multi-branch accounts",
        "anycrm": "<strong>Yes.</strong> Every booking resolves to the right location.",
        "smithai": "Manual, depends on the receptionist.",
        "myaifrontdesk": "No. Defaults to trigger-setup location.",
        "goodcall": "No published per-call resolution."
      },
      {
        "capability": "Deposit & loyalty policy delegated to YOUR CRM's own flow",
        "anycrm": "<strong>Yes.</strong> Lead event delivered straight into your CRM, into the receiving flow we wire up at onboarding.",
        "smithai": "No. Policy lives in the receptionist's training.",
        "myaifrontdesk": "No. Hardcoded \"Create Invoice\" / \"Automate Payments\" actions.",
        "goodcall": "No. Connector-default behaviour."
      },
      {
        "capability": "Unified conversion pipe: web bookings AND AI Receptionist → CRM + ad platforms server-side",
        "anycrm": "<strong>Yes.</strong> Same shape, same source taxonomy, same server-side delivery.",
        "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": "<strong>Yes.</strong> Every call and chat lead lands server-side.",
        "smithai": "No.",
        "myaifrontdesk": "No.",
        "goodcall": "No."
      },
      {
        "capability": "Source attribution stays consistent across web and voice",
        "anycrm": "<strong>Yes.</strong> <code>AI Receptionist Call</code>, <code>AI Receptionist Web</code>, plus your web form identifiers.",
        "smithai": "Manual / inconsistent.",
        "myaifrontdesk": "No standardised taxonomy.",
        "goodcall": "Whatever the connector defaults to."
      },
      {
        "capability": "Scale ceiling",
        "anycrm": "Bounded by Square API limits, not by staffing.",
        "smithai": "Bounded by human receptionist staffing.",
        "myaifrontdesk": "Bounded by Zapier rate limits and action contracts.",
        "goodcall": "Bounded by the connector hop."
      }
    ],
    "footer": "Every row in this table is solved one layer down inside AnyCRM. Not in the prompt. Not by humans. Not by Zapier."
  },
  "faqs": [
    {
      "q": "Does this actually work with my Square Appointments account?",
      "a": "Yes. AnyCRM uses Square's official Bookings, Customers, Catalog, and Team APIs via a standard OAuth grant. Every captured caller lands as a Square customer with the right source and a profile note from the call. Appointments land as native Square bookings on the right team member's calendar at the right location, with the full segment array correctly assembled."
    },
    {
      "q": "Will it create duplicate customers in Square?",
      "a": "No. AnyCRM resolves the existing customer first (normalising email and phone) before writing, and every write carries a deterministic idempotency key. A returning caller becomes a new profile note on the existing record, never a second customer."
    },
    {
      "q": "Can it route different inquiries to different team members?",
      "a": "Yes. AnyCRM reads your Square team roster once at setup. Every active member, with their qualified service variations, location assignments, and timezone. \"A men's cut with Marco\" pins both the variation and the member. \"A balayage, anyone available\" assigns across qualified colourists at the right location. Inactive members and members not assigned to the requested location are filtered out."
    },
    {
      "q": "Where do the appointments actually live, calendar or Square?",
      "a": "In Square — as native bookings on the right team member's calendar. The booking is queryable in the Square Dashboard, surfaces in the team member's Appointments app, and triggers Square Assistant's SMS confirmations to the customer automatically. You see one clean booking, one source-attributed customer, one profile note. Same as a counter-booked appointment."
    },
    {
      "q": "Can it cancel or reschedule an appointment from a phone call?",
      "a": "Yes. The caller gives their email, AnyCRM finds the soonest upcoming Square booking, the AI Receptionist reads it back, and AnyCRM either reschedules in place or cancels the Square-native way (with the reason captured on the customer profile). Never a deletion. Square doesn't have one anyway."
    },
    {
      "q": "What if I edit a service price in the Square Dashboard mid-day?",
      "a": "No problem. AnyCRM re-reads the service variation version from the Catalog on every booking, so the dreaded version-mismatch 400 can't fire. The price and duration the AI Receptionist quotes are always the current Catalog values."
    },
    {
      "q": "Does it handle multiple locations correctly?",
      "a": "Yes. Setup imports every Square location and each team member's location assignments. The AI Receptionist confirms the caller's preferred branch, surfaces availability only at that location, and only books members who actually work there. No cross-branch confusion."
    },
    {
      "q": "Does it handle timezones correctly?",
      "a": "Yes. The AI Receptionist confirms the caller's timezone, AnyCRM converts the time into the format Square's booking endpoint requires, and the AI Receptionist reads the time back to the caller in <em>their</em> local timezone. No customer-facing UTC strings, no off-by-an-hour confirmations."
    },
    {
      "q": "Does it handle deposits or take payment over the phone?",
      "a": "Not directly. AnyCRM stays focused on the conversation surface: capturing the customer, matching the right team member, booking the appointment. Deposit and payment policy is YOUR business policy, and that policy lives inside your CRM, in the receiving flow we wire up for you at onboarding. Every customer-create and every booking in AnyCRM sends a lead event straight into that flow (tagged with source <code>AI Receptionist Call</code> or <code>AI Receptionist Web</code>). Your flow decides whether a deposit invoice fires, which loyalty tier applies, which follow-up sequence runs. AnyCRM doesn't try to encode policy that will drift out of date 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 page) 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 and online booking page? Do they go through the same pipe?",
      "a": "Yes — that's the whole point. Web forms, online-booking-page conversions, AND the AI Receptionist all 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 bookings into Square?",
      "a": "Most businesses are live the same afternoon. The OAuth grant takes a minute. The team + Catalog + booking-profile 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."
    }
  ]
}