Creators Agency Docs

Appearance

Troubleshooting Guide ​

A brand emailed but never got a reply ​

Check first: Zapier history for Zap 347165805 — search by the brand's email address or look at runs around the time the email came in.

Common causes:

  1. Classified as OTHER or spam — Step 4 filter stopped it. Look at the Step 3 output in the run. If it was classified as OTHER when it shouldn't have been, the GPT prompt may need tuning. If it's spam, check if the domain needs to be added to the blocklist.

  2. DNS check blocked it — The sender domain had no MX or A records. Can happen with newly registered domains or unusual TLDs. Check the Step 2 output for domain_exists: false.

  3. Thread dedup stopped it — A previous email from the same Gmail thread already triggered a reply. Step 6 filter stopped the second email. This is correct behavior — only one auto-reply per thread.

  4. Gmail authentication issue — The Gmail send step (Step 16) failed. Check the Zap run for a Step 16 error. Usually resolved by reconnecting the Gmail auth in Zapier.

  5. Zap was paused — Check if Zap 347165805 is turned on. Task limit could have paused it.

Follow-ups stopped too early ​

Check Airtable first: Find the record in Inbound Messages. Check:

  • Responded — if true, that's why. Who set it? Was it correct?
  • Follow Up Count — if 4, all follow-ups were sent and the sequence is complete
  • Reply Sent — if false, the initial auto-reply never sent. Follow-Up Zap skips these.

If Responded = true but brand didn't actually respond: The companion Zap (356311797) may have matched the wrong record. Check if Close has an inbound email activity on this lead from around the time Responded was set. Could be a different contact on the same lead triggering it.

If Follow Up Count is stuck: Check Zap 356080312 run history for that record. The Formatter step (Step 4) calculates days since routed_at. If routed_at is blank or malformed on the record, the date math fails.

A message appeared in #crm-review-queue ​

The main Zap posts here when a brand emails from a generic domain (gmail.com, yahoo.com, etc.) and GPT couldn't extract a brand domain from the email body. A Close lead was created with the name Unknown - [Sender Name].

Action: Open the linked Close lead. Research the company, update the lead name and website URL. If it's legit, the follow-up sequence is already running.

Brand replied but Responded didn't get set ​

Cause: The companion Zap (356311797) runs off Close CRM email sync. If Close hasn't synced the agent's inbox yet, or the reply went to a non-synced address, the Zap won't fire.

Check: Go to the Close lead. Is there an inbound email activity from the brand? If not, Close hasn't synced it. Wait a few minutes and check again.

Fallback: Manually set Responded = true in the Airtable record to stop follow-ups immediately.

Brand booked a call but Has Booked didn't get set ​

Cause: The Cal.com handler (markAirtableBooked) couldn't find a matching Airtable record.

Most likely reason: The booker's email doesn't match any email field in Airtable. This happens when:

  • The brand was a cold booking (never went through the inbound flow)
  • The booker used a different email than the one that originally emailed intake@

Action: Manually set Responded = true and Has Booked = true on the Airtable record if you can find it.

Duplicate auto-reply was sent ​

Cause: The thread dedup (Steps 5-6) checks by Gmail thread_id. If the same brand sent a follow-up in a new thread (not a reply — a fresh email), both would trigger a reply.

Action: This is correct behavior for new threads. If it was a mistake, manually update Responded = true on the older record to stop further follow-ups.

Agent is getting too many / too few leads ​

Check the Airtable roster (base appftI8k7agMqH4bb, table tblX2Z1nIj3k3iSTT). Look at last_assigned_at for each active agent. The round-robin picks whoever has the oldest timestamp.

If one agent's last_assigned_at is far in the past compared to others, they'll get the next several leads until they catch up. This is by design.

To manually reset the balance: update last_assigned_at on the agents to equalize them.

Follow-up cron isn't sending (or sending when it shouldn't) ​

The follow-up cron replaced Zap 356080312 as of March 26, 2026. It runs Mon/Wed/Fri at 8:45 AM CT on Mac Mini.

Check the log first:

bash
ssh mini "tail -100 ~/tasks/logs/inbound_followup.log"

Common issues:

  1. 0 sends, no errors — Either no records are due yet (check routed_at + Follow Up Count in Airtable), or all eligible records already have Last Contact Date = today. This is correct behavior if it's the first run in the cycle.

  2. Threading failure — email starts a new thread — The script looks up the RFC Message-ID in the agent's Gmail mailbox. If the original email never landed in the agent's inbox (e.g., it went to a different address), threading degrades to headers-only. The email still sends but may not thread correctly. Check that the Message ID field in Airtable matches an actual Gmail message in the assigned agent's mailbox.

  3. Dollar sign in generated email → auto-retry — The validator catches $ in the output and regenerates. This is working correctly if you see [VALIDATE] Dollar sign found — regenerating in the log. If the retry also fails, the email still sends without the dollar amount (fallback).

  4. Gmail send fails (403/401) — Service account DWD may have lost scope. Test with:

    bash
    ssh mini "python3 -c \"
import warnings; warnings.filterwarnings('ignore')
import json
from google.oauth2 import service_account
from googleapiclient.discovery import build
from google.auth.transport.requests import Request
sa = json.loads(open('/Users/ari/.openclaw/workspace/.secrets/google_service_account.json').read())
creds = service_account.Credentials.from_service_account_info(sa, scopes=['https://www.googleapis.com/auth/gmail.send'], subject='annie@creatorsagency.co')
creds.refresh(Request())
print('OK')
\""

    If this fails, the service account needs its DWD scopes re-authorised in Google Admin.

  5. Airtable 401 — API key expired or rotated. Update /Users/ari/.openclaw/workspace/.secrets/airtable_api_key.txt on Mini.

  6. Cron didn't fire — Verify launchd is loaded:

    bash
    ssh mini "launchctl list | grep inbound"

    Should show com.creatorsagency.inbound-followup with exit code 0. If missing: ssh mini "launchctl load ~/Library/LaunchAgents/com.creatorsagency.inbound-followup.plist"

  7. Close status not updating after FU#4 — The script finds the Close lead by the sender's email. If the contact isn't in Close yet, the status update silently skips. Check the log for [CLOSE] Could not find lead — if present, manually set the lead status in Close.

Zap health check ​

Quick things to verify if the whole system seems off:

  1. Is Zap 347165805 turned on? (Main inbound Zap — handles first reply)
  2. Is Zap 356311797 turned on? (Brand reply detection — sets Responded = true)
  3. Is the follow-up cron loaded on Mini? ssh mini "launchctl list | grep inbound"
  4. Are Annie, Charlie, and Henry's Gmail accounts synced to Close? (Close Settings → Team → Email Sync)
  5. Is the Airtable PAT valid? (Try a test API call — auth errors will show in Zapier run logs)