Playbooks take less time than automation, and are often good enough.
Playbooks are the middle ground I reach for in these circumstances. When I see a process like this, instead of either doing nothing or just diving in and writing some code, I’ll first write a playbook. A playbook is nothing more than a set of instructions for performing the task – a “recipe” if you will. The key is to be as specific as possible. If this is some sort of task that involves code, you can even include bits of code or shell commands that someone following the playbook could copy and paste.
This gets a few steps closer to the goals of automation – consistency, repeatability, reliability – at a fraction of the effort. And, if you later decide that automation is worth the effort, the playbook serves as a detailed specification for your code.
Added benefit for me: I don’t code, not even writing AppleScript, or creating anything but the simplest Keyboard Maestro automations. I can’t even figure out how to use iOS shortcuts. One day I’ll take MacSparky’s courses in those things and become a wizard, but until then, playbooks seem worth looking into.
That said, I have found playbooks are often unnecessary when one step follows the other naturally. I can walk through a short, but relatively complex process that way. The only task on my to-do list will be “do the thing,” and “the thing” may be a task that takes hours, days, or weeks to complete.
I do them as breadcrumbs not playbooks. It may seem overly explicit but I have things as detailed as the following (partial description) Here’s a piece from how to incorporate EBVs into my LambTracker database when I get them back from NSIP
Waiting for e-mail that NSIP data has been run
Download the .ZIP file from Sheep Genetics Site legacy.sheepgenetics.org.au - /updates/
UnZip using Terminal (required due to Password protection)
Start a terminal window
enter the password ****************
Move the files to the NSIP Folder for this run in Active_Projects
Move these files
Open ATFEBV.DBF in Libre Office and save as an ODS sheet
And so on,
OK so 95% of the time I can do them w/o looking at the instructions but the 5% that I need them I REALLY need them.
It’s also an Oh S**t backup so that if I am dead or disabled someone else can still do the tasks correctly.
I tend to do something quite similar, as described by @OogieM . I try to make notes on tasks that are complex, multi step, or not obvious, especially when they are things I don’t do regularly and hence am not likely to remember in sufficient detail the next time they are do.
For example: One task is doing reconciliation of checks from my (now former) business that we had written but never were cashed, as periodically the state requires filing those checks as unclaimed funds. The process of finding the correct data in QuickBooks, determining which checks have to be filed, completing the correct forms for the state, and entering the appropriate “journal entry” into QB for this is multi-step and which reports from QB are needed is far from obvious, so I have a step by step algorithm written out for this purpose so I can step through it.
Another example, would be setting up a process that allows remote access to a piece of equipment at work. This requires setting up a vpn using third party software not suppled with MacOS (I use a FOSS package), logging in to a corporate Windows server, bouncing from that server to the work place, logging in again, and configuring the connection. Some of this is automated (a zsh script to set up the necessary VPN connection and tunnels, but some cannot be as it requires typing usernames and passwords into online servers. As a result, I have a detailed step by step that I can use when needed.
If it is something that can be automatic AND I do it frequently enough, I will write scripts, Automator actions, KM macros, etc as needed, but I still keep the step by step notes in the event that the process ever needs upgrading and as a reference so I can recall how I did it should I ever need to recreate the workflow and/or help someone else.