{
"icp": "solo and small-firm lawyers already running their practice on Clio Manage — litigation, family law, immigration, estate planning, and personal-injury firms whose intake calls land outside business hours",
"capabilities": {
"availability": {
"headline": "Captures the intake caller as a Clio Contact, books the consultation if there's real intent, and feeds one unified conversion pipe for your website forms AND your AI Receptionist.",
"lede": "Every caller who lands on the line becomes a Clio Contact (with the right responsible attorney and, when warranted, a Pending-status Matter on the right practice area). When they want a consultation, AnyCRM creates a native Clio Calendar Entry on the matched attorney's calendar. 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 caller becomes a Clio Contact, not a stray voicemail",
"body": "The AI Receptionist captures first name, last name, primary email, primary phone, the legal issue, and the practice area. Then AnyCRM writes the record into Clio as a Person-type Contact with the right responsible attorney attached and a call-summary Note on the Contact, DURING the call."
},
{
"num": "A.02",
"title": "Opens a Pending Matter when the intake warrants one. Conflict check stays a human step.",
"body": "When the caller's issue maps to a practice area your firm handles, AnyCRM opens a Pending-status Matter linked to the Contact, with the right practice area set and a description drawn from the call. Status only moves to Open when a paralegal or attorney clears the conflict in Clio's UI. AnyCRM can't create an Open Matter directly. That decision is reserved for a person."
},
{
"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 matter-intake rules. Every Contact-create and every Calendar Entry sends a lead event straight to your CRM (with source: \"AI Receptionist Call\" or source: \"AI Receptionist Web\") where YOUR business logic takes over. Run conflict check, advance the Matter, fire the intake workflow, send the engagement letter. We set up the receiving end inside your CRM for you during onboarding, tuned to your firm and your practice areas. AnyCRM doesn't get in the way of policy you've already encoded."
}
],
"apiSummary": "The AI Receptionist asks AnyCRM for availability against the attorneys on your roster and gets back open slots in the caller's timezone. No double bookings. Busy time on other Calendar Entries and Court Calendar Rules are respected. Every AnyCRM call prevents duplicate Contacts, optionally opens a Pending Matter, sets the responsible attorney (matched from your roster), writes the Calendar Entry so Clio's calendar sync to Google/Outlook fires automatically, 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": [
"getClioAvailability",
"createClioContactAppointment"
],
"curl1Path": "/mcp/tools/getClioAvailability",
"curl2Path": "/mcp/tools/createClioContactAppointment",
"pipeIntro": "Most law firms run two completely separate conversion-tracking stacks: one for the website (forms, chatflows, 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, the bidding optimises for the wrong audience, attribution is broken, and the high-intent intake call at 9pm is invisible to your marketing stack. 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 intake form / chatflow 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 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 practice area, which intake workflow, which engagement letter, which conflict-check queue. 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 signed clients (not just form-fill noise), your Facebook Ads campaigns see the high-intent traffic that picks up the phone, your analytics platform sees a single unified intake funnel, and attribution stops fragmenting between web and voice."
}
],
"outcomes": [
"Higher ROAS. Ad bidding optimises against actual intake conversations and booked consultations, not against the noisy subset of leads that happen to fill a form.",
"Lower ad costs. Once Google Ads and Facebook Ads learn what a real legal lead looks like, they stop spending against lookalikes of low-quality form-fills.",
"Enriched analytics. Every intake surface (web form, 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 prospect 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.",
"One source of truth for intake policy. Your CRM's flow owns matter-opening, conflict-check routing, and engagement letters. 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 Matter is opened, what status it lands in, and which intake fields to populate. That approach breaks the moment your firm's practice mix 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 practice areas, 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 for a small firm trying to know whether its Ads are actually working."
},
"adsConversionLift": {
"headline": "Turns every intake 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 your firm runs paid Ads on Google, Facebook, or LinkedIn (and most personal-injury, family-law, and immigration practices do), here is the uncomfortable truth: those platforms only get smarter when they see real conversions. Today, a website intake form-fill counts. A real phone call from a prospect who picked up the phone at 7pm after seeing your Ad does NOT count. So Google bids harder on the audience that fills forms (often the cheaper, lower-intent one) and ignores the audience that actually calls a lawyer. 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 intake form-fills. That's why your Cost per Lead looks low but your retained-client rate doesn't move. The high-intent prospect is calling you instead of filling a form, 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 filling out forms. In practice this means: Cost per Lead drops because you stop overpaying for low-intent form-fills; Return on Ad Spend goes up because the Ads now find people closer to ready-to-retain; and Customer Acquisition Cost shrinks because more of your Ad budget reaches prospects who will actually sign an engagement letter."
},
{
"num": "1b.03",
"title": "The same pipe carries your website intake 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 intake forms and chatflows through the same pipeline. So a prospect from a Google Ad that fills the intake form on your website AND a prospect from a Facebook Ad that called the AI Receptionist three days later both end up tagged, attributed, and counted the same way. Your Ads platform stops double-counting, your analytics stop fragmenting, and your firm stops being half-blind to where its retained clients actually came from."
}
],
"apiSummary": "Every Contact-create and Calendar Entry fires through AnyCRM's Conversion Lift pipeline. The lead event lands inside your CRM for business logic (matter-opening, conflict check, engagement letter), 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 intake forms run 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 form-fillers, and start finding the audience that picks up the phone to call a lawyer.",
"Return on Ad Spend (ROAS) goes up. Because the Ads now optimise toward intake conversations that actually convert into signed engagement letters, not toward whichever cheap audience generates the most form submissions.",
"Customer Acquisition Cost (CAC) shrinks. Because a higher share of every Ad dollar reaches prospects ready to talk to your AI Receptionist (and then your intake attorney).",
"Analytics get a complete intake funnel. Web and voice leads sit side by side, with the same source taxonomy. You stop seeing \"50% of retained clients: unknown source.\"",
"Attribution stops fragmenting. A prospect who first clicked a Google Ad, then called the firm three days later, finally shows up correctly attributed. Today, that prospect is invisible to your Ads stack.",
"You finally know if Ads are working. Most small firms cannot honestly tell you whether their Google or Facebook spend is profitable. With AnyCRM's Conversion Lift, you can."
],
"plainEnglishExample": "Imagine your firm spends $5,000/month on Google Ads targeting personal-injury keywords. Today, you see 80 intake-form fills and assume that's the full picture. With AnyCRM running, you'll also see (say) 60 phone calls and 45 web chats the AI Receptionist handled, all flowing into Google Ads as real conversions. Suddenly Google sees 185 intake conversions a month instead of 80. It re-trains on that bigger, better signal. Within weeks, the bidding finds you more of the right kind of prospect. Same $5,000 spend, more real consultations booked, lower Cost per Lead, more signed retainers. That is what \"AI Receptionist with AnyCRM\" actually means for the bottom line. Not just \"it answers the phone after hours.\"",
"tools": [
"createOrUpdatesClioContact",
"createClioContactAppointment"
]
},
"lifecycle": {
"headline": "Manages the full consultation lifecycle inside Clio for anyone calling or chatting.",
"lede": "Every \"push the consult to Thursday\" or \"actually, I need to cancel\" lands with the AI Receptionist instead of in your inbox. AnyCRM reschedules update the existing Clio Calendar Entry in place. Cancellations follow Clio's own best practice. The Calendar Entry stays on the linked Matter with the caller's reason captured as a Note. Instead of issuing a DELETE that erases the audit trail your firm's billing, conflict, and ethics review depend on, you get crystal clarity on when a Calendar Entry was created, and when and why it was updated by your AI Receptionist.",
"cards": [
{
"num": "B.01",
"title": "Finds the consultation by email in a single step without needing a Calendar Entry ID",
"body": "Callers DO NOT quote Clio Calendar Entry IDs over the phone. We've tested with hundreds of callers and each time they were asked 'Can you tell me the meeting 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 Calendar Entry linked to the matching Contact. And the AnyCRM response forces the AI Receptionist to be human. It reads back the summary, date, time, linked Matter, and responsible attorney before changing anything."
},
{
"num": "B.02",
"title": "Reschedules in place and keeps the Matter link intact",
"body": "Rescheduling updates the existing Calendar Entry in a single confirmation. No cancel-then-rebook round-trip means the Matter link, the time-entry history, and the calendar invite all stay intact. Failed reschedules leave the original Calendar Entry untouched."
},
{
"num": "B.03",
"title": "Cancels without erasing the audit trail",
"body": "When a caller cancels, AnyCRM flags the Calendar Entry cancelled the way Clio's reporting expects and writes the caller's reason as a Note on the linked Matter (falling back to the Contact if no Matter yet), instead of deleting the entry and stripping WHY the consultation fell through. This lets you intuitively track changes for Clio Calendar Entries created or updated by your AI Receptionist."
}
],
"apiSummary": "AnyCRM's search, reschedule, and cancel all accept just an email. The soonest upcoming Calendar Entry linked to the matching Contact is resolved inside AnyCRM. No Calendar Entry IDs at the AI Receptionist layer.",
"tools": [
"searchClioAppointments",
"rescheduleClioAppointment",
"cancelClioAppointment"
],
"curl1Path": "/mcp/tools/searchClioAppointments",
"curl2Path": "/mcp/tools/rescheduleClioAppointment",
"curl3Path": "/mcp/tools/cancelClioAppointment"
},
"routing": {
"headline": "Routes every intake to the right attorney. And maintains the existing responsible attorney on the Matter instead of randomly reassigning to someone else.",
"lede": "Clio firms run on responsible attorneys, originating attorneys, and practice-area specialisation. At setup AnyCRM imports your Clio user roster into its database and enriches each attorney with practice areas, bar admissions, languages, timezone, and a bookable consultation type. The AI Receptionist then routes each intake to the attorney who actually handles that practice area. Existing Matter assignments in Clio are honoured as the source of truth.",
"cards": [
{
"num": "C.01",
"title": "Routes by practice area: family vs PI vs estate",
"body": "\"My husband filed for divorce\" routes to your family-law attorneys. \"I was rear-ended last week\" routes to PI intake. \"I need to update my will\" routes to estate planning. And the responsible attorney already on an active Matter is always preserved."
},
{
"num": "C.02",
"title": "Honours existing Matter assignments in Clio",
"body": "If a Contact already has an active Matter with a responsible attorney, the AI Receptionist routes back to that attorney. The Note, the Calendar Entry, and any follow-up Task all attach to the existing Matter. No orphaned duplicate, no client poached off a colleague's caseload."
},
{
"num": "C.03",
"title": "Matches fresh inbound callers to the right attorney on the team",
"body": "New prospects with no existing Clio Contact get matched to an attorney on the practice area you've designated, honouring the criteria you set in AnyCRM for matching an intake to an attorney. The AI Receptionist doesn't fight the intake-distribution rule your firm already follows."
}
],
"apiSummary": "Team details live in AnyCRM's database, pulled once from Clio at setup, enriched with practice areas, bar admissions, languages, timezone, and consultation duration (valuable context for the AI Receptionist that Clio's user object doesn't carry by default). At runtime, one read of the team roster matches caller → practice area → attorney. New Contacts get assigned to the right attorney as the Matter's responsible attorney. Existing Matters keep theirs. AnyCRM does NOT cache your Matter statuses, your billing rates, or your trust-accounting policy. That policy stays inside your CRM, where it belongs.",
"tools": [
"listClioTeamMembers",
"getClioAttorneyProfile"
],
"curl1Path": "/mcp/tools/listClioTeamMembers",
"curl2Path": "/mcp/tools/getClioAttorneyProfile"
}
},
"setup": {
"headline": "Setup in 3 steps. Battle-tested on real Clio firms.",
"lede": "You connect Clio once. AnyCRM imports your attorney roster, your practice areas, your Matter statuses, and your custom fields. AnyCRM also wires up the receiving end inside your CRM so lead events from the AI Receptionist land where your intake workflow can act on them. Then the AI Receptionist starts capturing intakes and booking consultations the same afternoon. No middleware. No prompt-engineering by you.",
"steps": [
{
"num": "S.01",
"title": "Connect Clio (OAuth, 60 seconds)",
"body": "Authorize AnyCRM on your Clio account via the standard OAuth grant from your firm's regional Clio Identity endpoint (US, CA, EU, AU). AnyCRM scopes to the least amount of access needed for the intake-and-booking lifecycle. Nothing for trust accounting, nothing for billing, nothing for document management. You can always revoke permissions at any time from Settings → Apps & Integrations. Every update to your Clio 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 the roster. Lock in your practice areas. Wire up your CRM's lead-receiving flow.",
"body": "AnyCRM imports every active Clio user as a bookable attorney with practice areas, bar admissions, languages, timezone, and consultation duration. AnyCRM also freezes your practice-area and Matter-status values so the AI Receptionist can only open Matters that map to a practice area your firm actually handles (and only in Pending status), 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 intake workflow can act on them. AnyCRM does NOT replicate your conflict-check rules, your billing setup, or your engagement-letter automation. 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 firm's number to the AI Receptionist's number and paste the chat widget into your site. The same AI Receptionist (same roster, same Clio 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 Clio's Clio Grow + Scheduler?",
"body": "Clio Grow's intake forms and Scheduler links are excellent at the steps AFTER a prospect has chosen to come to your website. They don't pick up the phone. A new caller at 9pm gets a missed call, not a Contact record. The Scheduler runs only when the prospect clicks the link in your email signature. Clio Grow intake forms sit in the submissions queue until someone reads them. The AI Receptionist is the layer BEFORE all of that. It picks up the call, asks the right intake questions (jurisdiction, opposing party, statute timing), books the consultation as a native Clio Calendar Entry on the right attorney's calendar, writes a clean Contact (with the source set to AI Receptionist Call or AI Receptionist Web and a call-summary Note), AND sends the same lead event straight into your CRM's downstream intake workflow plus your ad platforms server-side. So your Clio intake workflow, your analytics, and your Google / Facebook Ads bidding all start optimising on a real conversation, not a name and a voicemail."
},
"enrichmentSummary": "Every tool the AI Receptionist calls is an opinionated wrapper inside AnyCRM. AnyCRM does the messy work for you. Dedup, practice-area resolution, Matter-status mapping, custom-field ID lookup, timezone math, calendar-owner resolution, 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 CRM internals.",
"enrichmentExamples": [
{
"title": "Capturing a new intake",
"raw": "Writing a Contact straight into Clio looks simple. But Clio doesn't dedup for you on either email or phone. Send the same caller with a slightly different email casing or a phone-only inquiry, and you end up with two Contacts with two different responsible attorneys and two truncated intake histories. Practice area carries its own gotcha. Clio treats it as an ID reference (not free text), so a free-text \"family law\" string is silently dropped. Custom fields use account-specific IDs that differ by firm. Inbound-call source attribution has to be set when the Contact is created. And nothing in raw Clio fires a server-side conversion event to your ad platforms, so call-driven and chat-driven intakes never get optimised for.",
"mcp": "createOrUpdatesClioContact accepts name, email, phone, note, practice_area, matter_intent, plus the matched responsible attorney. AnyCRM handles dedup by normalised email then phone, picks the surviving Contact (or creates a Person-type Contact with the right shape), opens a Pending-status linked Matter when matter_intent is true, sets the responsible attorney, appends the Note, 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 consultation",
"raw": "Creating a Calendar Entry directly against Clio is a tight contract. The calendar owner has to be the attorney's personal Clio calendar (not the firm-wide or Court calendar), the time format has to be exactly what Clio accepts, and the Contact has to be on the attendees list so Clio's invite fires. Get any of these wrong and the entry writes into Clio but never lands on the attorney's actual Google/Outlook calendar. Skip the Matter link and the entry becomes orphaned from the case file your billable-time entries will eventually attach to.",
"mcp": "createClioContactAppointment takes email, scheduled_datetime (a naive date and time, no offset needed), invitee_timezone, and consultation_type. AnyCRM resolves the right attorney from the practice area, picks the attorney's personal Clio calendar as the owner, handles the timezone and duration math, builds the attendees list so the calendar invite fires, links the entry to the Pending Matter, 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": "Deleting a Calendar Entry in Clio strips it off the linked Matter entirely. No reason, no audit trail, no signal to the attorney of WHY it fell through. Clio's own best practice is to flag the entry cancelled instead of deleting it, so it stays queryable in reporting and on the Matter. Doing that cleanly takes several round-trips: read the entry, write a Note on the Matter with the reason, then update the entry.",
"mcp": "cancelClioAppointment takes email and reason. AnyCRM resolves the soonest upcoming Calendar Entry, writes the reason as a Note on the linked Matter (falling back to the Contact if no Matter exists), and flags the entry cancelled the Clio-native way. All in one AnyCRM call. No DELETE, full audit trail, the entry stays on the Matter and in the attorney's reporting."
}
],
"alignmentSummary": "Every AnyCRM tool for Clio follows the same AI-alignment contract, so the AI Receptionist never has to think about transport:",
"alignment": [
"Naive datetimes in, Clio-native shape out. The AI Receptionist passes 2026-05-15T11:00:00 and a timezone string. AnyCRM converts it into whatever shape Clio's Calendar Entry requires, on both start and end.",
"Email is the identity. Cancel and reschedule never need a Calendar Entry ID at the AI Receptionist layer. Email and soonest-upcoming resolves inside AnyCRM.",
"Practice area, Matter status, and custom-field IDs come from setup, not the LLM. The AI Receptionist can't invent a practice area or accidentally open an Open-status Matter. It inherits the values you configured at setup. Matter status starts at Pending so conflict check stays a human step.",
"Existing responsible attorneys are sacred. If a Clio Contact has an active Matter with a responsible attorney, AnyCRM preserves it. New intakes only get the matched attorney when no active Matter exists.",
"Cancellation preserves the audit trail. Clio's audit trail is load-bearing for billing, trust accounting, and ethics review. We never destroy it.",
"Every lead event leaves AnyCRM in two places at once. Your CRM gets the lead event so your intake workflow 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 Clio 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 Clio Calendar Entry is preserved. The client never ends up with nothing."
],
"industryLine": "Currently running for family-law practices, personal-injury firms, immigration attorneys, estate-planning solos, and small-firm litigators. Anyone whose caseload is in Clio but whose intake calls keep coming in after the last paralegal has logged off.",
"teamsSetup": {
"headline": "Multi-attorney setup. Team roster, practice areas & system-prompt assembly",
"body": "If you run more than one attorney on Clio, AnyCRM imports the roster once, you link each attorney to the practice areas they actually cover (family / PI / estate / immigration / criminal), 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.",
"steps": [
"Team roster import. AnyCRM imports your Clio attorneys once and writes each one into its database keyed by crm_user_id (with name, role, practice areas, timezone, calendar ID).",
"Per-attorney consultation types. For each attorney AnyCRM resolves the consultation types they actually book and the duration per type. One call per person, cached.",
"Practice-area visibility. Each practice area is flagged Public, Private or Ignored. The AI Receptionist only routes to and books on Public practice areas. 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 conflict-check and engagement-letter policy lives. AnyCRM doesn't try to own it.",
"System-prompt assembly. The cached team roster, practice-area, and consultation-type 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.",
"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 attorneys, practice areas, or consultation types re-run the cache. The AI Receptionist picks them up on its next deploy."
],
"note": "The end result: the AI Receptionist can match \"I need to talk to someone about a custody case\" → the family-law pool → that attorney's consultation type → that attorney's Clio calendar availability → a booked Calendar Entry on the right attorney's calendar with a linked Pending Matter → 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 Clio data passes through AnyCRM. It doesn't stick.",
"lede": "AnyCRM processes your Clio 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. Contacts, Matters, Calendar Entries, Notes. All of it stays in Clio, owned by your firm's Clio account, governed by the same data-residency rules (US, CA, EU, AU) your firm already chose at sign-up.",
"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 Contact records, no caller PII, no Matter content."
},
{
"kind": "not-stored",
"label": "What AnyCRM doesn't",
"body": "Caller names, emails, phone numbers, Clio Contact IDs, Matter content, your attorney roster, your practice areas, your custom fields, your trust-account or billing data. 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 Clio account and in whatever systems your CRM's flow forwards lead events to. Contacts, Matters, Calendar Entries, Notes all live in Clio. In your firm's chosen region (US/CA/EU/AU). Source-attributed (always AI Receptionist Call or AI Receptionist Web), attributed to AnyCRM in the audit log, revocable. AnyCRM does not build a shadow case-management system alongside yours."
},
{
"kind": "revoke",
"label": "Revocation",
"body": "Revoke the AnyCRM OAuth grant in your Clio account settings (Settings → Apps & Integrations) 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": "Clio uses OAuth 2.0 scopes. AnyCRM requests only the smallest set required for the intake-and-booking lifecycle. Nothing for trust accounting, nothing for billing, nothing for document management, nothing for intake-policy enforcement (that's your CRM's flow's job).",
"scopes": [
"Contacts (read + write). Read and write Contacts, dedup against existing records, set source attribution and intake details.",
"Matters (read + write). Open Pending-status Matters linked to Contacts so intakes live where your case management expects them.",
"Calendar Entries (read + write). Read availability and write entries on the right attorney's calendar; update to reschedule and to cancel-as-update.",
"Notes (read + write). Append call-summary Notes to the Contact and Matter so the next attorney to look at the record knows the intake conversation in full.",
"Users (read). Read your attorney roster at setup so the AI Receptionist knows who exists and who handles which practice area.",
"Practice areas & custom fields (read). Read your firm's practice-area list and custom-field IDs at setup, so AnyCRM writes only valid values.",
"Not requested: trust-account data, bills and invoices, time entries, expense entries, documents, secure messages, Clio Grow form submissions, your other integrations."
],
"surfaceNote": "Same OAuth grant any Clio app from the Clio App Directory uses. Just a smaller surface. AnyCRM holds the access and refresh tokens (every write is signed by AnyCRM's connected-app credentials, so each Contact, Matter, and Calendar Entry change is attributable to AnyCRM in Clio'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 Contacts",
"raw": "Clio doesn't dedup on either email or phone. Send the same caller with a slightly different email casing, or by phone alone, and you get a second Contact with a different responsible attorney and a different intake history. And Clio has no first-party merge endpoint. You have to manually re-link Matters from one Contact to the other through the UI. My AI Front Desk runs on a Zapier-style \"Create Matter / Update Contact\" action list. A single API call that hands the caller's email straight to Clio with no \"search-then-write\" step. Phone-only? Duplicate. Slightly different casing? Duplicate. Goodcall writes through a native connector and Zapier path that does the same single-step create. Smith.ai syncs the contact after the call through its native Clio integration that captures the call summary, name, email, phone, and call duration — but it isn't a search-then-write either; the contact is created and the duplicate sits there. None of these can do a true dedup-before-write because their architecture is one call in, one call out.",
"mcp": "AnyCRM does NOT do a one-shot create. AnyCRM first searches Clio on a normalised lowercased + trimmed email, then on a normalised phone, then decides whether to update the existing Contact or create a new one. A returning caller lands on the existing record with a new Note on the Matter, never as a duplicate. This costs us an extra API call per Contact-create. We do it anyway, because the alternative is the duplicate-Contact mess Smith.ai, My AI Front Desk, and Goodcall users live with.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Consultations that don't reach the attorney's real calendar",
"raw": "Writing a Calendar Entry to Clio looks like it creates a calendar event. And it does, but only inside Clio. Whether it actually syncs to the attorney's Google/Outlook calendar depends on the entry being assembled correctly. The right calendar owner (the attorney's personal Clio calendar, not the firm-wide or Court calendar), the right time format, the right attendees list. My AI Front Desk's Zapier-style \"Schedule Appointment\" action posts whatever it has straight at Clio. No checking the calendar-owner choice, no validating the attendees list, no confirming the attorney actually has a connected calendar. Goodcall's native connector / Zapier path doesn't write a Clio Calendar Entry as a first-class operation at all. It writes through a connected scheduler, and a separate sync tries to mirror it back into Clio. So the entry either doesn't exist in Clio, or exists but never syncs to Google/Outlook. Smith.ai's integration is built around syncing call summaries and contact information after the call. Booking the consultation is described as a separate manual step the attorney handles after the email summary. Either way, the attorney opens their calendar and the meeting isn't there.",
"mcp": "AnyCRM does multiple things in one call: resolves the attorney's personal Clio calendar from the roster, validates the time format Clio's calendar sync requires, populates the attendees list Clio's calendar invite expects, then writes the Calendar Entry. The consultation lands in Clio AND on the attorney's Google/Outlook calendar atomically. We do four checks where Smith.ai/My AI Front Desk/Goodcall do one. That's why a consultation booked through AnyCRM is never missing from the attorney's calendar.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Inventing practice areas and custom-field IDs that don't exist in your firm",
"raw": "Clio's practice areas, Matter statuses, and custom fields are all firm-specific. The actual values differ from firm to firm. My AI Front Desk's Zapier-style action takes whatever the AI generates and posts it. There is no \"read your firm's real practice-area values first\" step in a Zapier path; it's a single action. So the AI invents a value like \"Divorce\" when your firm's practice-area record is \"Family Law,\" the write fails (or worse, succeeds with the value silently dropped), and your intake reporting silently breaks. Goodcall's connector hands the value through to Clio the same way. Smith.ai's integration captures generic intake fields and call summary, not your firm-specific practice-area or custom-field IDs. The architecture is one-shot; there is no \"check the firm's real values first\" step.",
"mcp": "AnyCRM reads your firm's real practice areas, Matter statuses, and custom-field IDs at setup, in a separate call to Clio, and bakes them into the AI Receptionist's system prompt as a frozen table. So when the AI Receptionist captures an intake, it CAN ONLY pick from values that actually exist in your firm. This is two 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 attorney's calendar",
"raw": "Clio happily accepts any user on a Calendar Entry, including disabled users or attorneys without bar admission in the relevant jurisdiction. My AI Front Desk's Zapier action takes whichever attorney name the AI generates and posts it. No \"is this person still active?\" check, no \"does this person own the existing Matter?\" check. So a family-law intake gets booked on the PI attorney's calendar, or worse, on a no-longer-active partner's calendar. Goodcall's scheduler hop assigns based on connector defaults rather than the practice area the call actually belongs to. Smith.ai's human receptionists rely on receptionist memory of who handles what, with the booking happening as a separate manual step after the call summary email. 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 practice area from the call's intent, looks up the right attorney from the AnyCRM team roster, filters out disabled attorneys, AND checks whether the existing Clio Contact has an active Matter with a different responsible attorney. If the existing responsible attorney contradicts the inferred practice area, AnyCRM refuses to overwrite. Instead, the AI Receptionist surfaces the conflict so the call respects who is already on the Matter. Smith.ai/My AI Front Desk/Goodcall can't do this because their architecture is one-shot.",
"competitorsAffected": ["Smith.ai", "Goodcall", "My AI Front Desk"]
},
{
"title": "Cancelling by deletion instead of by outcome",
"raw": "Deleting a Calendar Entry from Clio strips it off the linked Matter entirely. No reason, no cancellation outcome, no audit trace. My AI Front Desk's Zapier-style cancel action (where it exists at all) issues a single DELETE — that's the only Clio operation Zapier exposes for it. The entry vanishes, the attorney gets no signal of WHY it fell through, and \"consultations booked vs cancelled\" reporting breaks because the entry no longer exists to be counted. Worse, if any pre-logged time entries had been written against the slot, your trust-accounting reconciliation gets confused. Goodcall's cancellation goes through its scheduler, not the Clio Calendar Entry. So the scheduler is updated but the Clio Matter never reflects the cancellation reason. Smith.ai receptionists ask the caller why, but the cancellation lands as a call summary rather than as a properly outcome-flagged Calendar Entry, so Clio's reporting doesn't count it correctly.",
"mcp": "AnyCRM's cancellation is multi-step: find the soonest upcoming Calendar Entry, capture the caller's reason, write the reason as a Note on the linked Matter, AND flag the entry cancelled the Clio-native way. The entry stays on the Matter, queryable in reporting, with the reason attached. 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": "Opening Matters past conflict check",
"raw": "Clio Matters can be created in any status, including Open, via a single Matter-create call. My AI Front Desk's Zapier-style \"Create Matter\" action defaults to Open status. There is no \"only open the Matter as Pending so conflict check still runs\" logic. The action is single-step. So every intake call becomes an Open Matter before any conflict check has run, exposing the firm to Rule 1.7 (conflict of interest) and Rule 1.18 (prospective-client confidentiality) problems. Goodcall's connector applies whatever default behaviour the underlying integration shipped with. Change your firm's intake workflow, and the connector keeps doing what it did six months ago. Smith.ai's human receptionists work from intake playbooks that capture the conflict-check fields, but routing them through a status discipline that keeps the Matter at Pending until a human clears the conflict is a manual step performed off-platform.",
"mcp": "AnyCRM only opens Matters in Pending status. Conflict check stays a human step. Status only moves to Open when a paralegal or attorney clears the conflict and updates the Matter in Clio's UI. The AI Receptionist cannot create an Open Matter directly. That decision is reserved for a person. Smith.ai/My AI Front Desk/Goodcall can't enforce this because their architecture forces every intake into the same single-step action.",
"competitorsAffected": ["My AI Front Desk", "Goodcall", "Smith.ai"]
},
{
"title": "Encoding your intake policy in the prompt or in middleware",
"raw": "My AI Front Desk ships hardcoded \"Create Matter / Generate Invoice / Log Time\" actions that fire on every inbound call. There is no \"only open the Matter if the caller is actually a prospective client and not a returning party\" logic. The actions are single-step, so every call becomes a Matter clogging your intake queue with unqualified records. Worse, the moment you change your conflict-check routine or add a new practice area, 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 firm, and the connector keeps doing what it did six months ago. Smith.ai's human receptionists work from intake playbooks that drift out of date as your real intake policy evolves.",
"mcp": "AnyCRM does not encode your intake 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 practice area? Update the flow. New conflict-check queue? Update the flow. New engagement-letter template? 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 leads and AI Receptionist leads run on two separate conversion-tracking stacks",
"raw": "Smith.ai, My AI Front Desk, and Goodcall all treat phone and chat conversions as separate from web intake-form / chatflow conversions. None of them fire a real conversion event into Google Ads, Facebook Ads, or LinkedIn Ads when the AI Receptionist closes an intake call. So your Ad platforms only see the website form-fills, the bidding optimises for that (lower-intent) audience, your Cost per Lead looks deceptively low, ROAS reporting becomes a fiction, and the high-intent prospect who 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 Smith.ai, My AI Front Desk, or Goodcall fail for family-law practices, personal-injury firms, immigration attorneys, estate-planning solos, and small-firm litigators that use Clio. And why AnyCRM can't.",
"lede": "Most AI Receptionists fail on Clio in the same handful of ways. Duplicate Contacts, consultations that never sync to the attorney's real calendar, invented practice areas and custom-field IDs, the wrong attorney's calendar, deletions that destroy the audit trail, Matters opened past conflict check, hardcoded intake 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 intake 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 Clio",
"columns": [
{ "key": "anycrm", "label": "AnyCRM" },
{ "key": "smithai", "label": "Smith.ai" },
{ "key": "myaifrontdesk", "label": "My AI Front Desk" },
{ "key": "goodcall", "label": "Goodcall" }
],
"rows": [
{
"capability": "Live Clio Calendar Entry booked DURING the call",
"anycrm": "Yes. Native Clio Calendar Entry, attorney-matched, calendar-synced, linked to a Pending Matter.",
"smithai": "No. Call summary logged; booking is a manual follow-up by the attorney.",
"myaifrontdesk": "Partial. Zapier-style \"Schedule Appointment\" without structural detail for calendar sync.",
"goodcall": "Partial. Scheduler hop, not a native Clio Calendar Entry."
},
{
"capability": "Dedup-before-write on email and phone",
"anycrm": "Yes. Always.",
"smithai": "No. Single-step create through native sync.",
"myaifrontdesk": "No. Zapier path has no search-then-write step.",
"goodcall": "No published guarantee."
},
{
"capability": "Preserves existing responsible attorney on returning callers",
"anycrm": "Yes. Existing Matter assignment is sacred.",
"smithai": "Implicit, not guaranteed.",
"myaifrontdesk": "No. Can overwrite.",
"goodcall": "Depends on the underlying connector's defaults."
},
{
"capability": "Routes by practice area (family / PI / estate / immigration)",
"anycrm": "Yes. Practice area is part of AnyCRM's team roster.",
"smithai": "Manual, depends on the receptionist.",
"myaifrontdesk": "No.",
"goodcall": "No."
},
{
"capability": "Practice areas, Matter statuses & custom fields frozen from your real Clio values",
"anycrm": "Yes. Read at setup, baked into the prompt as a frozen table.",
"smithai": "Not API-enforced.",
"myaifrontdesk": "No. Writes can fail on unknown values.",
"goodcall": "No structural guard."
},
{
"capability": "Cancellation preserves the audit trail (outcome-flagged + Note on Matter, not deleted)",
"anycrm": "Yes. Clio-native cancellation.",
"smithai": "Manual.",
"myaifrontdesk": "No. DELETE strips the Matter.",
"goodcall": "No. Cancellation happens in the scheduler, not the Clio entry."
},
{
"capability": "Reschedule in place (no cancel-then-rebook)",
"anycrm": "Yes.",
"smithai": "Manual.",
"myaifrontdesk": "No.",
"goodcall": "No."
},
{
"capability": "Matter opened only as Pending; conflict check stays a human step",
"anycrm": "Yes. Only Pending Matters; Open requires a person.",
"smithai": "Manual; conflict-check fields captured but not status-enforced.",
"myaifrontdesk": "No. Zapier \"Create Matter\" defaults to Open.",
"goodcall": "No. Connector-default behaviour."
},
{
"capability": "Intake / matter-opening 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 training and email summaries.",
"myaifrontdesk": "No. Hardcoded \"Create Matter / Generate Invoice\" actions.",
"goodcall": "No. Connector-default behaviour."
},
{
"capability": "Unified conversion pipe: web forms 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 intake 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 form identifiers.",
"smithai": "Manual / inconsistent.",
"myaifrontdesk": "No standardised taxonomy.",
"goodcall": "Whatever the underlying connector defaults to."
},
{
"capability": "Scale ceiling",
"anycrm": "Bounded by Clio API limits, not by staffing.",
"smithai": "Bounded by human receptionist staffing.",
"myaifrontdesk": "Bounded by Zapier rate limits and action contracts.",
"goodcall": "Bounded by the scheduler-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 Clio account?",
"a": "Yes. AnyCRM uses Clio's official API via a standard OAuth grant against your firm's regional Clio Identity endpoint (US, CA, EU, AU). Every captured caller lands as a Person-type Contact with the right responsible attorney and a first Note from the call. Consultations land as native Clio Calendar Entries on the right attorney's calendar, linked to a Pending-status Matter so the case file is ready before the conflict check."
},
{
"q": "Will it create duplicate Contacts in Clio?",
"a": "No. AnyCRM resolves the existing Contact first (normalising email and phone) before writing. A returning caller becomes a new Note on the existing record, never a second Contact, and the responsible attorney already on any active Matter is preserved."
},
{
"q": "Can it route different intakes to different attorneys?",
"a": "Yes. AnyCRM reads your Clio user roster once at setup. Every active attorney, with their practice areas, bar admissions, default consultation type, and timezone. Family-law, personal-injury, estate, immigration, and criminal intakes each route differently, and existing Matter assignments in Clio are always preserved."
},
{
"q": "Will it open Matters before I've run a conflict check?",
"a": "No. AnyCRM only opens Matters in Pending status. Conflict check stays a human step. The Matter moves to Open only when a paralegal or attorney clears the conflict in Clio's UI. The AI Receptionist cannot create an Open Matter directly. That decision is reserved for a person."
},
{
"q": "What about Clio Manage AI (formerly Clio Duo)? Does this replace it?",
"a": "No. They solve different problems. Clio Manage AI works inside Clio on your existing matter data (extracting deadlines from court documents into calendar events, drafting invoices, composing client correspondence, organising matter files). It doesn't pick up the phone. AnyCRM is the layer BEFORE that. We answer the inbound intake call at 9pm, capture the caller as a Contact, open a Pending Matter on the right practice area, book the consultation, and send the lead event into your CRM and your ad platforms. The two are complementary. AnyCRM populates the matter; Clio Manage AI helps the attorney work on it afterwards."
},
{
"q": "Where do the consultations actually live, calendar or Clio?",
"a": "Both. AnyCRM writes the consultation as a native Clio Calendar Entry with the attorney's personal Clio calendar as the owner and the Contact on the attendees list. Which makes Clio's Google/Outlook calendar sync fire automatically. You see one Calendar Entry on the linked Matter, one calendar invite on the attorney's calendar, one source-attributed Contact."
},
{
"q": "Can it cancel or reschedule a consultation from a phone call?",
"a": "Yes. The caller gives their email, AnyCRM finds the soonest upcoming Calendar Entry linked to the matching Contact, the AI Receptionist reads it back, and AnyCRM either reschedules in place or flags the entry cancelled the way Clio's reporting expects (with the reason captured as a Note on the linked Matter). Never a DELETE that would strip the audit trail your firm's billing and trust-accounting reconciliation depend on."
},
{
"q": "What if a caller has two upcoming consultations in Clio?",
"a": "AnyCRM returns every upcoming Calendar Entry for that Contact (summary, date, time, responsible attorney, linked Matter) and the AI Receptionist asks which one to change before doing anything. It never assumes."
},
{
"q": "Does it handle timezones correctly?",
"a": "Yes. The AI Receptionist confirms the caller's country/timezone, AnyCRM converts the consultation time into the format the Clio Calendar Entry requires, 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": "What about data residency, my firm uses Clio EU / Clio CA?",
"a": "Your Clio data stays in your firm's region. AnyCRM authorizes against your regional Clio Identity endpoint (US, CA, EU, AU) and every API call is made to that region's Clio host. AnyCRM persists only conversation history IDs on our side. No Contact, Matter, or Calendar Entry content leaves Clio's regional boundary via us."
},
{
"q": "How does the conversion tracking work?",
"a": "Every lead event AnyCRM produces (from a phone call, a chat conversation, OR a website intake form / chatflow) 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 intake forms? Do they go through the same pipe?",
"a": "Yes, that's the whole point. Web intake forms / chatflows 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 intake conversions instead of fragmenting across web-only and voice-only stacks."
},
{
"q": "How long until it's actually capturing intakes into Clio?",
"a": "Most firms are live the same afternoon. The OAuth grant takes a minute. The roster, practice-areas, and custom-fields 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."
}
]
}