In this article
A harmless button carried a bigger decision
Save is a promise to keep your work. It should not quietly change who may act on it.
On October 23, 2026, we found that saving a playbook in Mach also approved its steps. The label said save. The button also gave permission.
We changed the button and added a check for that exact line. Save now saves the playbook without approving every step.
That fixes one product mistake. It does not make sending safe on its own. A campaign still needs clear owners and checked actions.
When you judge a sales tool, ask someone to show what changes after Save. Read the status before and after. If permission changes too, the screen owes you a clearer choice.
This is an account of our own October 23 and 24 changes. It is not a study of customer results.
Keep four decisions apart
Your written plan is what you want to happen. Drawing gives it a proposed shape. Saving keeps the work. Approving records that a person accepts the steps.
Running is one more decision. It starts people through the plan, within the routes and limits you set.
These buttons may sit close together on a screen. What each one does should stay easy to tell apart.
In Mach, this work also marks which steps need approval and which only wait or check a condition. Approving everything as a hidden side effect blurs that.
The useful question is plain: what exact action becomes possible after this click? Ask it for saving, approving and running. Do not accept one vague answer for all three.
Try this made-up check before a real campaign
Imagine Tarang Labs, a made-up software team in Pune, preparing emails to 12 chief operating officers at US banks. Nina Patel writes the plan. Jamie Carter checks the drafts and sending choices.
The team has not agreed the wait before a follow-up. Nina needs to save her work before she leaves the page.
In this example, saving must keep the unfinished plan. It must not turn Jamie's missing check into permission.
The table shows which changes to expect and which need another decision. It is a test sheet, not a record of a real customer run.
| Action | Expected change | Separate decision |
|---|---|---|
| Draw | Proposed steps appear | Accept the proposed meaning |
| Save | Work is preserved | Approve relevant steps |
| Approve | Specific actions are accepted | Start the plan |
| Edit briefing | Old drawing becomes stale | Draw and review again |
Try the same test on a tiny internal sample before you add real buyers. Write down the status at each stage. Keep screenshots if two labels seem to mean the same thing.
Leave the follow-up step unapproved on purpose. Save the plan, close it and open it again. Jamie should still see a decision waiting. Saving an unfinished plan should not make it ready to run.
Changed instructions need another look
A checked plan can go out of date when someone edits its words. The old drawing may no longer match the plan on screen.
Our October work made that mismatch plain. A change in the first step marks the drawing out of date. Approving and running wait for a fresh drawing.
Another change dealt with drafts whose records or person had changed. Those words get another pass. They do not keep the trust of an earlier draft.
So check what an approval is tied to. Is it the person, the step, the exact words or yesterday's copy?
Our guide to fit and intent draws the same line between evidence and a decision. A good score does not prove a purchase. [1]
At Tarang Labs, Jamie notes which instructions changed and checks only those parts again. That is still a real check. A changed sender or channel can matter even when the message reads the same. Keep the earlier decision visible so the next person knows what changed.
The cost of an extra check is visible
Here is a made-up budget for Jamie's check. Allow 10 minutes for the plan, 6 for the first drafts and 4 for fixes.
At $60 an hour, those 20 minutes cost $20. If the team does that check four times a week, the example comes to $80.
These are made-up labor costs. They leave out the subscription, research and sending charges. They do not estimate fewer mistakes.
This check may feel slower than one big approve button. The point is knowing which work you accepted, not saving clicks.
Track the real checking time in your trial. If most of it goes to finding changed facts, improve the evidence view before you send more.
Ask the person checking to leave one action undecided on purpose. Saving should keep that open question visible. A good tool makes unfinished work safe to come back to. It should never require approval just to keep a draft.
Test what the button does, not its label
What we got wrong was a small label with a big side effect. Someone could save unfinished work and approve it by accident.
A check now tests the action itself. It also checks that the saved status matches the drawing's real state.
You can use the same habit without reading code. Save an unfinished plan. Reopen it. Confirm the work is still unfinished and no new permission appeared.
Then edit one important instruction. Check whether the old approval still looks valid, and ask who must check the changed action.
Before you approve a sales plan, say what the next click allows. If you cannot say it in one sentence, the steps need a clearer line.
Common questions
Does this mean Mach cannot run approved work?
No. Saving keeps a plan, and approving allows its actions. Running also depends on the sending routes you have set up.
