Who Should Be On Call When a Revenue Automation Breaks?

Who should be on call when a revenue automation breaks?

One named person per automation, with a named backup, and a clear rule for what counts as urgent. On-call for revenue automations is not about a pager rotation. It is about making sure that when a lead stops reaching the CRM at night, someone specific owns the problem by morning, and everyone else knows who that is.

Most small teams never decide this. The person who built the Zap is assumed to be responsible forever, even after they change roles or leave. The founder finds out about a broken routing flow when a prospect complains. That is not a tooling problem. It is an ownership problem that tooling cannot fix.

I build and run automations in production, including the Airtable and WhaleSync system behind Ajust and the HubSpot via Zapier work for Kismet Health. The principle I hold to is simple: the automation that matters most is the one nobody thinks about, because it has worked quietly for months.

What counts as a revenue automation?

A revenue automation is any workflow whose failure changes what happens to a lead, a deal, or a customer. Form to CRM syncs, lead routing, enrichment, sequence enrollment, deal stage updates, and renewal reminders all qualify. If it breaks and nobody notices for a day, you lose pipeline or annoy a buyer. That is the test.

This definition matters because it tells you what needs an on-call owner and what does not. A Zap that posts a weekly summary to Slack can fail for a week without harm. A Make scenario that assigns inbound demo requests to account executives cannot fail for an hour without cost. Treating them the same wastes attention.

Keep a short register of every automation that touches revenue, with its trigger, what it writes to, and who owns it. A spreadsheet or an Airtable base is enough. The point is that the list exists, because you cannot assign on-call duty for systems you have not written down.

Why is the builder usually the wrong on-call owner?

The builder knows how the automation works, but they rarely own the outcome it serves. A marketing ops contractor who built your lead routing does not feel the pain of a missed demo. The sales leader does. On-call should sit with someone who feels the business impact and can reach the builder when needed.

This is why I separate two roles. The business owner decides how urgent a failure is and whether a workaround is acceptable. The technical owner fixes it. On a small team they can be the same person, but naming both roles forces a conversation about what happens when the technical owner is on holiday or no longer around.

When I hand an automation to a client, I want the business owner to be someone on their team, not me. I can be the technical owner under a retainer, but the person who decides whether a broken sync is a crisis should work inside the business. That keeps decisions close to the revenue.

How do you decide how urgent a failure is?

Sort every revenue automation into three tiers before anything breaks. Tier one blocks leads or customers right now and needs a response within hours. Tier two degrades data or reporting and can wait until the next working day. Tier three is cosmetic or internal and goes into a weekly review. Write the tier next to each automation.

Inbound lead routing, demo booking handoffs, and payment related syncs are usually tier one. Enrichment that fills firmographic fields in Clay or HubSpot is usually tier two, because a lead without a company size can still be worked by hand. Internal Slack notifications are almost always tier three.

The value of tiers is that they stop every alert from feeling like an emergency. When the team trusts that tier three alerts can wait, they respond faster to tier one. Without tiers, people learn to ignore alerts entirely, which is how a real failure sits unnoticed for days. I wrote more about that pattern in my piece on monitoring silent automation failures.

What should the on-call person actually be able to do?

They should be able to pause the automation, run the documented workaround, and reach the technical owner. They do not need to fix the root cause. A sales leader who can turn off a broken Zapier flow and route leads by hand for a day has done the job. Fixing it properly can wait for the builder.

That means the on-call person needs access, not expertise. Make sure they have a login to the automation platform with permission to pause workflows, and that they know where the manual fallback lives. Too many teams discover during an outage that the only person with access is the contractor who built it.

The workaround should be written down in plain language. My preference is a short runbook per tier one automation, covering how to tell it is broken, how to pause it, and what to do by hand until it is fixed. I go into the format in my guide to writing a runbook for a Zap that touches revenue.

How should alerts reach the on-call person?

Send tier one alerts to a named person in a channel they actually watch, and send everything else to a shared channel reviewed on a schedule. A dedicated Slack channel for automation alerts works well, as long as tier one failures also reach a person directly. An alert that lands in a busy shared channel is an alert nobody owns.

Automation platforms such as Zapier, Make, and n8n each offer their own ways to surface failures. Check your platform's official documentation for the exact options on your plan. The design choice that matters is routing: which failures go to whom, and how quickly.

I also recommend a simple daily check for tier one flows that can fail silently, such as a scheduled count of new leads created in the CRM compared with form submissions. If the numbers diverge, someone hears about it. Silent failures are the most expensive kind, because no error ever fires.

How do you tell a client or team that something broke?

Tell them early, tell them plainly, and tell them what you are doing about it. Say what failed, when it started, how many leads or records are affected, and what the workaround is. Do not wait until you have a fix. A short, honest message within hours builds more trust than a polished apology days later.

This is harder than it sounds, because the instinct is to fix the problem quietly and hope nobody noticed. I think that instinct is wrong. People forgive broken automations. They do not forgive finding out on their own. I covered how I handle this conversation in more depth in how I tell a client that an automation I built broke.

After the fix, write two lines in the automation register: what broke and what changed. Over time, that log shows which automations are fragile and which owners need more support. It also makes the next handover far easier.

What should you do next?

List every automation that touches leads, deals, or customers. Give each one a tier, a business owner, and a technical owner. Confirm that every tier one owner can pause the workflow and knows the manual fallback. Then route tier one alerts to a person, not a crowded channel. This takes an afternoon and saves real pipeline.

If you have more than a handful of tier one automations and no clear owners, start with lead routing. It is usually the flow with the highest cost per hour of failure and the least visible symptoms. Once that one is owned and monitored, the rest gets easier.

If you want help building an automation register, setting up alerts, or writing runbooks your team can actually follow, reach out. I build websites and the automations behind them for lead generation, and keeping those automations healthy after launch is part of the job. Let's chat.