How to Automate Repetitive Tasks at Work Without Coding

Which tasks should you automate first?

Most people pick the wrong task. They choose the one that annoys them most, typically a large quarterly job full of judgment calls. The better candidates are boring, frequent and predictable, and they tend to hide in plain sight: the twelve-minute download-and-paste you do every morning, the welcome email you retype, the folder of files you rename at month end.

Three numbers tell you whether a task is worth it. Frequency: how many times a year it runs (a daily task runs roughly 230 times in a working year, a weekly one about 46). Minutes: how long one run really takes, timed with a stopwatch and including the hunt for the file. Error cost: what happens when it goes wrong. Manual copying is where mistakes breed. The European Spreadsheet Risks Interest Group keeps a public list of costly spreadsheet errors, including the 2020 case in which nearly 16,000 positive COVID-19 results were missed in England because an Excel file ran out of rows.

Then discount for two things. Rule clarity: could you write the task as 'if this, then that' with no 'it depends'? And build effort: is it a ten-minute formula or a multi-week project that needs approval? A simple score works well: annual hours, weighted up for error risk, multiplied by rule clarity and divided by build effort. Twelve minutes a day comes to about 46 hours a year, which often outranks the job you dread.

• Copying something from one place to another
• Reformatting data so another system or person accepts it
• Chasing people on a schedule
• Assembling the same document from the same sources
• Filing things by a naming rule

How do you map a workflow before automating it?

You cannot hand over a job you can't describe, to a colleague or to software. Every automation has four parts. The trigger is what starts it: a time, an event such as a new form response, or a person pressing a button. The steps are what happens, in order, each written as one verb and one object. The decisions are the points where the path splits, each with a rule that can be checked without opinion. The output is what exists at the end, where it lands and who receives it.

Do the task once, slowly, and narrate every click. Note the exact names of files, tabs and columns. Then add the part beginners skip: what should happen in the awkward cases. A blank cell, a duplicate, a file that arrives late, a renamed header. For each, decide whether the automation should skip, stop or tell you. Finally, mark the human checkpoint, the place where you still want eyes on the result before anything goes out.

Ask a colleague to read the page. There is nearly always a step that lived only in your head. If process mapping is new to you, the Flowcharts and Process Logic assessment on AssessAll is a quick way to see how comfortable you are with this kind of thinking before you start.

Which automation tool should you use?

Use the lightest tool that works. Think of four rungs on a ladder and start at the bottom. Each rung up adds power and adds something that can break while you are not looking.

Scripts deserve a short explanation. Google describes Apps Script as a platform for building business applications that integrate with Google Workspace, written in JavaScript in a browser-based editor with nothing to install. Microsoft describes Office Scripts as a way to turn manual Excel steps into reusable scripts, with an Action Recorder that captures your actions and the option to run scripts through Power Automate on a schedule or in response to events. Connector tools such as Zapier, Make and n8n (examples, not recommendations) pass data between separate apps. Names, plans and limits change often, so check each vendor's current documentation.

How do you get an AI assistant to write the script?

