Automation Projects Don’t End at Delivery: What Happens After?

People argue endlessly over tools. With new ones launching every day, the question every technical person has to answer is still the same: what do I use?

The answer is usually a mix of reasons. I know how to use it. It’s the fastest way to do the job. It’s the cheapest. It doesn’t need heavy support or maintenance. The client already uses it, so why not use it here too? It doesn’t depend on other things. Or the skills available limit the options.

Two sides to the same decision

Leaving systems building aside, when it comes to automation, those answers help decide which route to follow. Some relate to the person building the flow. Others relate to the client’s context. In short, it comes down to skills, budget and time.

But there is one element that is sometimes forgotten: what happens after?

Why automation project support matters

Automation flows are great when they work. When they don’t, it can take technical skills to understand what went wrong. And when changes or adjustments are needed, how easy they are depends on how the arrangement was set up in the first place.

That is why automation project support should be discussed by both parties before the work starts, not after something breaks. It’s the one lesson I’ve learnt from doing a lot of automation over the years: even when a flow is simple or easy to use, some clients will still need assistance, and how that works matters.

Questions to agree before you build

• Who fixes it when it stops working?
• Who handles changes and adjustments later, and how?
• Who supports the people who use it every day?

Not taking this into account harms both parties in the long run.

When you build or buy an automation, who is responsible for it once it’s live? I’d like to hear how you handle it.