Editing a live automated step: 4 checks
Last lesson you listed your automated steps in one register, each row showing its state and last change date. Most changes it records will be edits, not pauses or retirements: a new price list, a new lead time, a clearer reply. Small-looking edits go live unchecked, and customers see the result before the team does. A healthy step needs no pause like a drifting one, but the edit must be tested before customers see it. Four checks follow.
A case from the floor
A two-branch bakery takes cake pre-orders over WhatsApp: a customer sends "I need a cake for twenty people on Thursday", and the system replies with sizes, price and the earliest pickup time. As event orders grew, the owner decided that orders for more than 30 people need 48 hours' notice instead of 24.
The order clerk edited the live rule on Sunday, writing "orders need 48 hours" and dropping the 30-person condition. For three days every customer, even one ordering a small cake, was told the earliest pickup was two days away. Few complained; most quietly went elsewhere. When the second branch's manager noticed next-day orders plunging, nobody knew when it had started, or what the rule said before.
Four checks before any edit
- Write the edit as two sentences: what changes, what stays. The first, in the register's form: when an order is for over 30 people, the system offers pickup after 48 hours. The second, often forgotten: orders for 30 or fewer keep 24 hours. That sentence alone would have caught the bakery's mistake.
- Replay it on past messages, not customers. Take the step's last 30 messages plus cases from your exception log, and set each old reply beside the new one. Every difference must be intended; any change outside your first sentence means stop. At the bakery, most replies would have changed, not just large-order replies.
- Keep the previous version and a rollback signal. Copy the rule's old text into the step's row in the register, and decide in advance who may roll back and what triggers it: the first complaint, or the step's metric worsening since its last review. A rollback that relies on memory is a rewrite under pressure.
- Record it and tell whoever answers manually. Update the step's row in the automation register that day: the date, the change and who approved it. Then tell staff answering the same question by phone or in person; a customer told 24 hours by staff and 48 by WhatsApp trusts neither.
The same principle appears in ISO/IEC 42001:2023, the international standard for AI management systems: clause 8.1 requires an organization to control planned changes and review the consequences of unintended ones, acting to mitigate any adverse effects.
Sizing the check to the change
Size the check by what happens if the edit goes out wrong:
| Type of edit | Example | Check needed |
|---|---|---|
| Reply wording only | A shorter or clearer reply | Compare 10 past messages |
| Data update | A new price list | Match it to its source, test a sample of 10 items |
| Rule change | A new condition, lead time or limit | Compare 30 messages, watch daily for a week |
| Money or personal data | A credit limit, a discount, sending a statement | Two-week parallel run and owner approval |
The last row's check is the parallel run from the second automated step lesson: the system drafts; staff review each reply before sending and log every difference.
When the edit is a WhatsApp message
If the step lives inside your system, the replay can be part of the edit request. The owner sends "Change the notice for orders over 30 people to 48 hours", and before applying it the system replies: "This would have changed 4 of the last 30 replies, all for orders over 30; smaller orders are unaffected. Apply it?" The owner's yes is the recorded approval; the old version stays ready. More in running your business from WhatsApp.
Three common mistakes
- Bundling edits. Change price, lead time and wording together and you cannot tell which broke things; change one at a time.
- Editing when the step's owner is away. Late in the day or before a holiday, nobody sees the first replies; edit when they can watch.
- Patching a bad edit with a rushed one. Roll back first, then investigate; a hurried fix on a wrong edit hides the cause.