Three workflows I wouldn't build today

Three workflows I wouldn't build today

Most consulting writing celebrates wins. It sells better. But anyone who runs automation in production learns more from the workflows that should never have been built than from the ones that worked.

I've shipped hundreds of workflows for clients over the last four years. Some still run today, generating real value. Others quietly got switched off after a few months because they were creating more trouble than they solved. Here are three from my own past that I would not build the same way again.

The Slack notification for every successful run

A client in 2023, thirty employees, B2B service business. We built a workflow to qualify inbound contact form requests and push them into HubSpot. The client wanted Slack notifications to the sales team for each new lead. We added them. Job done.

Three months later the sales lead asked me to turn them off.

What had happened was simple. In the first month, seven leads per week came in. Seven Slack pings the team read and acted on. Good. By month three, lead volume had grown to forty per week. Forty pings in a channel of twelve people. The first ten got read, the next twenty skimmed, the last ten ignored. When an interesting lead came in, it got buried among the routine ones.

The lesson is older than software: notifications about "something happened" are not a feature, they are noise. What deserves notification is the exception. The error. The deal over a threshold. The repeat customer with an open renewal. Not every routine event.

Today I design notifications the same way you'd design a pager. What does someone need to know immediately, because waiting causes damage? Anything else belongs in a daily or weekly digest.

The auto-updating CRM from email signatures

Another client, 2024, IT services firm with a hundred staff. We built a workflow that scanned incoming email, extracted contact signatures, and updated CRM records automatically. It seemed elegant. It also turned out to be wrong.

What I had not accounted for: email signatures are not a reliable source of truth. People change jobs and write from their old address before forwarding kicks in. Auto-replies include the contact details of stand-ins, who got overwritten into the primary contact record. Subcontractors with their own company suffixes ended up assigned to the wrong organisation in the CRM.

After four months, we found 380 silent data errors. Sales called the wrong people. An important reminder went to the old address of a CFO who had left the company two months earlier, because someone else's auto-reply had overwritten his record. The clean-up took two weeks. The damaged trust in the CRM lasted much longer.

I no longer build workflows that mutate production databases without human confirmation. If the workflow proposes a change, it lands in a review queue. A human confirms or rejects. Only then does it commit.

This is slower. It is also the only way to keep a CRM from becoming a database of guesses.

The three-stage approval workflow for expenses under fifty euros

Third example. A professional services client, fifteen staff. They had a messy expense approval process. We built a clean one. Employee submits, team lead approves, accounting books. Three stages, each with Slack notifications and reminders.

After three months we checked the numbers. Employees were submitting fewer expenses than before. Not because they were travelling less. Because for a fourteen-euro taxi ride, the friction of the process was higher than the reimbursement was worth. They were paying it themselves.

We had built a workflow that solved "expenses sit too long unpaid" and quietly created a new problem: employees absorbing small costs because the process was too heavy for the amount involved. That is bad on several axes: questionable under labour law, questionable under tax law, and a signal that the process is wrong for what it processes.

Today I look at the typical amount that will flow through any approval workflow before designing it. If the average item is under a hundred euros, I do not build a multi-stage process. I build a flat allowance with sample-based audits. Approval costs time. Time is more expensive than what is being approved, if the thing being approved is small.

The pattern behind all three

Three mistakes, three lessons. When I sum them up, the pattern is something I now spot more often than I used to.

First. Automation should solve a problem the people involved recognise as a problem. Not one invented from outside. In none of the three cases had anyone complained: not about missing lead updates, not about CRM gaps, not about loose oversight on small expenses.

Second. Every automation moves costs somewhere. It rarely deletes them. The first one moved cognitive load from the developer to the sales team. With the second, error sources shifted from manual entry to automated entry, where they are harder to detect. In the third, costs moved from accounting into the pockets of employees.

If you cannot say where the costs are going, you have not finished thinking the workflow through.

Third. Reversibility is undervalued. All three workflows ran for months before anyone understood the effect they were having. If we could have stopped them sooner, the damage would have been smaller. Today I design production workflows with a kill switch from day one. Pause should be a button, not a project.

What I do differently now

Before any new automation, I ask three questions. What happens if this workflow does not exist? Who pays the costs it moves? How do I switch it off if it has the wrong effect?

If you can't answer the first two clearly, don't build it. If you can't answer the third, don't put it into production.

These questions are not original. They are unusual because the automation conversation is rarely about whether something should be built. It is about whether it can be built.

If you want to know which workflows in your own company are doing more harm than good today, the free Automations Check gives you a first answer in about 30 minutes.