"My team will resist. My office manager barely uses email."
The one-button rule: automation that survives the least-technical person on the team
Most office automation fails not because the tool is bad, but because it demands a new habit from a person who is already fully loaded. Here is the design rule I hold to avoid that.
Every founder I talk to has some version of this worry.
"My team is not going to use this."
They are usually right. Most office automation fails not because the tool is bad, but because it demands a new habit from a person who is already fully loaded and mildly suspicious of the founder's new idea.
Here is the design rule I hold against every workflow before it ships.
The one-button rule
If your least-technical team member cannot use the automation with one visible action, it will not survive.
It is not a slogan. It is a hard constraint.
If Maria the office manager has to remember three steps in a specific order, the automation will not survive her holiday. If she has to log into a second tool, it will not survive her holiday. If she has to remember which of two buttons to press, she will press neither and go back to the spreadsheet.
The version that works:
- One tab, already the right one when she arrives at her desk
- One page, already loaded, showing today's drafts
- One button per draft: Approve
- One button as a fallback if something looks wrong: Ask for help (routed to the support contact named in her runbook)
That is the whole interface. Everything else — the AI, the routing, the exception handling, the reminders, the retries — is invisible to her.
Why this works
It fits an existing habit. She was already opening the browser at 9am. Now the tab she opens is the approval page. Not a new habit. A slightly different one.
It is faster than manual. If clicking Approve takes 3 seconds and doing it manually took 10 minutes, she does not need to be convinced. The convincing happens in week one.
It has a human escape hatch. The "Ask for help" button is not decoration. It is the reason she trusts the system. If something looks wrong, she has a real person to route to, named in her runbook.
What "trained" actually means
I do not run training sessions. Training sessions are how consultants make you feel like you got your money's worth. They are also the thing that dies fastest.
Instead I write a two-page runbook. It has three sections:
- What you will see when you open the page each morning
- What the two buttons do
- Who to call if something looks wrong, and what to do while you wait
That is the runbook. It fits on two pages because the tool fits in two buttons. If the runbook needed ten pages, the tool would be wrong.
Where this rule gets uncomfortable
The rule forces us to say no to features, and that is uncomfortable early on.
You will want a dashboard. Reporting. Bulk-approve. Filters. The last 30 days at a glance.
Some of that is legitimate. Most of it is not for Maria. It is for you. We build it in a separate founder view she does not see and does not have to learn.
Maria has one page and two buttons. You have your dashboard. Both of you are happier.
What this article does not claim
The rule does not mean every automation is trivial. Some workflows need more than one button on the human side. In those cases, I split the workflow into steps, each with its own one-button screen, each owned by the right person.
It also does not mean the team never touches the underlying tools. They do, when we set up. After go-live, the one-button rule is the contract.
The keeper
If your least-technical person cannot use it on Monday morning, it will not exist by Friday.
The tools are not the risk. The daily habit is the risk. The one-button rule keeps the habit small enough to survive.
Talk to me
If a team member is politely refusing to use the last three tools you bought, book 30 minutes. That pattern is often the tool's fault, not the person's.