How to decide what your software should do on its own

Two things happen in your business every week. One sends a delay notice to a customer whose order missed its window. The other changes the price of your best selling product.

Ask which one your software should be allowed to do without you and the instinct is to pick the notice, because it feels smaller. The instinct is right. The reason is wrong. The notice is safe to hand over because a correction takes a minute and it reaches one person. The price change is risky not because it matters more, but because it applies to everyone at once and nobody may notice for a week.

That difference is the whole framework. When people sort their operations, they sort by importance and start at the top. Importance tells you how much you care about the outcome. It tells you close to nothing about whether a machine should be doing it.

Five questions to ask about any action

Take any single action your business performs. Not a process, a single action, written as a verb. Issue a refund. Reorder stock. Cancel a subscription. Send an invoice. Pause an ad. Then answer these five questions honestly.

If it goes wrong, how hard is it to undo?

The test is concrete. Can one person put it back within an hour, using tools they already have, without anybody outside the company being affected. Sending a notice, applying a tag, creating a draft order, moving a ticket to another queue: all easy to reverse. Paying money out, deleting records, emailing your whole list, cancelling somebody’s account: hard or impossible. An apology is not an undo.

If it goes wrong, how quickly will you find out?

Name the specific way you would learn. Not “we would probably catch it”. The exact signal. If the honest answer is “it would show up in the monthly report” or “a customer would eventually complain”, the action is silent. Silent mistakes repeat while you are not looking, and by the time you see one you are looking at three hundred. A loud action fails visibly the first time.

How far does one mistake reach?

Does a single bad decision touch one order, or every order. This is the difference between a wrong refund and a wrong refund rule. One is an incident, the other is a bill. Reach can be designed down: a limit per action, a limit per hour, a limit per customer. An action with unbounded reach and no cap is not a candidate for anything.

How often does it happen?

Twenty times a day, or four times a year. Frequency matters more than it looks. Rare actions are poor candidates even when they are simple. Nobody writes down an accurate rule for something they do twice a year, and you never gather enough evidence to know if the rule is right. Frequent actions give you a rule people remember and enough repetitions to see the exceptions.

Does doing it well need something the machine cannot see?

Watch the person do it. If they open a second screen to check something, that is data, and the system can have it. If they say “I know this customer”, or “not this week, their last delivery was a mess”, or they read the tone of an email and decide to be generous, that is context living outside your systems. You have two choices then. Put that context into the system so it becomes a rule, or leave the action with a person. Pretending it is not there is how autonomous systems embarrass you.

Three lanes, not two

Score your action against the five and it lands in one of three places.

It acts on its own. Reversible, loud when it fails, small reach, happens often, needs no context the system lacks. These are the ones to hand over first, and they are usually unglamorous. Restock a returned unit. Send the delay notice. Flag a payment that failed twice.

It prepares and waits. This is the lane most work belongs in, and the one people forget exists. The software does everything except the final commitment. It gathers the order history, the delivery record, the previous claims, the amount, the rule that applies, and the exact action it proposes to take. Then it waits for one click.

It stays with a person. Anything that fails the last question, and anything that is both hard to undo and silent when wrong. A machine will do these confidently and badly.

The middle lane does most of the work

The choice is not between software that does nothing and software that acts freely. Between those two there is a version where the decision is fully prepared and a person spends four seconds on it.

A refund review that took ten minutes of hunting across three screens becomes one screen with everything assembled and a proposed answer. The human keeps the judgement. The work disappears. And because the system had to state what it would have done, you get a running comparison between its answer and the human’s.

That comparison is how an action graduates. Watch how often the person clicks approve without changing anything. If a rule proposes the same thing your team would have chosen, week after week, on hundreds of cases, you are no longer guessing about whether to let it run alone. If the person keeps editing the proposal, the rule is wrong, and their edits tell you exactly what it is missing. Either outcome is useful.

Graduation runs backwards too. When an action that runs alone produces a bad result, move it back to the middle lane while you fix the rule. That beats turning everything off, and the work keeps flowing.

In our own Shopify apps, xupsell and xbundle, the actions that affect one shopper’s session run on their own. The ones that would change what every shopper sees are the ones we kept behind a click.

Run your own list

Set aside an hour. Write down every recurring action in one part of your business, one verb per line. Aim for twenty. Then for each one, answer the five questions with a yes or a no, and put it in a lane.

Two things usually happen. Most of the list lands in the middle lane, which is the correct answer and not a failure. And a few items you assumed were complicated turn out to be reversible, loud, small and frequent, which means they have been costing you attention for no reason.

Start with the most frequent item in the top lane, not the most valuable one. The first action you hand over is not about the return. It is about finding out whether your rules are written well enough to be followed literally. Frequent, reversible actions teach you that in a week. Important, rare ones teach you nothing for a year.

Anything running on its own needs three things around it: a hard limit on what it may do, a permanent record of what it saw and what it did, and a control that stops it immediately without anyone touching the software.

If you want to walk your own list through with someone, book a call.