Stop Automating Your Ceremonies

The third verdict on repetitive work is the one nobody reaches for. How to decide what to remove, what to automate, and what to keep

Every CS team I talk to right now wants to automate something. There’s an agent for QBR prep, an agent for the weekly account review, an agent that drafts the renewal-risk summary, an agent that assembles the onboarding plan. The tooling finally caught up to the ambition and everyone is racing to point it at their busywork. That instinct is mostly right, and I’m not here to talk anyone out of it. However there’s a step people keep skipping before they automate, and it’s the expensive one to skip.

Picture the moment that usually kicks off one of these projects. Someone on your team spent Friday afternoon building the same account review they’d already built for two other customers that week. Same slides, same pulled metrics, same “here’s your adoption trend” section the customer already knows because they’ve got the dashboard open in the next tab. By the third one they’re annoyed, and the annoyance turns into a proposal on Monday: “let’s build something that generates these automatically.”

That’s where it goes wrong. You’re about to spend real effort making that review faster, when the review itself might not need to exist. Automate it and you’ve built a machine that produces a ceremony nobody reads, on schedule, forever... and everyone calls it a productivity win because the calendar says the review happened.

The verdict everyone skips

I’ve got a rule I’ve said enough times that my teams can finish it for me. Do something manually once or twice, but by the third time you should figure out how to automate it or remove it completely. Manual effort is where value goes to die.

The part people hear is “automate it.” The part they skip is “or remove it completely.” And that second option is usually the higher-leverage one, because a lot of what a CS org does on repeat isn’t work that produces an outcome. It’s ritual that survives because nobody ever stopped to ask what it was for.

So the third time you catch yourself doing something by hand, you don’t actually have two options. You have three. You can remove it, automate it, or keep doing it by hand on purpose. Most teams only ever pick from the middle. The whole game is knowing which of the three a given task deserves, and being honest with yourself when the answer is “kill it.”

The Third Time Test

The trigger is frequency, and I picked the number on purpose. The first time you do something manually, you’re still figuring out the shape of it, and you should do it by hand... you don’t understand it well enough to systemize it yet. The second time confirms the shape. By the third time you’ve seen it enough to make a real judgment, and continuing to white-knuckle it past that point is a choice to let value leak out. So the third occurrence is the trigger. It isn’t a hard law. It’s a forcing function that makes you stop and render a verdict instead of drifting into a fourth, fifth, and fiftieth time out of pure habit.

When the trigger fires, you route the task with a few questions. The ones I ask, roughly in order:

Does this task exist to serve an outcome, or to serve a ritual? If you can name the outcome it moves and point at how you’d measure that it moved, it’s real work. If the honest answer is “we do it because we’ve always done it,” or “because the customer expects a meeting,” you’re looking at ceremony.

Is it a symptom of something broken upstream? A lot of repetitive CS toil is downstream of a bad default somewhere else. If you’re manually reminding thirty customers a week to finish a setup step, the task isn’t “send the reminder faster.” The real task is “why does the product let them get stuck there at all.”

Does it need human judgment every single time, or only sometimes? Some work genuinely requires a person on every instance, because the situation is different each time and the cost of getting it wrong is high. Most work needs judgment only on the exceptions. That difference is what decides whether a human stays in the loop or just supervises it.

Do you actually have the inputs to automate it well? This is the one people skip when they’re excited. If the data you’d feed the automation is dirty, sparse, or living in five systems that don’t agree with each other, the automation won’t be neutral about that. It’ll produce confident garbage, and confident garbage is worse than an honest blank.

Those questions route the task to one of three places.

Remove

This is the verdict nobody reaches for, and it’s the one that pays the most. If the task is ceremony, kill it. If it’s a symptom of a broken upstream default, fix the default and the downstream toil disappears on its own. Removing work is better than automating it, because automated work still has to run, still has to be maintained, still fails quietly, and still costs a sliver of attention every time it fires. Work you removed does none of that. The reason people avoid this verdict is that it feels exposed... somebody built that review, somebody’s boss asked for that report, and saying “we should just stop doing this” means having a conversation. Have the conversation.

The account review from the top of this post is a Remove in a lot of orgs. If the customer already has live visibility into their own outcomes (which is where I think this whole function is heading anyway), a recurring meeting to read those same numbers back to them isn’t adding anything. Replace the standing review with always-on visibility, plus a human reaching out when a signal actually warrants it, and you didn’t automate the review. You deleted the reason it existed.

