The Automation Change-Control SOP
Purpose
This procedure guarantees that no automated message or flow changes without a written description of the change, a test against staff records covering every branch, a phone preview, a second person's approval, a way back to the previous version, and a record of all of it. Without it, the usual failure is not a badly built automation; it is a sound one broken by a quick edit on a busy afternoon, where the person editing changed four settings and knew about one.
Scope
Covers any change to an automation that sends something to a customer or acts on customer records: reminder and follow-up sequences, appointment confirmations, review requests, invoice and payment reminders, web-form routing that replies to the sender, and the configuration (greeting, booking rules, transfer rules) of an AI phone or chat agent. Wording changes count: they are the most common way a segment or a delay gets changed by accident.
Does not cover: building a new automation from nothing, which starts with mapping the process (see Mapping a Process Before You Automate It); reviewing individual AI-drafted messages before they are sent (see The AI-Drafted Customer Message Review SOP); and the after-the-fact review of what a phone agent actually said on calls (see The Weekly AI Call Review SOP). An emergency stop is also outside this procedure: anyone may pause a live automation at any time without approval, and should.
Roles and responsibilities
| Role | Does | Hands off to |
|---|---|---|
| Editor (usually office manager) | Writes the change, edits a copy, runs the tests and the phone preview | Approver, with the change form and test results |
| Approver (a second person, never the editor) | Checks the form against the test results and audience count, signs, owns the go-live watch | Editor, for go-live; owner, if the change is refused |
| Owner | Approves where the editor is the only office person; decides any legal question | Attorney, where the change touches consent or opt-outs |
In a one-person office the owner edits, and the change waits overnight before the owner approves it; a night's sleep is the closest a one-person shop gets to a second set of eyes.
Procedure
1. Write the change down and capture the version being replaced
Before opening the editor, fill in the change form: which automation, what changes, why, and the expected audience size. Then capture the current live version in full: export it if the software allows, or screenshot every step, including the message wording, the segment and its filters, the opt-out exclusion, every merge field and its fallback, every delay and its unit, the send window and the channel. Acceptance: the form names the automation, the change and an expected audience count as a number, and the capture shows all seven settings for every step. Wrong looks like a form that says only "updated wording", or a capture of the text without its settings. Stop rule: no edit begins until the capture exists, because without it there is no rollback. Hazard: none physical; this is desk work.
2. Make the change in a copy, never in the live automation
Duplicate the live automation, name the copy with the date and "DRAFT", and edit only the copy; the live version runs untouched until the copy passes. Acceptance: the live automation's last-modified date is unchanged after this step, and the copy exists under a dated name. Wrong looks like editing the live version "because it is only a word". Stop rule: if the software cannot duplicate, pause the live automation before editing and record the pause time on the form, so any messages held by the pause can be accounted for. Hazard: none physical.
3. Compare every setting in the copy against the capture
Go through the seven settings from Step 1 for every step of the copy, and mark each one changed or unchanged. Every "changed" must match something the form names. Acceptance: seven settings listed per step, and the count of changed settings equals the count the form describes. Wrong looks like any setting that moved without being on the form: a delay unit that reset from days to hours, a fallback filled with sample text, a date filter left blank. Stop rule: an unlisted change is either reverted in the copy or added to the form and explained before going further; the editor does not proceed with a change they cannot explain. Hazard: none physical.
4. Test-send to staff records, one per branch
List each distinct path the conditions allow (a branch), then pick one staff-owned test record per branch: at minimum a record that should receive it, a record that should not, a record opted out of texts, a record opted out of email, and a record with an empty value in each merge field. Acceptance: the number of test records equals the number of branches, every record that should receive a message gets the right one with every merge field filled, every record that should not receives nothing, and every skipped record shows as skipped in the log. Wrong looks like a message to an opted-out record or default text in a merge field. Stop rule: any wrong result sends the change back to Step 2; fix the copy and re-run every branch, not just the one that failed. Hazard: test records must be staff-owned contact details only; never test against a real customer, which turns a test into a send.
5. Preview each message on a phone
Open each test message on a phone, for each channel. Check merge fields, links, that the text is not cut off, that the sender is recognisable, and the arrival time. Acceptance: each message opened on a phone, each link tapped through, arrival times match the delays on the form within a few minutes. Wrong looks like a link that opens a login page, a message that arrives hours early, or a text that splits into fragments. Stop rule: any fault goes back to Step 2. Hazard: if the previewer is a tech or the owner in the field, the preview is done parked; nobody opens a test message while driving.
6. Check the live audience count against the expected number
Read the count of records the copy's segment would reach today and compare it with the expected count on the form. Acceptance: the actual count is within 10 percent of the expected count (a common starting band; for small segments use a difference of a few records). Wrong looks like a count several times the expected one (usually a blank filter or a dropped condition) or one near zero. Stop rule: outside the band, stop and find out why before approval. Hazard: none physical.
7. Approval by a named second person
The approver reads the form, the setting comparison, the test results and the audience count, and signs the form with name and date. The approver opens the copy and reads the audience count themselves rather than taking the editor's word. Acceptance: the form carries an approver who is not the editor, and the approver has written the audience count they saw. Wrong looks like "looks good" by text, or the editor approving their own change. Stop rule: no approver available means the change waits. If the reason for the change is urgent, such as wrong information in a live message, the fix is to pause the live automation, which needs no approval, rather than to skip this step. Hazard: none physical.
8. Write and check the rollback
On the form, write where the pause control is, where the prior version is saved, and who rolls back; the approver then finds both without help. Acceptance: the approver locates the pause control and the saved prior version in under two minutes, and the form names the person who will roll back if needed. Wrong looks like "undo the change" with nothing saved to undo to. Stop rule: no tested rollback, no go-live. Hazard: none physical.
9. Go live at a watched time and read the first sends
Switch the copy live and the old version off when someone will be at a desk for the next two hours; Tuesday to Thursday mornings are a good default, never a Friday afternoon. Read the send log for the first ten sends, or the first hour if fewer go out. Acceptance: the first ten log entries show the expected recipients, channels, merge values and next-step times, and no queued step falls outside the send window. Wrong looks like any recipient outside the segment, a fallback value printing, or a queued step due at night. Stop rule: any mismatch, pause immediately, then roll back per Step 8 and record what went out; do not try to fix forward while it is still sending. Hazard: none physical.
10. Close the record and check it a week later
File the form. Seven days after go-live, the approver reads the replies and compares the opt-out rate with the same automation's rate before the change. Acceptance: the form is filed with a seven-day check line completed, and the opt-out rate is no more than double the prior rate. Wrong looks like a spike in opt-outs or confused replies: the change sends correctly and reads badly. Stop rule: above double, the change returns to Step 1 as a new change. Hazard: none physical.
The record this produces
One change form per change, filed with the shop's procedures: automation, date, editor, change and reason, expected and actual audience counts, the prior-version capture (attached), the setting comparison, each branch's test result, the phone preview, approver and date, rollback instructions and owner, go-live time, the first-ten-sends check, and the seven-day opt-out comparison.
The approver reads it before signing, the owner reads the file when judging whether an automation earns its keep, and whoever reconstructs a misfire reads it first, because it says what changed, when, and what the automation looked like before.
Worked pass
The office manager at a lawn and pest shop changes the spring service reminder to add lapsed customers: anyone whose plan ended in the last 12 months gets a "welcome back" version. The owner approves.
| Step | What was recorded | Result |
|---|---|---|
| 1 | Add lapsed-plan branch. Expected audience 412 active plus about 40 lapsed, about 450. Full export captured | Pass |
| 2 | Dated DRAFT copy made; live version unchanged | Pass |
| 3 | 21 settings compared (7 across 3 steps). Form describes 2 changes (segment, wording); comparison finds 3: step 2 delay unit reset from days to hours on duplication | Unlisted change found, unit set back to days, comparison re-run: 2 changed, matches form |
| 4 | Six branches, six staff records: active plan, lapsed plan, never on a plan, texts opted out, email opted out, blank plan name. Lapsed record received the active-plan wording with plan name printing as "Annual Lawn Plan" from a fallback | FAIL. Stop rule: back to Step 2 |
| 2 to 4 rerun | Lapsed branch given its own template; fallback set to skip send. All six branches re-run: correct message or nothing, blank-name record logged as skipped | Pass |
| 5 | Both channels opened on a parked phone; links work; step 2 due in 7 days | Pass |
| 6 | Copy segment count 447 against expected about 450, a difference of 3, inside 10 percent | Pass |
| 7 | Owner opened the copy, read 447 herself, signed with name and date | Pass |
| 8 | Owner found pause control and export in about a minute; office manager named | Pass |
| 9 | Live Tuesday 9:00. First ten sends: 8 active, 2 lapsed, right wording each, next steps queued 7 days out, nothing outside the send window | Pass |
| 10 | Seven-day check: opt-out rate 0.9 percent of recipients against 0.6 percent the prior spring, under double | Pass, filed |
The Step 4 failure is the one the procedure exists for: the new branch looked right in the editor and printed the wrong plan name to the very people it was written for. The re-run covered all six branches, because a fix to one template can disturb another. Step 3 caught a delay unit nobody had touched, the fault that turns a two-week sequence into an overnight one.
References
- See related: The Automated Reminder That Annoyed Every Customer
- See related: Mapping a Process Before You Automate It
- See related: The AI-Drafted Customer Message Review SOP
- See related: The Weekly AI Call Review SOP