{
"icp": "fitness studios, yoga and pilates studios, wellness spas, boutique gyms, and personal-training studios already running their bookings on Mindbody",
"capabilities": {
"availability": {
"headline": "Captures the caller as a Mindbody client, books the appointment or class enrollment in the same call, and feeds one unified conversion pipe for your website forms AND your AI Receptionist.",
"lede": "Every caller who lands on the line becomes a Mindbody client with the right home location and a real client record. When they want a session, AnyCRM books it as a native Mindbody appointment on the right staff member's schedule (or as a class visit in the right class) at the right location. 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 Mindbody workflows and your Google / Facebook / LinkedIn Ads both stay in sync.",
"cards": [
{
"num": "A.01",
"title": "Every caller becomes a Mindbody client, not a stray missed call",
"body": "The AI Receptionist captures first name, last name, email, mobile phone, and the location they're calling about. Then AnyCRM writes the client into Mindbody with the right home location DURING the call."
},
{
"num": "A.02",
"title": "Books appointments as native Mindbody appointments on the right staff member's schedule",
"body": "The appointment lands as a real Mindbody appointment with the right staff member, the right session type, the right location, and a duration that matches the session type. So it shows on the staff member's schedule and on the client's account exactly the way Mindbody expects, and your existing client-confirmation emails, contract assignments, and autopay drafts fire automatically."
},
{
"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 membership-creation or contract-assignment rules. Every client-create and every booking sends a lead event straight to your CRM (with source: \"AI Receptionist Call\" or source: \"AI Receptionist Web\") where YOUR business logic takes over. Trigger the welcome series, assign the contract, offer the intro pack, route to the right location workflow. We set up the receiving end inside your CRM for you during onboarding, tuned to your studio configuration. AnyCRM doesn't get in the way of policy you've already encoded."
}
],
"apiSummary": "The AI Receptionist asks AnyCRM for availability against the staff on your roster and gets back open slots in the caller's timezone at the right location. No double bookings. Class capacity and waitlist policy are always respected. Every AnyCRM call prevents duplicate clients, resolves the right home location, matches the staff member to the requested session type, writes the appointment so the staff member's schedule and the client's account are both updated atomically, and sends the lead event straight into your CRM tagged with AI Receptionist Call or AI Receptionist Web. 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": [
"getMindbodyAvailability",
"createMindbodyContactAppointment"
],
"curl1Path": "/mcp/tools/getMindbodyAvailability",
"curl2Path": "/mcp/tools/createMindbodyContactAppointment",
"pipeIntro": "Most studios run two completely separate conversion-tracking stacks: one for the website (booking widget, class schedule embeds, page-load pixels) and a totally absent one for the phone and the AI Receptionist. So Google Ads and Facebook Ads only learn from web bookings, the bidding optimises for the wrong audience, attribution is broken, and the high-intent caller who phones at 7pm to book a free intro stays invisible. 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 booking widget / class schedule embed OR through the AI Receptionist on phone / chat. Either way, AnyCRM produces the same clean lead-event shape, tagged at source with either AI Receptionist Call, AI Receptionist Web, or your website's booking-widget 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 welcome series, which intro pack offer, which contract template, which location workflow, which front-desk channel. You don't have to maintain two sets of rules. Web bookings and AI Receptionist bookings 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 bookings AND AI Receptionist bookings flow through the same pipe with the same source taxonomy, your Google Ads bid strategy now optimises against real revenue (not just web-widget noise), 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": [
"Higher ROAS. Ad bidding optimises against actual booked sessions and class enrollments, not against the noisy subset of leads that happen to make it through the widget.",
"Lower ad costs. Once Google Ads and Facebook Ads learn what a real intro-pack buyer looks like, they stop spending against lookalikes of low-intent web-widget tyre-kickers.",
"Enriched analytics. Every conversation surface (web widget, web chat, phone call, AI Receptionist chat) feeds the same event shape into your analytics, so funnels are complete instead of half-blind.",
"Correct attribution. A caller who first saw a Google Ad for your studio, then visited the site, then phoned three days later to book a free intro gets attributed end-to-end. Voice traffic stops being invisible to your marketing stack.",
"One source of truth for lead policy. Your CRM's flow owns membership creation, contract assignment, and intro-pack offers. 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 membership is created, which contract template to apply, which late-cancel policy to fire, and which source tag to use. That approach breaks the moment your studio policy 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 studio configuration, 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 for studios. AnyCRM treats the AI Receptionist as one of two equally weighted entries into a unified lead-event pipe, and that's where the real compounding value sits for a studio running Ads."
},
"adsConversionLift": {
"headline": "Turns every call and chat into a real conversion event your Google, Facebook, and LinkedIn Ads can actually optimise against. So Cost per Lead drops, ROAS goes up, and CAC stops being a guess.",
"lede": "If you run paid Ads on Google, Facebook, or LinkedIn to fill classes, here is the uncomfortable truth: those platforms only get smarter when they see real conversions. Today, a web-widget booking counts. A real phone call from a high-intent buyer asking about your intro-pack at 7pm does NOT count. So Google bids harder on the audience that uses the widget (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 web-widget bookings.",
"body": "Today, Google Ads and Facebook Ads probably think your only conversions are web-widget bookings. That's why your Cost per Lead looks low but your front-desk team complains the leads are weak. The high-intent traffic is calling you to ask about pricing and intro packs instead of clicking through your widget, 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 through booking widgets. In practice this means: Cost per Lead drops because you stop overpaying for low-intent web traffic; Return on Ad Spend goes up because the Ads now find people closer to ready-to-buy; and Customer Acquisition Cost shrinks because more of your Ad budget reaches buyers who will actually convert into members."
},
{
"num": "1b.03",
"title": "The same pipe carries your website widget 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 booking widget and class-schedule embed through the same pipeline. So a lead from a Google Ad that books through your widget 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 members actually came from."
}
],
"apiSummary": "Every client-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 booking widget runs through the same pipeline, so Web and Voice conversions feed the SAME training signal.",
"businessImpact": [
"Cost per Lead drops. Because Google, Facebook, and LinkedIn stop wasting your Ad budget on lookalikes of low-intent widget clickers, and start finding the audience that picks up the phone to ask about your intro pack.",
"Return on Ad Spend (ROAS) goes up. Because the Ads now optimise toward conversations that actually convert into memberships, not toward whichever cheap audience generates the most widget visits.",
"Customer Acquisition Cost (CAC) shrinks. Because a higher share of every Ad dollar reaches buyers ready to walk into your studio.",
"Analytics get a complete funnel. Web and voice leads sit side by side, with the same source taxonomy. You stop seeing \"50% of new members: unknown source.\"",
"Attribution stops fragmenting. A buyer who first clicked a Google Ad, then called the studio three days later, finally shows up correctly attributed. Today, that buyer is invisible to your Ads stack.",
"You finally know if Ads are working. Most studios 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 Ads to fill classes at your studio. Today, you see 40 web-widget bookings and assume that's the full picture. With AnyCRM running, you'll also see (say) 55 phone calls and 30 web chats the AI Receptionist handled, all flowing into Google Ads as real conversions. Suddenly Google sees 125 conversions a month instead of 40. It re-trains on that bigger, better signal. Within weeks, the bidding finds you more of the right kind of buyer (the one who phones at 7pm to ask about your intro pack, not just the one who clicks the widget). Same $3,000 spend, more real members, lower Cost per Lead, higher revenue per ad dollar. That is what \"AI Receptionist with AnyCRM\" actually means for the bottom line. Not just \"it answers the phone.\"",
"tools": [
"createOrUpdatesMindbodyContact",
"createMindbodyContactAppointment"
]
},
"lifecycle": {
"headline": "Manages the full appointment and class-visit lifecycle inside Mindbody.",
"lede": "Every \"can we push the Tuesday massage?\" or \"actually, cancel tonight's vinyasa\" lands with the AI Receptionist instead of at the front desk. AnyCRM reschedules update the existing Mindbody record in place. Cancellations follow Mindbody's own idiom (status change, not deletion) and your studio's late-cancel policy fires through Mindbody's own engine. So you get crystal clarity on what changed, when, and why, instead of a deletion that strips the visit history.",
"cards": [
{
"num": "B.01",
"title": "Finds the booking by email in a single step without needing an appointment ID",
"body": "Customers DO NOT quote appointment IDs over the phone. We've tested with hundreds of callers and each time they were asked 'Can you tell me the appointment id from your email?', the response was the same: 'Why can't you find it yourself?'. AnyCRM gives the AI Receptionist an easy way to find the soonest upcoming booking (appointment OR class visit) for the matching client. And the AnyCRM response forces the AI Receptionist to be human. It reads back the service, staff, location, and time before changing anything."
},
{
"num": "B.02",
"title": "Reschedules in place and keeps the booking record clean",
"body": "Rescheduling updates the existing appointment in a single confirmation. No cancel-then-rebook round-trip means the client's visit history, the staff assignment, and any deposit all stay intact. Failed reschedules leave the original appointment untouched."
},
{
"num": "B.03",
"title": "Cancels without erasing the audit trail, and honours late-cancel policy",
"body": "When a caller cancels, AnyCRM flags the booking cancelled the Mindbody-native way (status change, not delete) so it stays queryable in reporting and on the visit history. The caller's reason is written onto the client's account, and the studio's late-cancel-fee policy fires automatically through Mindbody's own engine when the cancellation falls inside the window. So the right policy fires every time instead of being argued about later."
}
],
"apiSummary": "AnyCRM's search, reschedule, and cancel all accept just an email. The soonest upcoming Mindbody booking (appointment OR class visit) for that client is resolved inside AnyCRM and returned as a single chronological list. No appointment IDs at the AI Receptionist layer.",
"tools": [
"searchMindbodyAppointments",
"rescheduleMindbodyAppointment",
"cancelMindbodyAppointment"
],
"curl1Path": "/mcp/tools/searchMindbodyAppointments",
"curl2Path": "/mcp/tools/rescheduleMindbodyAppointment",
"curl3Path": "/mcp/tools/cancelMindbodyAppointment"
},
"routing": {
"headline": "Routes every caller to the right staff member and the right service. Across every location.",
"lede": "Mindbody studios run on staff, session types, and locations. At setup AnyCRM imports your Mindbody staff roster into its database and enriches each staff member with expertise, languages, timezone, and the locations they actually teach at. The AI Receptionist then routes each caller to the staff member who actually offers that service at that location. Existing client-to-staff preferences in Mindbody are honoured as the source of truth.",
"cards": [
{
"num": "C.01",
"title": "Routes by service: massage vs personal training vs yoga private",
"body": "\"I want a 60-minute deep tissue with someone who does prenatal\" routes to staff whose bookable services include 60-minute deep-tissue AND whose expertise tags include prenatal. \"I want a private vinyasa with Sarah\" routes to Sarah's private-yoga service at the location she teaches it."
},
{
"num": "C.02",
"title": "Honours the existing client and their home location",
"body": "If the caller is already a Mindbody client with a home location and a preferred staff member, the AI Receptionist doesn't reassign them. The appointment and any new note attach to the existing client at the existing home location. No orphaned duplicate at a sister studio."
},
{
"num": "C.03",
"title": "Respects class capacity and waitlists",
"body": "When a caller wants a class that's full, the AI Receptionist offers the waitlist instead of inventing capacity. Capacity, waitlist policy, and pricing-option requirements come from the class definition in Mindbody, not the LLM."
}
],
"apiSummary": "Team details live in AnyCRM's database, pulled once from Mindbody at setup, enriched with expertise, languages, timezone, and per-location assignments (valuable context for the AI Receptionist that Mindbody's staff object doesn't carry by default). Each staff member's Mindbody record is kept on the record as the bridge for the booking write. At runtime, one read of the team roster matches caller intent → service → staff member → location → bookable slot. AnyCRM does NOT cache your contract templates, your pricing options' business rules, or your membership pipelines. That policy stays inside your CRM, where it belongs.",
"tools": [
"listMindbodyTeamMembers",
"getMindbodySpecialistServices"
],
"curl1Path": "/mcp/tools/listMindbodyTeamMembers",
"curl2Path": "/mcp/tools/getMindbodySpecialistServices"
}
},
"setup": {
"headline": "Setup in 3 steps. Battle-tested on real Mindbody studios.",
"lede": "You activate AnyCRM on your Mindbody site once. AnyCRM imports your staff, your session types, your locations, your classes, and your pricing options. 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 sessions the same afternoon. No middleware. No front-desk transcription.",
"steps": [
{
"num": "S.01",
"title": "Connect Mindbody (Public API source credentials + activation, ~5 minutes)",
"body": "AnyCRM is a Mindbody-approved API partner with our own source credentials. You activate AnyCRM from your Mindbody site's Integrations panel (which generates a one-time activation code), confirm the sites we're allowed to read and write, and approve the scopes we requested. Authorization is per-site and revocable from the Integrations panel at any time. Every write AnyCRM does is signed with AnyCRM's partner credentials, so it's easy to track what the AI Receptionist did when you audit."
},
{
"num": "S.02",
"title": "Import staff, session types, locations, classes and pricing options. Wire up your CRM's lead-receiving flow.",
"body": "AnyCRM imports every active Mindbody staff member as a bookable team member with expertise, languages, timezone, and per-location assignments. AnyCRM also reads your session types, your locations, your class schedule, and your pricing options, and freezes them so the AI Receptionist can only book services you actually offer, and locks inbound-call source attribution (always AI Receptionist Call or AI Receptionist Web) so reporting stays consistent. During onboarding we set up the receiving flow inside your CRM so the lead events from the AI Receptionist land where your business logic can act on them. AnyCRM does NOT replicate your contract templates, your pricing-option logic, or your membership pipelines. Your CRM decides what happens after a lead is captured. AnyCRM just delivers a clean event."
},
{
"num": "S.03",
"title": "Drop the AI Receptionist on your phone line and your site",
"body": "Forward your studio's number to the AI Receptionist's number and paste the chat widget into your site. The same AI Receptionist (same staff, same Mindbody site, 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 Mindbody's Messenger[ai] + Online Booking widget + Branded Web?",
"body": "Mindbody's own Messenger[ai] is a chat-based AI assistant that responds to missed calls with a text-back conversation, plus webchat and SMS on the studio's behalf. It is excellent at the post-miss recovery step, but it does not actually pick up the live phone call as a voice agent. The Online Booking widget and Branded Web are excellent at the steps AFTER a client has chosen to come to you via your website. None of them pick up the phone in real time. A new caller at 9pm gets a missed call followed by a text-back, not a live booking conversation. A form sits in the submissions queue until someone reads it. The AI Receptionist is the layer BEFORE all of that. It picks up the call (on voice, not via SMS), asks the right qualifying questions, books the session as a native Mindbody appointment on the right staff member's calendar at the right location, writes a clean, attributed client (with the source set to AI Receptionist Call or AI Receptionist Web and a call summary as the first note), AND sends the same lead event straight into your CRM's downstream business logic plus your ad platforms server-side. So your Mindbody workflows, your analytics, and your Google / Facebook Ads bidding all start optimising on a real conversation, not a missed call recovered via text."
},
"enrichmentSummary": "Every tool the AI Receptionist calls is an opinionated wrapper inside AnyCRM. AnyCRM does the messy work for you. Dedup, home-location resolution, session-type-to-staff matching, timezone math, association labels, 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 Mindbody internals.",
"enrichmentExamples": [
{
"title": "Capturing a new inquiry",
"raw": "Writing a client straight into Mindbody looks simple. But Mindbody does not dedup for you, and the API has hard requirements that aren't obvious. Send the same caller with a slightly different email casing or a phone-only inquiry and Mindbody creates a second client with a new identifier, silently. There is no merge endpoint exposed in the Public API for cleanup. Home location defaults to a placeholder site if you don't pass one, which then causes appointment-creation calls to fail later because that placeholder has no staff. Search behaves differently across email vs partial name: a partial match returns multiple clients in priority of last name, not exact-match, so naive code books the wrong client when two callers share a surname. And nothing in raw Mindbody fires a server-side conversion event to your ad platforms, so call-driven and chat-driven leads never get optimised for.",
"mcp": "createOrUpdatesMindbodyContact accepts name, email, phone, note, plus the inferred home location. AnyCRM searches Mindbody on the full email first, then on the full mobile, filters to exact matches, and only creates a new client when no match exists, with the right home location attached. The note is appended to the client's account after creation so the studio's front desk sees the call summary on the client's profile. AnyCRM also sends the lead event straight into your CRM (with source AI Receptionist Call or AI Receptionist Web), AND fires a server-side conversion event into your ad platforms using the origin of your registered domain. All in one AnyCRM call."
},
{
"title": "Booking the session",
"raw": "Creating a Mindbody appointment looks like one call. But the booking write requires the session type, the staff member, the location, the client, and the start time all together, and the session type MUST be one the staff member actually offers. Mindbody returns an unhelpful error if the staff member doesn't have that session type on their bookable list. Start times are local studio time (not UTC, not the caller's time) and have to align with the staff member's working hours and the session-type increment. Duration is not a parameter, it's inherited from the session type and can only be overridden with admin credentials. And the appointment doesn't auto-deduct from the client's pricing option, so naive code books a session the client can't actually pay for.",
"mcp": "createMindbodyContactAppointment takes email, scheduled_datetime (a naive date and time, no offset needed), invitee_timezone, and session_type_id. AnyCRM resolves the right staff member from our roster (filtered by which staff members actually offer that session type at that location and are currently active), converts the naive datetime to studio local time, snaps it to the session-type increment, builds the payload with all required fields, links the matching pricing option if the studio runs pay-at-booking, sends the same lead event straight into your CRM with the booking context, fires the server-side conversion event into your ad platforms, and returns both local and UTC start times in the response."
},
{
"title": "Cancelling with a reason",
"raw": "Mindbody splits cancellation across two completely different endpoints depending on whether you're cancelling an appointment or a class visit. Neither endpoint has a reason field, neither writes to the client's timeline automatically, and the late-cancel-fee logic depends on the studio's policy settings. A naive integration that deletes anything either fails outright (Mindbody doesn't support a true delete on appointments) or bypasses the late-cancel-fee policy, which the front desk then has to argue about with the client.",
"mcp": "cancelMindbodyAppointment takes email and reason. AnyCRM resolves the soonest upcoming booking (appointment OR class visit), picks the correct endpoint based on the booking type, writes the reason as a note on the client's account, applies the studio's late-cancel-fee policy automatically through Mindbody's own engine if the booking is inside the window, and returns the cancelled booking and the recorded reason so the AI Receptionist can read it back to the caller. All in one AnyCRM call. No deletion, full audit trail, booking stays in the visit history and in the staff member's reporting."
}
],
"alignmentSummary": "Every AnyCRM tool for Mindbody follows the same AI-alignment contract, so the AI Receptionist never has to think about transport:",
"alignment": [
"Naive datetimes in, Mindbody-native shape out. The AI Receptionist passes 2026-05-15T11:00:00 and a timezone string. AnyCRM converts it to studio local time and snaps to the session-type increment.",
"Email is the identity. Cancel and reschedule never need an appointment ID at the AI Receptionist layer. Email and soonest-upcoming resolves inside AnyCRM, across appointments AND class visits.",
"Session types, staff, locations, and pricing options come from setup, not the LLM. The AI Receptionist can't book a session a staff member doesn't offer, can't invent a location, can't override a session type's duration, and can't promise a pricing option that doesn't exist for that client. The values are frozen at setup.",
"Existing clients are sacred. If the caller already exists in Mindbody, AnyCRM preserves their client record and home location. New clients only get created when no match exists by email or mobile.",
"Cancellation is a status change, not a deletion. Mindbody's idiom is preserved so reporting, late-cancel policy, and the studio's visit-history view all stay accurate.",
"Every lead event leaves AnyCRM in two places at once. Your CRM gets the lead event so your business logic can run. Your ad platforms get the server-side conversion event so bidding optimises against real conversations. Both happen on the same AnyCRM call. No race conditions, no missing events.",
"Flat, deterministic shapes. Every AnyCRM response has the same top-level keys across every tool, so the AI Receptionist's prompt never grows with edge-case branching.",
"Errors are messages, not codes. An error from Mindbody becomes a one-sentence reason the AI Receptionist can repeat to the caller without translation.",
"Idempotent reschedules. If a reschedule fails mid-flight, the original Mindbody appointment is preserved. The customer never ends up with nothing."
],
"industryLine": "Currently running for yoga and pilates studios, boutique gyms, massage and wellness spas, personal-training studios, and martial-arts schools. Anyone whose schedule is in Mindbody but whose front desk can't pick up every phone call.",
"teamsSetup": {
"headline": "Multi-staff setup. Team roster, services & system-prompt assembly",
"body": "If you run more than one staff member on Mindbody, AnyCRM imports the team roster once, you link each staff member to the session types and locations they actually cover, 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 team roster on every call. It already knows who teaches what at which location.",
"steps": [
"Team roster import. AnyCRM imports your Mindbody staff once and writes each one into its database keyed by crm_user_id (with name, role, expertise, languages, timezone, Mindbody staff record, and per-location assignments).",
"Per-staff session types and classes. For each staff member AnyCRM resolves the session types they actually offer, the classes they teach, and the duration per session type. One call per person, cached.",
"Service visibility. Each session type is flagged Public, Private or Ignored. The AI Receptionist only routes to and books on Public services. You toggle this in the AnyCRM dashboard without re-deploying.",
"Lead-event receiving flow inside your CRM. During onboarding we wire up the flow inside your CRM that receives lead events from AnyCRM. That's where your membership-creation and contract-assignment policy lives. AnyCRM doesn't try to own it.",
"System-prompt assembly. The cached team roster, session-type, and class 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 studio before it reads its own instructions.",
"Runtime stays minimal. On a live call the AI Receptionist makes at most one availability call and one booking call. Never a team roster lookup. Updates to staff, services, or classes re-run the cache. The AI Receptionist picks them up on its next deploy."
],
"note": "The end result: the AI Receptionist can match \"I want a 60-minute prenatal massage with someone who has Wednesday evenings\" → the staff whose bookable services include prenatal-massage-60 and whose expertise tags include prenatal → that staff member's availability at the right location → a booked Mindbody appointment on that staff member's schedule → a lead event delivered straight into your CRM → a server-side conversion event in your ad platforms. Without a single team roster query during the call."
}
},
"privacy": {
"headline": "Your Mindbody data passes through AnyCRM. It doesn't stick.",
"lede": "AnyCRM processes your Mindbody data to answer the call. Then forgets it. The only thing AnyCRM persists is a conversation history ID so the AI Receptionist can recognise a returning caller. Clients, appointments, class visits, staff schedules, pricing options. All of it stays in Mindbody, owned by your Mindbody site.",
"cards": [
{
"kind": "stored",
"label": "What AnyCRM stores",
"body": "Conversation history IDs only. So the AI Receptionist can pick up where it left off if a caller hangs up and rings back. No call audio, no transcripts of client records, no caller PII."
},
{
"kind": "not-stored",
"label": "What AnyCRM doesn't",
"body": "Caller names, emails, phone numbers, Mindbody client identifiers, your staff roster, your session types, your class schedule, your pricing options, your visit 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": "In your Mindbody site and in whatever systems your CRM's flow forwards lead events to. Clients, appointments, class visits, notes all live in Mindbody. Source-attributed (always AI Receptionist Call or AI Receptionist Web), attributed to AnyCRM in the audit log, revocable. AnyCRM does not build a shadow scheduler alongside yours."
},
{
"kind": "revoke",
"label": "Revocation",
"body": "Revoke AnyCRM's integration from your Mindbody site's Integrations panel 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": "Mindbody's Public API uses per-site activation with scoped endpoint access. AnyCRM only touches the smallest set of endpoints required for the booking lifecycle. Nothing for payments beyond pricing-option checkout, nothing for analytics, nothing for marketing campaigns.",
"scopes": [
"Clients (read + write). Search, create, and annotate clients (the lead-capture work).",
"Appointments (read + write). Read availability and write appointments on the routed-to staff member's schedule (the booking work).",
"Classes (read + write). Enroll clients into classes and resolve class visits for the lifecycle endpoints.",
"Staff, session types, locations, pricing options (read-only). Roster, services, locations, and pricing options at setup time.",
"Not requested: payment-method tokenization beyond the studio's existing pricing-option checkout flow, contract management, autopay schedules, marketing campaign data, retail inventory, your other integrations."
],
"surfaceNote": "Same Mindbody-approved partner credentials any approved integration uses. Just a smaller surface. AnyCRM holds the partner credentials and per-site activation tokens (every write is signed with AnyCRM's partner credentials, so each booking and client change is attributable to AnyCRM in Mindbody's audit trail). The LLM never sees the credentials, and every tool call is logged with the operation name, never the raw payload."
},
"failureModes": [
{
"title": "Duplicate client records",
"raw": "Mindbody does not dedup for you. The Public API will happily create a second client for the same caller (same email, same mobile, different identifier), and there is no merge endpoint exposed for cleanup. My AI Front Desk runs Mindbody through Code by Zapier and Webhooks (its own documentation explicitly admits \"No official Zapier app; use Webhooks + Public API\") — meaning the \"Add Client\" step is a single Custom Request that either skips the client-search step entirely or relies on Zapier's exact-match dedup. Same caller, slightly different casing? Duplicate. Phone-only inquiry? Duplicate. Goodcall writes through a connector that does the same single-step create against the Mindbody API with no published structural guarantee about dedup-before-write. Smith.ai's integration is described as \"share your Mindbody calendar link\" — the human receptionist (or AI tier) then books on your calendar without owning the dedup discipline at the API level. 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 Mindbody on a normalised lowercased + trimmed email, then on a normalised mobile, then decides whether to update the existing client or create a new one. A returning caller lands on the existing record with a new note on the account, never as a duplicate. This costs us an extra API call per client-create. We do it anyway, because the alternative is the duplicate-client mess Smith.ai, My AI Front Desk, and Goodcall users live with. We do two checks where Smith.ai / My AI Front Desk / Goodcall do one.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Partial-match search returning the wrong client",
"raw": "Mindbody's client-search behaves differently for full email vs partial name. A search on a partial name returns every client whose first name, last name, or email contains that string, ordered by last name rather than by exact match. My AI Front Desk's Zapier-style Custom Request to Mindbody's search endpoint passes whatever string the AI generates and takes the first result. Goodcall's connector does the same single-step search-and-pick. Smith.ai's human receptionists rely on the receptionist scrolling the result list and picking the right person, which is fine on a Tuesday morning and less reliable on a Friday at 8pm with a relief receptionist. Any of these will book the wrong client when two callers share a surname.",
"mcp": "AnyCRM always passes the full email or full mobile as the search term (never partial name), then filters the response to exact-match on the original field before picking a winner. If multiple exact matches come back, AnyCRM surfaces the conflict so the AI Receptionist asks one disambiguating question instead of guessing. Smith.ai / My AI Front Desk / Goodcall can't do this because their architecture is one-shot.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Booking a session type the staff member doesn't offer",
"raw": "Mindbody returns an error if the requested session type isn't on the picked staff member's bookable list, but the error message is unhelpful and the staff member's actual session types live behind a separate read. My AI Front Desk's Zapier-style \"Book Appointment\" Custom Request posts whatever the AI generates straight at Mindbody's appointment endpoint — its own docs admit there's no \"check the staff member actually offers that session type first\" step in a Zapier path; it's a single Custom Request. So the AI Receptionist promises a 60-minute deep tissue with Sarah, Sarah doesn't have that session type on her bookable list, and the call ends with \"sorry, I couldn't actually book that.\" Goodcall's connector hands the booking through with the same single-step approach. Smith.ai's human receptionists or AI tier book on the calendar link without owning the session-type-to-staff matching at the API level.",
"mcp": "AnyCRM resolves the right staff member from the AnyCRM team roster, filtered by which staff actually offer the requested session type at the requested location and are currently active. If no staff member at that location offers that session type, AnyCRM surfaces the conflict before the booking attempt. Instead of producing a Mindbody error the AI Receptionist has to apologise for. We do three checks where Smith.ai / My AI Front Desk / Goodcall do one.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Inventing session types, locations, or pricing options that don't exist",
"raw": "Mindbody's session types, locations, and pricing options are all account-specific. The actual values differ from studio to studio. My AI Front Desk's Zapier-style Custom Request takes whatever the AI generates and posts it. There is no \"read your studio's real session-type list first\" step in a Zapier path; it's a single action. So the AI invents a service name like \"60-minute deep tissue with hot stones\" that doesn't map to any real session type, quotes a location that's actually a sister studio, or promises a pricing option that doesn't exist for that client. The write fails (or worse, succeeds silently with the wrong value), and the front desk untangles it later. Goodcall's connector hands values through to Mindbody the same way. Smith.ai's receptionists work from a playbook that drifts out of date as your real studio configuration evolves.",
"mcp": "AnyCRM reads your studio's real session types, locations, and pricing options at setup, and bakes them into the AI Receptionist's system prompt as a frozen table. So when the AI Receptionist captures a booking, it CAN ONLY pick from values that actually exist in your Mindbody site. This is several API calls at setup time that Smith.ai, My AI Front Desk, and Goodcall don't make. And it's the difference between writes that always succeed and writes that silently rot your reporting.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Booking the wrong staff member's schedule",
"raw": "Mindbody happily accepts any staff member on an appointment, including inactive staff or staff who don't work at that location on that day. My AI Front Desk's Zapier-style Custom Request takes whichever staff name the AI generates and posts it. No \"is this person still active?\" check, no \"does this person work at this location on this day?\" check. So an evening prenatal massage gets booked on a staff member who's on leave, or at a location where they don't have working hours. Goodcall's scheduler hop assigns based on connector defaults rather than the lane the call actually belongs to. Smith.ai's human receptionists rely on the receptionist's memory of who teaches what at which location, which falls apart with a relief receptionist.",
"mcp": "AnyCRM does the heavy work in multiple steps: matches the service from the call's intent, looks up the right staff member from the AnyCRM team roster, filters out inactive staff, cross-checks per-location assignments, AND validates working hours before writing. The AI Receptionist can't book on a schedule that isn't currently rostered for that service at that location. We do four checks where Smith.ai / My AI Front Desk / Goodcall do one.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Cancelling by deletion instead of by status change, bypassing the late-cancel policy",
"raw": "Mindbody's idiom is to flag the booking cancelled as a status change, not delete it, so it stays queryable in reporting and the visit history. And the late-cancel-fee policy only fires automatically through Mindbody's engine if the cancellation goes through the right endpoint with the right parameter. My AI Front Desk's Zapier-style cancel action (where it exists at all) issues a single Custom Request that doesn't model the late-cancel policy. Cancellations bypass Mindbody's late-cancel engine, the fee never fires, and the front desk realises after the fact. Goodcall's cancellation goes through its scheduler, not the Mindbody appointment, so the scheduler is updated but the Mindbody visit history never reflects the cancellation reason or the policy. Smith.ai's human receptionists ask the caller why, but the cancellation lands as a note rather than as a properly status-flagged booking with the policy fired, so reporting doesn't count it correctly.",
"mcp": "AnyCRM's cancellation is multi-step: find the soonest upcoming booking (appointment OR class visit), capture the caller's reason, write the reason onto the client's account as a note, AND flag the booking cancelled the Mindbody-native way through the right endpoint with the late-cancel-policy parameter set so the fee fires through Mindbody's own engine. Three operations where Smith.ai / My AI Front Desk / Goodcall do one (and usually the wrong one).",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Mixing up appointments and class visits",
"raw": "Mindbody splits 1:1 sessions (appointments) and group sessions (class visits) into two completely different object families with different identifiers, different create endpoints, and different cancel endpoints. My AI Front Desk's Zapier path picks one endpoint family at design time. A caller asking about \"my booking tonight\" gets \"I don't see anything\" if their booking happens to be on the other endpoint family. Goodcall's connector handles one or the other, not both in a single chronological view. Smith.ai's human receptionists scroll the Mindbody UI to find the right family, which works most of the time and breaks the rest. Either way, the customer hangs up thinking the studio lost their reservation.",
"mcp": "AnyCRM always queries both endpoint families in parallel and merges the results into a single chronological list. The AI Receptionist sees one upcoming-bookings array regardless of whether the caller booked a private session or a class. And reschedule / cancel routes to the right endpoint family automatically.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Encoding your membership and intro-pack policy in the prompt or in middleware",
"raw": "My AI Front Desk ships hardcoded \"Create Member\" / \"Sell Intro Pack\" actions that fire on every inbound call — and its own docs admit the integration runs on Code by Zapier with custom requests, so the policy is baked into the zap. There is no \"only sell the intro pack if the caller actually qualifies\" logic. Worse, the moment you change your pricing structure or add a new intro offer, you have to go back into Zapier and rebuild the zap. Goodcall's connector applies whatever default behaviour the underlying integration shipped with. Change your studio policy, and the connector keeps doing what it did six months ago. Smith.ai's AI tier and human receptionists work from playbooks that drift out of date as your real studio policy evolves.",
"mcp": "AnyCRM does not encode your membership or intro-pack policy at all. AnyCRM sends a clean lead event straight to your CRM, into the receiving flow we wire up for you at onboarding. YOUR flow decides what happens: new intro pack? Update the flow. New contract template? Update the flow. New source-tag scheme? Update the flow. AnyCRM's behaviour stays consistent because AnyCRM's job stops at the conversation. Smith.ai / My AI Front Desk / Goodcall can't separate these concerns because their architecture forces business policy into either Zapier middleware or a hardcoded action.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Web bookings and AI Receptionist bookings run on two separate conversion-tracking stacks",
"raw": "Smith.ai, My AI Front Desk, and Goodcall all treat phone and chat bookings as separate from web booking-widget conversions. 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 widget bookings, the bidding optimises for that (lower-intent) audience, your Cost per Lead looks deceptively low, ROAS reporting becomes a fiction, and the high-intent traffic that picks up the phone to ask about your intro pack 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 Smith.ai, My AI Front Desk, or Goodcall fail for yoga and pilates studios, boutique gyms, wellness spas, and personal-training studios that use Mindbody. And why AnyCRM can't.",
"lede": "Most AI Receptionists fail on Mindbody in the same handful of ways. Duplicate clients, partial-match search collisions, session-type-to-staff mismatches, invented session types and locations, wrong-schedule bookings, deletions that bypass the late-cancel policy, appointment-vs-class confusion, hardcoded intro-pack and membership 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 membership-creation and contract 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 Mindbody",
"columns": [
{ "key": "anycrm", "label": "AnyCRM" },
{ "key": "smithai", "label": "Smith.ai" },
{ "key": "myaifrontdesk", "label": "My AI Front Desk" },
{ "key": "goodcall", "label": "Goodcall" }
],
"rows": [
{
"capability": "Live Mindbody appointment or class enrollment booked DURING the call",
"anycrm": "Yes. Native Mindbody appointment or class visit, staff-matched, location-correct.",
"smithai": "Partial. \"Share your Mindbody calendar link\" — human receptionist books on your calendar.",
"myaifrontdesk": "Partial. Code-by-Zapier + Webhooks Custom Request (own docs admit \"no official Zapier app\").",
"goodcall": "Partial. Connector hop against the Mindbody API, not a guaranteed native write."
},
{
"capability": "Dedup-before-write on email and mobile (with exact-match filtering)",
"anycrm": "Yes. Always.",
"smithai": "Manual. Receptionist discipline, not an API invariant.",
"myaifrontdesk": "No. Single Custom Request with no published search-then-write step.",
"goodcall": "No published guarantee."
},
{
"capability": "Partial-match search resolves to the right client (no first-result-wins)",
"anycrm": "Yes. Full email / mobile, exact-match filtered.",
"smithai": "Manual. Receptionist picks from the result list.",
"myaifrontdesk": "No. Custom Request takes first result.",
"goodcall": "No structural guard."
},
{
"capability": "Preserves existing Mindbody client and home location on returning callers",
"anycrm": "Yes. Existing client is sacred.",
"smithai": "Implicit, not guaranteed.",
"myaifrontdesk": "No. Can overwrite or duplicate.",
"goodcall": "Depends on the underlying connector's defaults."
},
{
"capability": "Routes by service / specialist (session type + expertise + location)",
"anycrm": "Yes. Service-and-location matching is part of AnyCRM's team roster.",
"smithai": "Manual, depends on the receptionist.",
"myaifrontdesk": "No.",
"goodcall": "No."
},
{
"capability": "Session types, locations, pricing options frozen from your real Mindbody site",
"anycrm": "Yes. Read at setup, baked into the prompt as a frozen table.",
"smithai": "Not API-enforced.",
"myaifrontdesk": "No. Writes can fail on invented values.",
"goodcall": "No structural guard."
},
{
"capability": "Cancellation preserves the audit trail (status change, not deletion)",
"anycrm": "Yes. Mindbody-native cancellation.",
"smithai": "Manual.",
"myaifrontdesk": "No. Deletion strips the visit history.",
"goodcall": "No. Cancellation happens in the scheduler, not the Mindbody booking."
},
{
"capability": "Late-cancel-fee policy fires through Mindbody's own engine automatically",
"anycrm": "Yes. Policy parameter applied when the cancellation is inside the window.",
"smithai": "Manual.",
"myaifrontdesk": "No. Custom Request bypasses the policy parameter.",
"goodcall": "No."
},
{
"capability": "Reschedule in place (no cancel-then-rebook)",
"anycrm": "Yes.",
"smithai": "Manual.",
"myaifrontdesk": "No.",
"goodcall": "No."
},
{
"capability": "Appointments AND class visits merged into one chronological view",
"anycrm": "Yes. Both endpoint families queried in parallel.",
"smithai": "Manual UI scrolling.",
"myaifrontdesk": "No. Zap picks one family at design time.",
"goodcall": "No."
},
{
"capability": "Membership / intro-pack policy delegated to YOUR CRM's own flow",
"anycrm": "Yes. Lead event delivered straight into your CRM, into the receiving flow we wire up at onboarding.",
"smithai": "No. Policy lives in the receptionist's playbook.",
"myaifrontdesk": "No. Hardcoded \"Create Member / Sell Intro Pack\" action in Zapier.",
"goodcall": "No. Connector-default behaviour."
},
{
"capability": "Unified conversion pipe: web widget AND AI Receptionist → CRM + ad platforms server-side",
"anycrm": "Yes. Same shape, same source taxonomy, same server-side delivery to your CRM and your ad platforms.",
"smithai": "No. Web and voice run on separate stacks.",
"myaifrontdesk": "No. Web and voice run on separate stacks.",
"goodcall": "No. Web and voice run on separate stacks."
},
{
"capability": "Server-side conversion events sent to Google Ads, Facebook Ads, and analytics (origin = your registered domain)",
"anycrm": "Yes. Every call and chat lead lands server-side.",
"smithai": "No.",
"myaifrontdesk": "No.",
"goodcall": "No."
},
{
"capability": "Source attribution stays consistent across web and voice",
"anycrm": "Yes. AI Receptionist Call, AI Receptionist Web, plus your web widget identifiers.",
"smithai": "Manual / inconsistent.",
"myaifrontdesk": "No standardised taxonomy.",
"goodcall": "Whatever the underlying connector defaults to."
},
{
"capability": "Scale ceiling",
"anycrm": "Bounded by Mindbody API limits, not by staffing.",
"smithai": "Bounded by human receptionist staffing.",
"myaifrontdesk": "Bounded by Zapier rate limits and Custom Request contracts.",
"goodcall": "Bounded by the connector-and-sync 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 Mindbody site?",
"a": "Yes. AnyCRM uses Mindbody's official Public API under approved-partner credentials. Every captured caller lands as a Mindbody client with the right home location and a first note from the call. Sessions land as native Mindbody appointments on the right staff member's schedule, or as class visits in the right class. Same as a front-desk-booked session."
},
{
"q": "Will it create duplicate clients in Mindbody?",
"a": "No. AnyCRM resolves the existing client first (normalising email and mobile) before writing. A returning caller becomes a new note on the existing record, never a second client, and the existing home location is preserved."
},
{
"q": "Can it route different inquiries to different staff on my team?",
"a": "Yes. AnyCRM reads your Mindbody staff roster once at setup. Every active staff member, with the services they actually offer, expertise tags, languages, timezone, and per-location assignments. A massage caller, a yoga caller, and a personal-training caller each route to the right staff member at the right location, and existing client-to-staff preferences are always preserved."
},
{
"q": "Where do the bookings actually live, calendar or Mindbody?",
"a": "In Mindbody, as native appointments (for 1:1s) or class visits (for group sessions) on the right staff member's schedule. Mindbody's existing client-confirmation emails, contract assignments, and autopay drafts fire automatically. Same as a front-desk booking."
},
{
"q": "Can it cancel or reschedule a session from a phone call?",
"a": "Yes. The caller gives their email, AnyCRM finds the soonest upcoming booking across both appointments and class visits, the AI Receptionist reads it back, and AnyCRM either reschedules in place or flags the booking cancelled the Mindbody-native way. Applying your late-cancel-fee policy through Mindbody's own engine when the cancellation falls inside the window. Never a deletion that would strip the visit history."
},
{
"q": "What if a caller has two upcoming bookings in Mindbody?",
"a": "AnyCRM lists every upcoming booking for that client (service, staff, location, time) and the AI Receptionist asks which one to change before doing anything. It never assumes. And it merges appointments and class visits into one chronological list so the caller doesn't have to remember which one their booking is."
},
{
"q": "Does it handle timezones correctly?",
"a": "Yes. The AI Receptionist confirms the caller's country/timezone, AnyCRM books in the studio's local timezone (which is how Mindbody stores booking times internally), and the AI Receptionist reads the time back to the caller in their local timezone. No customer-facing UTC strings, no off-by-an-hour confirmations."
},
{
"q": "Does it create memberships or sell intro packs?",
"a": "Not directly. AnyCRM stays focused on the conversation surface: capturing the client, matching the right staff member, booking the session or class. Membership creation, contract assignment, and intro-pack offers are YOUR business policy, and that policy lives inside your CRM, in the receiving flow we wire up for you at onboarding. Every client-create and every booking in AnyCRM sends a lead event straight into that flow (tagged with source AI Receptionist Call or AI Receptionist Web). Your flow decides which welcome series, which intro pack, which contract template, which location workflow. AnyCRM doesn't try to encode policy that will drift out of date the moment your studio configuration changes."
},
{
"q": "How does the conversion tracking work?",
"a": "Every lead event AnyCRM produces (from a phone call, a chat conversation, OR a website booking widget) flows through a single conversion pipe. It lands in your CRM for business logic. AND it fires server-side into Google Ads, Facebook Ads, and your analytics platform, using the origin of the domain you registered with AnyCRM. Server-side means the conversion can't be blocked by ad-blockers and doesn't degrade under iOS / Safari tracking restrictions. The result: higher ROAS, lower ad costs, enriched analytics, and attribution that doesn't fragment between web and voice. As far as we can tell, none of our competitors have built this yet."
},
{
"q": "What about my existing website booking widget? Does it go through the same pipe?",
"a": "Yes. That's the whole point. Your web booking widget / class schedule embed AND the AI Receptionist produce the same lead-event shape with the same source taxonomy. They land in the same place in your CRM, and they fire the same server-side conversion event into your ad platforms. So your bid strategy optimises against unified, real conversions instead of fragmenting across web-only and voice-only stacks."
},
{
"q": "How is this different from Mindbody's own Messenger[ai]?",
"a": "Messenger[ai] is a great chat-based assistant for missed-call text-back, webchat, and SMS, and it's bundled as an add-on to Accelerate and Ultimate plans. It does not pick up the live phone call as a voice agent. The AI Receptionist with AnyCRM is the voice layer in front of Messenger[ai]. It picks up the live call, has the actual conversation, books the session as a native Mindbody record DURING the call, and feeds the unified conversion pipe into your CRM and your ad platforms. The two products are complementary, not redundant."
},
{
"q": "How long until it's actually capturing bookings into Mindbody?",
"a": "Most studios are live the same afternoon. The Mindbody activation step takes about five minutes. The staff and session-types and classes 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."
}
]
}