LearnAI in Business Operations

Restarting a paused step: 4 checks

AI in Business Operations2026-09-16

In the previous lesson you paused an automated step when the drift signals appeared. Pausing is half the work; the harder half is knowing when to switch it back on. Many owners leave the step paused until everyone forgets it existed, or they restore it the next day because the team is drowning in manual work, and the same fault returns within a week. This lesson gives you four checks to clear before the system replies to another customer.

A case from the floor

An auto parts shop ran a WhatsApp quoting step: the customer sends a message such as "how much is an oil filter for a 2018 Camry?", and the system replies with the part number, the price and availability at the nearest branch. The owner paused it after finding the system quoted from an old list that predated the supplier's price increase, so thirteen messages went out below cost.

The team fixed the list the same day and asked to switch the step back on that evening. The owner refused and walked through the four checks, which surfaced two other branch lists that had not been updated yet. A quick restart would have reproduced the same fault through a second door, right after telling the team it was solved.

Four checks before you resume

  1. Was the cause fixed at its source? Correcting the thirteen messages is cleanup, not a fix. Ask: where did the wrong data first enter, who owns updating it, and what stops it recurring next month? If that answer has no name and no date, the cause is still live.
  2. Did you replay it on 20 real cases? Take the last twenty messages you actually received, run them through the repaired step, and compare each answer with the correct one. Test cases you invent yourself always pass, because your mind writes the case that fits the rule.
  3. Is there a parallel run with a hard cap? Two weeks where the system drafts the reply and an employee sends it after a glance. Write the rollback ceiling before you start: if corrections pass three in one week, the step stops automatically. A ceiling agreed in advance saves you an argument under pressure.
  4. Does it have a metric, an owner and a decision date? One number (share of replies sent unedited), one employee accountable for it, and a calendar date where you decide: full handover, extended parallel run, or permanent stop. Without a date the step stays "temporary" forever.
CheckQuestion it answersEvidence of passing
Cause fixed at sourceWill the fault recur?A named owner and a recurring update date
20 real cases replayedIs the fix actually enough?A sheet listing the cases and each result
Parallel runDoes it hold under real load?Two weeks plus a written rollback ceiling
Metric, owner, dateWho decides, and when?One number, one name, one calendar date
Do not announce the step's return to customers. Announce it to your team only. The customer notices a fast reply and does not care who wrote it; the team needs to know who reviews what over the next two weeks.

What to tell your team on day one

Two sentences are enough: the step is back under review, so every reply the system drafts passes an employee before it is sent, until this date. And anyone who sees a wrong reply logs it in the exception log instead of quietly fixing it. Silent correction is what hid the first fault for a whole week, and it will hide the second one too.

Three mistakes when restarting

First, expanding on restart day: you add all three branches at once and lose any way to tell which change caused which result. Start with the branch where the fault happened. Second, restarting against a new metric rather than the one you paused it on, making the comparison meaningless. Third, coming back during your busiest week because the pressure is high and the need is urgent; a busy week is an excellent test window and a terrible launch window.

Before all that, make sure the step's data source is trustworthy again: a step that quotes prices or confirms availability cannot sit on stock balances nobody trusts, as covered in WhatsApp inventory and running your business from WhatsApp.

Takeaway: never restart a paused step on instinct. Clear four checks: the cause was fixed at its source with an owner and a date, it was replayed on 20 real cases, it runs in parallel for two weeks under a written rollback ceiling, and it has one metric, one owner and one decision date. Then start with the branch where the fault happened, judge it on the same metric you paused it on, and go live in a quiet week, not a busy one.