Business Process Automation: What Should You Automate First?

The problem, described by its symptom

You notice it as a queue that never drains. The person who owns content, outbound and lead follow-up is doing the same sequence of clicks every weekday: open the spreadsheet, copy the row, paste it into a language model, copy the output, paste it into the CMS, update the sitemap, rebuild the hub, submit the URL. Nothing about that sequence is hard. It is just long, and it is identical every time.

The symptom is not that work stops. The symptom is that work happens late and unevenly. The blog goes three days without a post, then four arrive in one afternoon. A lead fills a form on Friday night and hears nothing until Tuesday. The Instagram grid has a gap in the middle of a week and nobody can explain why.

A second symptom appears later, and it is more expensive: nobody can say which parts of the process are load-bearing. If the person doing the work goes on holiday, the whole chain stops, and there is no document that says what the chain actually was. The knowledge lives in the operator's head, not in a file.

How to diagnose it

Do not start with a tool. Start with a time log. For two weeks, every time you touch the content or lead pipeline, write one line: what you did, how long it took, and what would have broken if you had skipped it. A plain spreadsheet is enough. The point is to find steps that repeat, not steps that are interesting.

Then check whether each repeated step already has a written checklist. If it does not, that is your answer for that step: write the checklist. A robot built on an undocumented process will encode whatever the operator happened to do that day, including the mistakes.

On the server side, the diagnostic commands are simple. List what is actually scheduled:

crontab -l
systemctl list-timers --all

Then check what is running but not scheduled, which is where orphaned automation hides:

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Size}}'
docker system df
du -sh /var/lib/docker/volumes/* | sort -h

For each container, ask a single question: which process does this serve, and who owns that process? If the process was rebuilt or retired and the container is still running, it is cost with no output. Check disk pressure before it becomes an incident:

df -h

For the content pipeline specifically, look at the failure surface. Find every place where a manual step exists and ask what happens when it is skipped. If the answer is "nothing visible for a week", that step is a candidate for automation. If the answer is "the whole site breaks immediately", it is also a candidate, because the failure is loud enough to monitor.

What the data showed

In a one-person content and lead operation we automated, the time log produced a short list. Twelve scheduled automations now run on one server under cron. Every one of them was built after the manual step hurt, never before. That ordering matters: the automation was a response to a measured pain, not a project.

The examples, with the manual step each one removed:

• Blog article engine. Reads one master spreadsheet (PAUTA-MESTRE.xlsx), calls a language model, applies validation, writes HTML, updates the sitemap, rebuilds the blog hub, and pings IndexNow. Runs Monday to Friday at 12:00. Manual step removed: the entire copy, paste, publish, submit sequence, repeated five days a week.
• Instagram and Facebook feed poster, plus Stories filler. Reads the same spreadsheet. Manual step removed: opening each app, uploading, writing the caption again, and filling the Stories slot.
• LinkedIn scheduler. Manual step removed: logging in daily and posting by hand.
• AI news radar that proposes topics. Manual step removed: scanning sources each morning to decide what to write about.
• SMS to new leads, one message per lead. Manual step removed: noticing a new form submission and sending a first reply.
• Server monitor. Restarts a database service and alerts on Telegram. Covers two client systems. Manual step removed: discovering the outage from a user complaint.

The anti-example came from the same operation. A workflow-tool container ran for six months with zero workflows, because the process it had been set up to serve was rebuilt and the container was never retired. It held 5 GB and was the first thing deleted when the disk hit 94%. Nobody had missed it, because nobody owned it.

That is the pattern worth naming. The blog engine, the poster, the scheduler and the monitor all have an owner and a visible output. The empty container had neither. Automation that nobody owns becomes cost.

Mapping the candidates

The fix

The rule that came out of the operation: the first thing to automate is the step that is (a) repeated at least weekly, (b) already has a written checklist, and (c) fails visibly when skipped. Anything without a checklist gets a checklist first, not a robot.

Apply the rule in order. Write the checklist for the step you intend to automate. The checklist becomes the specification, and later it becomes the validation step inside the automation. In the blog engine, that validation is a real stage: the language model output is checked before it is written to disk. If validation fails, the run stops instead of publishing something wrong.

Then put the automation under cron on a schedule you can reason about. A weekday publishing job at a fixed hour is easier to debug than a chain of triggers:

# m h dom mon dow command
0 12 * * 1-5 /opt/pipeline/blog_engine.sh >> /var/log/blog_engine.log 2>&1

Keep the state in one place. The master spreadsheet is the single source for the blog engine, the Instagram and Facebook poster and the Stories filler. One input, several outputs. When you want to change what gets published, you edit one row, not four tools.

For lead follow-up, the automation is deliberately narrow: one SMS per lead. It does not sequence, it does not retry, it does not decide. It removes the manual step of noticing the submission. Anything more elaborate would need an owner and a reason.

For infrastructure, the monitor is the same shape. It watches the database service for two client systems, restarts it, and sends a Telegram alert. The alert matters as much as the restart, because a silent restart hides a recurring fault.

Finally, audit for orphans on a schedule. The 5 GB container survived because no audit existed. A monthly check is enough:

docker ps --format '{{.Names}} {{.Status}}'
docker system df
df -h

If a container serves no process, remove it. If a scheduled job has no owner, either assign one or delete the job. The full set of patterns we use is documented at https://prospectia.space/en/automation/.

How to verify the fix worked

Measure before and after on the same three axes.

• Output cadence. Before, count the days in the last month when the blog, the feed and the LinkedIn page each went without a post. After, count again. The weekday job should produce a post every weekday. If it does not, read the log, not the CMS.
• Response time to a new lead. Before, note the gap between form submission and first contact. After, the SMS fires once per lead, so the gap should be the time it takes the form handler to run, not the time it takes a person to check email.
• Incident detection. Before, note how outages were discovered, usually by a user. After, the monitor restarts the service and sends a Telegram alert. Count how many alerts arrive and how many of those were real outages. An alert that fires constantly is a monitoring bug, not a healthy system.

Add one hygiene metric: disk usage and container count. Before, the disk reached 94% and an unowned container held 5 GB. After the cleanup, track both monthly. If container count climbs without a matching process, you are rebuilding the same problem.

Do not measure "time saved" in the abstract. Measure the specific step that disappeared. The blog engine removed the copy, paste, publish and submit sequence, five days a week. That is a countable event, and it is the one you can verify.

Frequently asked questions