Automate

This is the right call when the work is real, repetitive, mostly rule-based, and you’ve got clean enough inputs to trust it. This is where the agents earn their keep: pulling and structuring data, drafting the first version of something a human will finish, watching a portfolio for state changes and surfacing the ones that matter, assembling a briefing so a person walks into a meeting prepared instead of spending an hour prepping. The trap here is scope. Automate the mechanical majority and leave the judgment call to the human. The moment you let the automation make the decision instead of teeing it up, you’ve quietly crossed out of Automate and into a place you probably meant to avoid.

Keep

Some work you should protect from automation on purpose. The executive conversation where you tell a customer something they don’t want to hear. The expansion discussion that lives or dies on reading the room. The novel technical problem nobody has seen before. These need a person every time, and the cost of a system getting them wrong is high enough that “efficiency” is the wrong thing to optimize for. Keep them manual, and buy back the time to do them well by removing and automating everything around them. The goal of the whole exercise was never a CS org with zero manual work. It’s a CS org where the manual work that’s left is the work that actually needed a human.

The two ways it goes wrong

Both of the common failures are the same mistake wearing different clothes: reaching for Automate when the honest verdict was something else. Automate is the seductive middle option because it feels productive without forcing the harder conversation on either side of it.

You automated the ceremony

This is the common one. The work was ritual, the honest move was to kill it, but killing it means a conversation with whoever asked for it, so instead you build a slick generator and now you produce the ritual faster and prettier than ever. You’ve made the wrong thing efficient. Worse, you’ve entrenched it, because it’s a lot harder to argue for removing a process after someone spent a sprint automating it. The automation becomes the reason the ceremony is now permanent. If you catch your team automating something and nobody in the room can crisply state the outcome it serves, stop. You’re standing in this failure mode.

You automated the judgment

This one is quieter and it bites harder. The work actually needed a human every time, either because the inputs were too messy to trust or because the cost of being wrong was high, but it looked automatable on the surface so you handed it to a system. Now the system is confidently wrong at scale. It marks a strategic account as healthy because the usage numbers looked fine, with no way to know the champion left last week. It fires an expansion nudge at a customer who’s three days from escalating to your CEO. The blast radius of an automation making bad judgment calls across your whole book is a lot bigger than one CSM getting one call wrong, and it’s harder to catch, because it arrives wrapped in the authority of “the system said so.” Before you automate a judgment call, ask what happens when it’s wrong on a hundred accounts at once, not one.

One number to watch

If you want a single gauge for whether you’re actually doing this, count the recurring workflows your team removed last quarter. Not automated. Removed. Deleted the reason they existed.

I’ll be straight with you that I don’t have a clean industry benchmark to hand you here, and I’d be making one up if I tried. But directionally, if that number is zero across a full quarter, something is off. It almost certainly doesn’t mean your org had nothing worth removing. It means Remove isn’t a real option in practice... every task that came up for review got sent to Automate or Keep, and the hardest, highest-leverage verdict never actually got used. A team that’s genuinely running this kills things on a regular basis, and can tell you what it killed and why.

The prompts

Three prompts to run the Third Time Test on your own team. Same rules as always. Each one carries its own definitions so you aren’t relying on whatever the model assumes, forces the reasoning out into the open before the recommendation lands, and degrades its confidence honestly when the inputs are thin instead of guessing and sounding sure. Notice that risk and confidence are rated separately... a high-risk change you’re highly confident in is a very different situation from a high-risk change you’re guessing at, and collapsing them into one number hides exactly the accounts where you should be doing more homework.

Prompt 1: The Third Time Triage

You are helping a Customer Success team decide what to do with a recurring
task. Your job is to route the task to one of three verdicts: Remove,
Automate, or Keep. Do not skip straight to a recommendation. Work through
the reasoning first, out loud, then give the verdict.

Definitions you must use:
- Remove: the task should stop existing. It is ceremony (serves a ritual,
  not a measurable outcome), or it is a symptom of a broken upstream default
  that should be fixed at the source so the task disappears.
- Automate: the task produces a real outcome, is repetitive and mostly
  rule-based, and the inputs are clean enough to trust. A system does the
  mechanical majority and a human owns any judgment call.
- Keep: the task requires human judgment on every instance, and the cost of
  getting it wrong is high enough that efficiency is the wrong goal.

