Most advice about automating admin work assumes you will buy something. For a large share of what an executive assistant repeats every week, you do not need to. Here is what I build, and how I decide what is worth building.
Most advice about automating administrative work assumes you will buy something. A connector platform, an AI assistant, a workflow tool with a monthly seat price and a limit on runs.
For a large share of what an executive assistant actually repeats, you do not need any of that. If the business already runs on Google Workspace, you have a scripting environment sitting inside it, it is free, and it will do things no connector platform will let you do.
I have built and maintained more than forty automation rules and nine scheduled jobs this way in a live agency, and retired two paid automation subscriptions in the process. This is how I decide what to build and how I build it.
Why scripts rather than a subscription
Connector platforms are excellent for what they do, and I still use them. But for recurring internal work they have three properties that eventually bite.
- They price by volume. The automation that saves the most time is usually the one that runs most often, which is also the one that costs most to keep.
- They constrain the logic. Anything conditional beyond a certain complexity turns into an unreadable chain of branches that only its author understands.
- They are a dependency nobody owns. When the person who built it leaves, the account, the billing and the logic leave with them.
A script sitting in the company's own Workspace has none of those. It costs nothing to run, the logic is readable by anyone who can read a paragraph of code, and it belongs to the business rather than to a login.
The goal is not to avoid paying for software. It is to own the automations that are load-bearing.
What to build first, and what not to
Before any code, the same test applies that applies to all automation: high frequency, low judgment, already written down. A process failing any of the three is not ready, and pointing a script at an undefined workflow produces the same mess faster.
| Good first build | Why |
|---|---|
| Recurring reporting assembled by hand | Happens weekly, output already defined, nobody decides anything |
| A daily brief pulled from a calendar or tracker | Same shape every day, and it replaces a meeting held to find out what is happening |
| Scheduled reminders driven by a date in a sheet | Removes a monitoring job nobody was formally given |
| Form submission into a tracked item with an owner | Kills the habit of checking four channels for requests |
What not to start with: anything that happens twice a year, anything where the right answer depends on the client or the week, and anything three people would describe differently. The first wastes the build, the second is a decision rather than a process, and the third means you would be automating a disagreement.
The anatomy of a working automation
Every one I have built has the same four parts, and knowing them makes the code much less intimidating than it looks.
1. The trigger
Either time-based, meaning it runs on a schedule you set, or event-based, meaning it fires when something happens such as a form submission or an edit. Time-based covers most reporting; event-based covers most intake.
2. The fetch
Reading from wherever the truth actually lives. A spreadsheet, a calendar, a form response sheet, or an external system that exposes an interface. This is usually the shortest part.
3. The logic
Filtering to what matters, working out what is overdue or missing, and deciding who needs to know. This is where a script beats a connector, because a condition that takes six branches in a visual builder takes three lines here.
4. The delivery
Sending it to the place people already look. This last part matters more than people expect. A report that lands in a folder is a report nobody reads. Deliver into email or the chat channel the team already has open.
The five rules I follow
Learned mostly by getting them wrong first.
Write down the manual process before you write any code. Not a flowchart. A short account of what actually happens, drafted from doing the task with the document open. If two people cannot agree on the steps, you have found a problem that no script will fix.
Measure the before. How long it takes, how often it runs, how often it goes wrong. Four weeks of that costs nothing and it is the only way you will ever be able to demonstrate that the automation paid for itself. Most operators skip this and then cannot prove their own work.
Make it fail loudly. A silent failure is worse than no automation, because everyone now trusts a thing that stopped working. Every script I run sends a message when it errors, and I would rather have a noisy false alarm than a quiet gap.
Automate the assembly, never the judgment. The script gathers, formats and delivers. A person reads it and decides what it means. The moment a script starts making calls that require accountability, you have built something nobody can answer for.
Leave a comment saying why. Six months later the code will be obvious and the reasoning will not. One line explaining why the threshold is seven days rather than five saves the next person, who is often you.
Automation does not create order. It multiplies whatever order already exists, including none.
Where AI actually fits
I use AI heavily in this work, and specifically for two things: writing and debugging the scripts themselves, and pressure-testing the logic before deployment. Describing a workflow in plain English and getting a working first draft back collapses the barrier that used to keep this kind of automation out of reach for non-developers.
What I do not do is let a model decide anything at runtime. The script is deterministic; the same inputs produce the same outputs, and when it breaks I can read exactly why. That predictability is the whole reason the business can rely on it.
The honest version of the skill in 2026 is not writing code from scratch. It is knowing precisely what should be built, being able to read what comes back, and testing it properly before anyone depends on it.
Start with one
Pick the most boring thing you do every week. Not the most annoying, because annoying usually means unusual and unusual does not repay a build. The dull, frequent, unremarkable one.
Write down how it currently works. Time it for a month. Then build the smallest version that removes the gathering and leaves the judgment with you.
One working automation will convince you to build the next, and momentum beats a master plan.