Client onboarding automation that starts where the signed proposal actually lands: your Downloads folder.

Both modes work, but the folder watcher is the one the feature is built around. You describe the ritual once in plain English, including the trigger condition ("whenever a signed proposal PDF lands in ~/Downloads"). Clone then listens to that folder and replays the ritual every time a new signed PDF appears. If you prefer a manual kick-off (for example, on a day you do not want anything to run automatically), you can also just type "run onboarding-ritual on Northbeam-signed.pdf" and Clone will do the same thing on demand.

A Zapier Zap requires you to configure every branch of the onboarding in their UI: the trigger (Gmail label or attachment), the parsing step (Zapier needs structured fields, so you either pay for PandaDoc webhooks or use a parser), a filter, and a separate step for Drive, Docs, Calendly, Gmail, HubSpot, and QuickBooks. Each step breaks when any of those vendors changes an API field. Clone does not configure steps. It reads the PDF as a PDF, opens the apps in a real Chrome session, and clicks the buttons you would click. Row four of the comparison table on Clone's homepage is explicit: "Works with custom or legacy apps" is one row where Clone checks and Zapier x's.

They are portal-replacement platforms. You move your client-facing surface into their ecosystem: proposals, contracts, invoices, and onboarding all live inside HoneyBook or Dubsado, and your clients log in there. That works for some consultants, but it requires replacing three or four tools at once and retraining every client. Clone lets you keep QuickBooks, HubSpot, Gmail, Docs, and DocuSign exactly as they are, and adds a ritual that chains them when a signed PDF lands. The ComparisonTable on Clone's homepage has a row, "Uses the tools you already have," where Clone checks and HoneyBook x's for this reason.

Clone operates whichever desktop it runs on. The filesystem trigger is ~/Downloads on macOS and %USERPROFILE%\Downloads on Windows by default, and you can point it at any folder you name (for example, if your firm uses a shared Dropbox-synced folder as the signed-proposal landing zone). Because Clone drives the UI of Chrome, Google Docs, Gmail, HubSpot, and QuickBooks through screen reading, the same ritual works on either OS as long as you are signed into the same web apps.

Principle one in architecture.tsx is "Runs on your machine. Clone operates your desktop apps from your desktop. Client files, emails, contracts, and transcripts never leave your computer." For onboarding specifically, the signed PDF never gets copied to a third-party cloud. Clone reads it locally, moves it into the Drive folder you already own, and attaches it to the HubSpot deal record you already own. There is no middleware cloud that holds a tokenized copy of your client's contract for the life of the engagement.

Open src/components/features.tsx in the cl0ne.ai repo and read lines 22 to 29. You will see one card: title "Client onboarding in minutes," description that starts with "Drop a signed proposal into a folder" and lists five concrete actions (provision shared workspace, draft kickoff agenda, book the call, send welcome email, file in CRM), detail line that says "Pulls from your proposal templates and existing client taxonomy. No rigid workflows." That single card is the product's literal answer to this topic. Then read src/components/architecture.tsx lines 46 to 54 for the two principles (Runs on your machine, Your workflows your voice) that make the folder-trigger implementation possible.

Clone does not care what signed the PDF. It cares that a file landed in the folder you told it to watch. A signed PNG scan, a printed-signed-scanned PDF, a PandaDoc-signed PDF, a HelloSign-signed PDF, and a DocuSign-signed PDF all land the same way. The signature detection is done on the document itself (looking for signature blocks, initials, and date fields), not by plugging into a specific signing vendor's API.

Yes. Principle four in architecture.tsx is "Always reviewable. Every action Clone takes is logged and reversible." The onboarding ritual is no exception. You can watch the terminal log as Clone progresses, interrupt it before the Calendly invite is sent (the Gmail and QuickBooks drafts never auto-send anyway), and ask Clone to roll back the Drive folder and the HubSpot stage change. The reversibility is per-action, not all-or-nothing.

Two concrete things. First, Clone reads the signed PDF and cross-references your ~/Documents/proposals folder to find which of your templates the proposal was built from. The template tells Clone what the deliverables are, what the fee structure looks like, and which kickoff agenda template matches. Second, Clone reads your existing CRM (HubSpot or Pipedrive or whichever) to see how you name clients, how you tag verticals, and how your deal stages are configured. It files the new client using those names, not a generic "Acme Corp" convention. The detail line in features.tsx lines 22 to 29 is explicit about this: "No rigid workflows."

The ritual you describe for onboarding becomes a named thing Clone can chain with other named rituals. For example, after the Closed Won stage change, Clone can automatically chain into a weekly-status ritual that runs every Friday for the life of the engagement, pulling hours from your time tracker and drafting a client update. You do not build a graph; you describe each ritual as a sentence, and Clone handles the chaining when one of them mentions the other. features.tsx lines 46 to 53 describe this for the follow-up feature, and the same pattern applies to onboarding.