The task:
- What the task is: {describe the recurring task}
- How often it happens: {frequency}
- The outcome it is meant to move: {outcome, or "unclear"}
- How you would measure that outcome moved: {measurement, or "unknown"}
- Inputs the task depends on and where they live: {data sources}
- What happens today if it is done poorly: {consequence}
- Who asked for it / why it started: {origin, if known}

Work through this in order, showing your reasoning at each step:
1. Can you name a specific outcome this task moves, and how you would
   measure it? If not, flag it as a likely Remove and say so plainly.
2. Is this task a symptom of a broken upstream default? If yes, describe the
   upstream fix that would make it unnecessary.
3. Does it need human judgment every time, or only on exceptions? Be specific
   about which parts are mechanical and which require a person.
4. Are the inputs clean, complete, and trustworthy enough to automate
   reliably? If not, say exactly what is missing.

Then give:
- Verdict: Remove, Automate, or Keep
- Risk of acting on this verdict (High / Medium / Low): how much damage a
  wrong verdict could do
- Confidence in the verdict (1-10): how sure you are, given only the
  information provided
- If confidence is below 7, list the specific missing information that would
  raise it. Do not invent details to sound more certain.
- The first concrete step to execute the verdict this week.

Prompt 2: The Ceremony Audit

You are auditing a Customer Success team's recurring activities to find work
that should be removed, not automated. Teams tend to automate rituals instead
of killing them, which just makes the wrong work faster. Your job is to catch
that before it happens.

For each activity below, do the following. Show your reasoning, do not just
apply a label.
1. Name the specific outcome the activity is supposed to move. If you cannot
   find one from the information given, say so plainly. An activity with no
   nameable outcome is a strong Remove candidate.
2. State whether that outcome could be delivered another way that needs less
   or no recurring human effort (for example, giving the customer live
   visibility into the same information instead of assembling and presenting
   it on a cadence).
3. Classify the activity as: Load-bearing (removing it would cause a real,
   measurable loss), Ceremony (survives out of habit or expectation, not
   outcome), or Unclear (not enough information to tell).
4. For anything classified Ceremony, describe what you would replace it with,
   and name the conversation that has to happen to retire it, and with whom.

Activities:
{list the recurring activities, one per line}

At the end, rank the activities from most to least removable. For the top
three, give a one-line case for killing each that the team could actually
say out loud to whoever owns it. Flag your confidence (1-10) in each ranking,
and lower it honestly where the information was thin.

Prompt 3: The Pre-Automation Blast Radius Check

A Customer Success team has decided to automate a task. Before they build it,
stress-test the decision. Your job is to find the ways this automation could
be confidently wrong at scale, and to tell them whether to proceed, proceed
with a human checkpoint, or hold.

The automation:
- What it will do: {describe the automation}
- The decision or output it produces: {what it decides or generates}
- How many accounts / customers it will run across: {scale}
- The inputs it relies on and their quality: {data sources and how clean}
- What a human does with this output today: {current human role}

Assess, with reasoning shown:
1. Judgment check: does the task actually require human judgment on each
   instance, or only on exceptions? If every instance needs a person, this
   may be a Keep, not an Automate. Say so.
2. Input check: are the inputs clean, complete, and consistent enough to
   trust? For each weak input, describe the specific wrong output it could
   produce.
3. Blast radius: if the automation makes a bad call, what is the damage
   across the full number of accounts it runs on? Compare that to the damage
   of one person getting one instance wrong.
4. Failure visibility: how would anyone notice the automation is wrong? If a
   bad output looks the same as a good one, flag that as a serious risk.

Then give:
- Recommendation: Proceed, Proceed with a human checkpoint (specify exactly
  where the human checks), or Hold
- Risk if you proceed as planned (High / Medium / Low)
- Confidence in the recommendation (1-10), lowered honestly if the
  information about inputs or scale was incomplete
- If you recommend Hold, the single most important thing to fix before
  revisiting

Wrapping up

So the next time repetitive work shows up for the third time, don’t reach straight for the agent. Run the verdict first. Remove it if it’s ceremony, automate it if it’s real and rule-based and you trust the inputs, keep it if it genuinely needs you in the room. And if you take only one thing from this: the verdict everyone forgets is Remove, and it’s usually the one that pays.

I’d love to hear what you’ve actually killed. Reply and tell me the dumbest ceremony you finally retired, or the automation you’re glad you didn’t build. I read all of them, and the good ones have a way of showing up in a future post.