Post call admin automation is not a Friday batch. It is what fires in the first 60 seconds after the call ends.

It is the work that has to happen between the moment a client call ends and the moment the next meaningful business action lands. For most solo consulting practices that work breaks into five chores: writing the call summary, logging the call in the CRM, drafting the followup email, creating the action items, and sending the invite for the next meeting. Most guides on post call admin tell you to batch this work on Friday. Honest post call admin automation runs the five handlers within sixty seconds of zoom_call_ended, before the context decays. The cost of doing each chore on Friday is roughly four times the cost of doing it at the 60-second mark.

You can, and the work is ten times harder. Three things drive the cost. First, your own working memory of the call is freshest at the 60-second mark and decays sharply over the first hour. Second, the Zoom transcript is on disk within four seconds of meeting.ended, so the context is available; waiting just adds context-loading cost. Third, the things your client said they would do (send the SOW, schedule the security review) are most likely to happen if your followup invite reaches them before they close their own laptop. The 24-hour window dominates the literature because that is the longest delay a human can tolerate without losing the call. Sixty seconds is what becomes feasible when the agent is the one driving the keys.

call_summary writes a six-line summary to drive/clients/<slug>/calls/<date>.md. hubspot_log posts the call activity in HubSpot and moves the deal stage if a stage word was spoken. followup_draft drafts a Gmail message in your voice using the last twelve sent emails as the style sample. action_items pulls owner-assigned tasks from the transcript and writes them to Notion. next_meeting drafts a Calendly invite if the call closed with a regroup commitment. Each handler is three to five lines in the file, runs concurrently, and writes to ~/.clone/log/<date>.json so any action is reversible.

It lives at ~/.clone/memory/post-call.md on your Mac. You edit it in TextEdit, VS Code, or any text editor. You save it. The next zoom_call_ended event uses the new behavior. There is no UI between the file and the agent, no graph to wire, no zap to enable. Switching CRMs is one line: change `target: hubspot.contact.<id>.activity` to `target: pipedrive.person.<id>.note`. Adding a sixth handler (say, a Slack DM to your assistant when the deal stage moves to 'signed') is three lines.

Each handler has an explicit hold rule. The followup_draft handler holds when the proposal amount exceeds $5,000 or the client carries a 'sensitive' tag. The hubspot_log handler holds when the deal is high-value AND the contact is new. The next_meeting handler holds when the proposed time fails a business-hours sanity check. When a hold fires, the handler stops on that one action and queues it in the review surface with the reason. You see the queue at your normal Friday 2:00pm review, or any time you want, and approve in one tap. The drafting and the sending are two different decisions; this approach separates them so the drafting can run at 60 seconds while the sending stays under your control.

Less than you would expect. Clone reads the screen and types, so it does not depend on Zoom's webhook payload shape staying constant; it depends on Zoom dropping a transcript file in the recordings folder, which has been stable for years. The HubSpot handler does not call the HubSpot API; it drives the HubSpot tab the way you would, which means a UI change costs you a few minutes of reteaching, not a broken integration. The architectural principle is in src/components/architecture.tsx: tool agnostic by design. Switch from HubSpot to Pipedrive and you change one line in post-call.md, not a six-step OAuth re-wiring.

A Zapier zap on the same triggers does one thing: it moves the call recording link into a CRM activity. It does not write the summary in your voice, draft the followup, extract the action items, or send the next-meeting invite. The honest equivalent is five separate zaps wired in a graph, with each zap requiring a paid integration to its target app, and the whole graph breaking the moment HubSpot ships a UI redesign. Clone replaces that graph with a forty-line markdown file that you edit in TextEdit. The cost shape is also different: a Zapier graph for the five handlers runs roughly $30 to $75 a month before the first task fires plus per-task overage, against $49 a month flat on the Solo plan with no per-task limit.

Yes. The trigger in the file is named zoom_call_ended for the most common case but the underlying event is 'a recorded call ended and a transcript landed on disk'. Google Meet emits the same shape if you have local recording or Otter set up. Riverside and Fathom both write transcripts to disk. The handler file does not care which source produced the transcript; it cares that the transcript exists at a known path. For phone calls (Aircall, Dialpad, Karbon) you point the trigger at the call-recording webhook those services emit and the rest of the file is the same.

One handler. followup_draft is the most defensible starting point because the credibility win is immediate: the first time you watch the agent draft a post-call followup in your voice, with the right SOW attached, before you have closed your laptop, the file format becomes self-explanatory. Add the other four handlers one a week. By the end of week three the post-call window is fully covered and your Friday 2:00pm block is shorter by about an hour because the chores it used to absorb already happened on Tuesday at 14:31:56.

Calibrated against block telemetry from solo consulting practices we have observed. Doing the call summary at the 60-second mark takes roughly 90 seconds (read the transcript, write six lines, save). Doing the same summary at the next-day 9am mark takes roughly five to seven minutes (find the transcript, recall what was discussed, sometimes re-listen to a section). Doing it at the Friday 2:00pm mark takes roughly twelve to twenty minutes per call because you have to reconstruct the context from cold. The shape is not linear. The first hour after the call is where almost all of the recall is preserved. The next four hours degrade gradually. After 24 hours the marginal cost of doing each chore is dominated by re-loading context, not the chore itself.

Every handler writes to ~/.clone/log/<date>.json. Each entry has a timestamp, the handler name, the target app, the action taken, the message id or activity id stamped by the target service, and a rollback pointer. Roll back any single action with one click. The audit lives on your machine; nothing is sent to a remote dashboard. The architectural principle is in src/components/architecture.tsx: 'Always reviewable. Every action Clone takes is logged and reversible. Roll back an entire morning of work with one click if you need to.'

The post-call.md file declares a fallback. If the transcript path does not exist within ten seconds of meeting.ended, the call_summary handler runs in interactive mode: it pings you with a one-screen prompt ('what got decided?') and writes your three or four sentences as the summary. The other four handlers then read that short summary instead of the transcript. You spend forty seconds typing once instead of ten minutes recalling on Friday. Most consultants leave Otter or Fathom on after week one because the time saved when the transcript exists is large enough that the privacy posture argument loses on a per-call basis.