Client support retainer: automation and integration failure pack (with AI)

When a client on an active support retainer says “Make stopped working” or “leads aren’t syncing anymore,” the failure is often silent: the UI looks fine, but runs stopped days ago or every execution errors on step three. You need a calm, billable path—separate facts from guesses, document what broke, get written approval before re-auth or production toggles, and keep a clear Gmail cadence until an end-to-end test passes.

This playbook is for integration and automation failures during retainer support (Make, Zapier, n8n, custom webhooks, CRM↔form connectors)—not email deliverability DNS, not a bad deploy rollback, and not a full-site outage. It pairs ChatGPT for structured triage, a one-page Integration Status Brief in Google Docs, and a three-email Gmail sequence your client can forward internally.

Browse more step-by-step guides in our guides library.

When to use this pack

Open this workflow when all of these are true:

• The retainer is active and the ticket is in scope (break/fix on existing automations).
• Something stopped moving data or runs fail repeatedly (not a one-off API blip you already closed).
• You can access run history, logs, or a test record ID the client cares about.

If the root cause is clearly a third-party vendor outage with no fix on your side, pivot to your vendor escalation pack after the first hour of blocked time. If the site is down entirely, use your urgent P1 pack instead.

The six-step flow

Step 1 — Capture facts before you touch anything

Paste into ChatGPT (replace bracketed fields):

You are my integration triage assistant. Label each line FACT (evidence) or ASSUMPTION (guess).

Symptom: [client quote]
Platform: [Make / Zapier / n8n / webhook URL]
Last successful run (timestamp + record ID if any): [from history]
First failed run (timestamp + error snippet): [paste]
Recent changes: [OAuth rotation / password / CRM field / plan downgrade]
Client priority record: [e.g. lead email test@…]

Output:
1) Failure class: auth | quota | mapping | upstream API | disabled scenario
2) Three safest next checks (no production writes)
3) Questions for the client (max 5)

Export the thread or copy the summary—you will paste the FACT block into the brief.

Step 2 — Build the Integration Status Brief (Google Docs)

Use this one-page structure:

Section	Content
Header	Client, scenario name, ticket ID, date
Impact	What stopped (e.g. “Shopify → HubSpot leads since Tue 14:00 UTC”)
Timeline	Last good run → first bad run (FACT only)
Error class	auth / quota / mapping / upstream / disabled
Evidence	Screenshots or log lines (redact secrets)
Proposed fix	Steps + estimated retainer hours
Rollback	How to revert if the fix makes things worse
Verification	Exact test record + expected outcome

Share the doc comment-only until the client approves reconnection or production changes.

Step 3 — Gmail cadence (three emails)

Email 1 — Acknowledge + brief link (within SLA)
Subject: [Retainer] Integration issue — facts captured, brief attached
Body: Symptom in one sentence, link to the Google Doc, what you need from them (e.g. “confirm we may reconnect Make to HubSpot”), and when the next update lands—even if still investigating.

Email 2 — Decision point or progress
Send when you know the error class or need approval: restate FACT vs open questions, options A/B (e.g. re-auth now vs wait for client IT), and hour impact if the retainer bank is tight.

Email 3 — Verified fix or explicit deferral
Include: test payload used, timestamp of successful run, link to updated brief section “Verification,” and what to watch for (OAuth expiry, API quota resets).

Keep all three in the ticket thread so billing and RCA stay traceable.

Step 4 — Fix with a verification matrix

Before closing, run this checklist:

1. Single test payload — one real or sanitized record the client named.
2. Downstream check — confirm the CRM row, Slack message, or sheet line exists.
3. Idempotency — re-run once; ensure you do not duplicate production objects unless intended.
4. Monitor window — note “watch until [time]” for delayed queues.
5. Doc update — brief shows green verification block; ChatGPT thread archived.

Common fixes (document which applied): OAuth reconnect, refreshed API key in vault, field map after CRM schema change, re-enabled scenario after plan lapse, webhook URL updated after domain change.

Step 5 — Make-specific quick checks (optional)

If the stack is Make, verify in order: scenario not paused, connection still “connected,” operation quota, and the exact module that first turned red in run history. Do not bulk-replay old bundles until the client approves duplicate risk.

Step 6 — Log it in the monthly retainer review

Add one row to your retainer health log: date, platform, error class, hours burned, preventive action (e.g. “quarterly OAuth audit,” “alert on 24h zero runs”). That row feeds your monthly support retainer review one-pager.

What this pack is not

• Email bounce/spam DNS — use your deliverability pack (SPF/DKIM/DMARC evidence).
• Bad release rollback — use your deployment rollback brief with last-good build.
• New automation scope — route to a change request if they want a net-new workflow.

Copy-paste client snippet

We’ve documented the integration failure in a brief (facts, timeline, proposed fix). We won’t reconnect APIs or change production mappings until you reply approved on the doc. Next update by [time]. Test verification will use [record ID] so you can confirm in [system].

Used honestly, this pack turns “automation magic stopped” into a written, verifiable retainer deliverable—without mystery fixes or silent re-auth that the client learns about later.