How to Write a Runbook for a Zap That Touches Revenue

What should a runbook for a revenue-critical Zap actually contain?

A useful runbook answers five questions for whoever is on call: what this Zap does, how to tell it is broken, what to check first, how to fix or replay safely, and who to tell. Keep it to one page, store it next to the Zap, and write it for someone who did not build it.

Most Zaps that move leads, deals, or invoices were built by one person on a busy afternoon. They work for months, then fail on a weekend, and the only person who understands them is on a flight. The fix takes ten minutes. Finding out what the Zap was supposed to do takes three hours.

A runbook closes that gap. It is not documentation for its own sake. It is the shortest path from "something looks wrong" to "leads are flowing again" for a person who has never opened the Zap before. Here is how I write them for automations that touch revenue.

Why does a Zap that touches revenue need its own runbook?

Because the cost of downtime is not the Zap. It is the leads that sit unrouted, the deals that never reach the CRM, and the follow-ups that never send. When a revenue Zap fails, the damage grows every hour nobody notices, and the person who notices is rarely the person who built it.

General automation docs describe how something was built. A runbook describes how to keep it running. The difference matters at 9 p.m. on a Friday, when a sales lead asks why no demo requests came in today and whoever picks up the question needs steps, not architecture diagrams.

I only write runbooks for Zaps that touch money or pipeline: form to CRM, lead routing, deal stage updates, invoice creation, and anything that sends an email to a buyer. Internal convenience Zaps, like posting a Slack message when someone books a meeting, can live without one. The test is simple. If this broke for a day, would a customer or a deal notice?

What goes at the top of the runbook?

The top of the runbook holds the facts someone needs in the first sixty seconds: the Zap's name and link, the trigger and its source app, the systems it writes to, the owner and a backup owner, and a one-sentence description of what success looks like. Nothing else goes above the fold.

That success sentence is the most useful line in the document. Something like: every Webflow demo form submission becomes a HubSpot contact with lifecycle stage set to lead and an owner assigned within five minutes. Anyone can check that sentence against reality, even without opening Zapier.

I also list the accounts the Zap uses to connect to each app. Many silent failures come from an expired connection or a person leaving the company whose login powered the integration. Knowing which account is connected saves a long hunt.

How do you know the Zap is broken?

List the symptoms a non-builder would see, not just the errors Zapier would show. Missing contacts in the CRM, a sales rep saying they got no leads today, duplicate records, or a sudden spike in records with an empty owner field. Then list where to confirm it: Zap history, the destination app, and any alert channel.

Zapier error emails are not a complete early warning system, and the runbook should say so. According to Zapier's help center, when autoreplay is on, Zapier retries a failed step up to five times, at growing intervals of 5 minutes, 30 minutes, 1 hour, 3 hours, and 6 hours. Zapier says it will not send any error notification emails until the final autoreplay attempt fails.

Add those intervals up and the final retry lands more than ten hours after the first failure. Autoreplay is useful, because many failures are temporary. But for a lead-routing Zap, ten hours of silence can mean a whole day of demo requests sitting unworked. Your runbook should name a second signal, such as a daily count check, so nobody relies on the error email alone.

I wrote about who should get those alerts in who gets the alert when an automation fails overnight. The runbook should point to that decision, not repeat it.

What should the first-response steps say?

Write the first steps as checks in the order of likelihood: is the Zap turned on, did the trigger fire, did a step error, did a connected account expire, and did the source or destination app change a field. Each check should say where to click and what a healthy result looks like, in plain words.

The order matters. I check the trigger first, because a renamed form field or a changed form in Webflow will break the data before Zapier ever sees an error. The second most useful check is the connected account, for the reason above.

Each step should end with a decision. If the trigger did not fire, check the source app. If a step errored, open the run in Zap history and read the error. If a connected account expired, reconnect it with the account named at the top of the runbook. No step should end with "investigate further" and nothing else.

For the reading-the-history part, I have a separate guide on using Zapier run history to debug a broken Zap. Link to guides like that rather than copying them, so the runbook stays short.

How do you replay failed runs without making things worse?

Before replaying anything, check whether a partial run already wrote data. Replaying a run that created a CRM contact but failed on the next step can create a duplicate contact. Your runbook should say which steps are safe to repeat, which are not, and how to check the destination app before you press replay.

Zapier's help center notes that autoreplay will not replay runs that were safely halted, and that autoreplay is available on Professional, Team, and Enterprise plans, not the Free plan. Plan features change, so the runbook should link to Zapier's current docs instead of stating the plan as a permanent fact.

The safest design is to make the Zap itself safe to repeat. A step that searches for an existing contact before creating one turns a dangerous replay into a harmless one. When a Zap is not built that way, the runbook has to carry the warning, in bold, at the replay step.

I also write down what not to do. Do not turn the Zap off and on to see if it helps. Do not edit the live Zap during an incident unless the owner agrees. Do not bulk replay a day of runs without checking a sample first.

Should a runbook use Zapier's error handlers?

Yes, where the Zap supports them, because an error path turns a silent failure into a visible one. Zapier's help center describes custom error handling as a separate path that runs only when a specific step fails, so you can log the error or alert a person immediately instead of waiting for retries to finish.

That is especially useful for the riskiest step in a revenue Zap, usually the CRM write. An error path on that step can post the failed record to a Slack channel or append it to an Airtable table, so a person can enter it by hand while the fix is underway. The lead still gets worked, even if the automation is down.

Know the tradeoffs. Zapier's help center says error handler runs do not send error notification emails and appear in Zap history with a Stopped or Handled status, and that custom error handling is available on Professional, Team, and Enterprise plans. That means the error path is your alert. If it only writes to a log nobody reads, you have built a quieter failure, not a safer one.

Who should own the Zap and the runbook?

One named person owns the Zap, and one named backup can act when the owner is away. Both names go at the top of the runbook. Ownership means they get the alert, they approve changes, and they update the runbook whenever the Zap changes. A team or a department is not an owner.

This is where most automation setups decay. The builder moves on, nobody is assigned, and the Zap keeps running until it does not. I wrote about the slow cost of that in the cost of an automation nobody owns, and a runbook without a named owner has the same problem.

Ownership also covers review. I put a review date on every runbook, usually once a quarter, where the owner checks that the success sentence is still true, the connected accounts still belong to current employees, and the steps still match the Zap.

Where should the runbook live?

Store it where the on-call person will look first, and make it findable from the Zap itself, for example by using the same name for the Zap and its runbook. Keep the full runbook in your team's shared docs or in the same Airtable or Notion space where you track automations.

For teams with more than a handful of revenue Zaps, I keep a simple automation register: one row per Zap with the name, owner, backup, systems touched, runbook link, and last review date. It turns "which of our automations touch HubSpot" from a guessing game into a filter.

The register also makes audits easy. When a SaaS tool changes its API or a connected employee leaves, you can see every affected Zap in one view instead of discovering them one failure at a time.

What should you do next?

List every Zap that touches leads, deals, or invoices. For each one, write the success sentence first, then the symptoms, first checks, safe replay rules, and owners on a single page. Add an error path to the riskiest step, link the runbook from the Zap, and set a quarterly review date.

Start with the one Zap that would hurt most if it failed tonight. Writing a good runbook rarely takes long, and most of that time is spent learning things about the Zap you did not know.

I build automations like these, including the HubSpot setup through Zapier that runs in production for Kismet Health. If you want help documenting the Zaps your pipeline depends on, reach out at pravinkumar.co and let's chat.