Treat the assistant (ChatGPT, Gemini, Claude, Copilot or your company's approved tool) as a fast junior colleague who has never seen your files and will not admit to guessing. A vague request gets a script for a process it invented. A precise brief gets something close to usable.

A good brief has six parts: the platform and the fact that you are not a programmer; your workflow map; exact sheet names, column headers and three rows of invented sample data; the rules for awkward cases; safety rails; and how you want the answer. Safety rails matter most: 'work only on a sheet named Test', 'process at most five rows', 'create drafts, never send', 'write a log line for every row'. Ask it to question you before writing anything.

Then read before you run. Ask for a line-by-line explanation, a list of every place the script reads, changes, deletes or sends, and five ways it could go wrong. Check that it uses only the names you gave it, that nothing says delete or clear unexpectedly, and that no password or key is typed into the code. Assistants are often right. They also invent function names, mishandle dates and rarely think about security unless asked. If an explanation does not make sense, do not run the script.

• Never paste real personal or confidential data into a chat; use invented rows of the same shape
• Save the final brief with your notes: in six months it is worth more than the code

Do you need permission from IT to automate your work?

For formulas and built-in features in approved apps, usually not. For scripts, tell your manager and check the policy. For anything that sends work data to an outside service, ask first, every time.

The UK's National Cyber Security Centre describes unapproved tools used for work as shadow IT, and notes that it is rarely malicious: it normally happens because staff are struggling to get a task done with the tools they have. The same guidance encourages organisations to avoid blame and to make approval easier. Your side of the bargain is to ask early and specifically. Say what the automation does in two sentences, which data it touches and at what sensitivity, which accounts it uses, where data is stored, who owns it and how it is switched off.

Three facts are worth knowing before you ask. First, a script acts as you: Google's documentation states that installable triggers always run under the account of the person who created them, so the emails come from your address. Second, connector platforms hold logins to your other accounts, which is why security teams care about them. OWASP's Low-Code/No-Code Top 10 lists risks such as authorisation misuse, data leakage and poor handling of secrets. Third, personal data is covered by privacy law in most countries. This guide is educational, not legal advice: check your local law and company policy.

How do you test an automation safely?

Testing means trying to make it fail while failure is still free. Work through four stages. First, a copy: duplicate the file, put TEST in the name and replace real email addresses with your own. Second, awkward data: blank rows, missing fields, duplicates, names with apostrophes and accents, dates typed as text, amounts with currency symbols, rows already processed, zero rows and several hundred rows. Third, a pilot: real data with the safety rails on, drafts instead of sending, for two full cycles. Fourth, live with a log.

One test reveals more than any other: run the automation twice on the same data. The second run should do nothing. If it sends again or adds rows again, the 'already handled' stamp is missing, and that must be fixed before anything else.

Check platform limits too. As an example of the ceilings that exist, Google's published Apps Script quotas currently list a six-minute limit per script execution and 100 email recipients a day for consumer accounts against 1,500 for Workspace accounts, and state that quotas can change without notice. Finally, know your undo: how to switch it off in under a minute, where the backup is, and how you would reverse what it did. Sent email cannot be recalled, which is why anything that emails people deserves the longest pilot.

What do you do when an automation breaks?

Ask what changed before asking what is wrong with the code. Automations rarely fail because their logic decays. They fail because the world around them moved: a renamed column, an expired login, a quota reached, a paused trigger, or occasionally a platform feature that was renamed or retired.

The method is short. If it is doing harm, switch it off first. Copy the error message exactly, with the line number. Look at the run history to find the last success. Use the log to find the failing step. Change one thing, on a copy, and test. Then write down what happened. If you have been guessing for an hour, restore the last version that worked, do the task by hand this week and ask for help with the error and the log in hand.

How do you keep automations alive and hand them over?

An automation nobody understands is a liability with a countdown. Write one page per automation: what it does and why, owner and backup owner, where it lives, the trigger, the data and its sensitivity, accounts and permissions, how to switch it off, how to tell it is working, what commonly goes wrong, and a change log. Attach the workflow map, because it doubles as the manual procedure if the automation ever stops.

Keep a light rhythm: a two-minute weekly glance at the log and a twenty-minute quarterly review that asks whether it is still needed and whether its permissions are still as narrow as possible. When you change role, transfer ownership properly with IT's help, since scripts run under their creator's account. And count what you get back: runs, minutes saved and minutes spent fixing. An automation that needs more fixing than it saves should be retired.

If you want the whole method with tools attached, the Automate the Boring Parts of Your Job kit from Bodhih Training includes a scoring and ROI workbook, ten recipes with prompts and test plans, a workflow map worksheet, safety checklists and a ten-week plan. Skills like this are built mostly by doing: Jobulary's explanation of the 70-20-10 model is a useful frame for planning that practice.