I’ve seen this advice floating around a lot, particularly when it comes to AI: "Don't just automate your existing processes; reimagine them entirely." This sounds great in theory, but in practice, it’s incredibly tricky to do. How do you "reimagine" your existing workflows without getting totally lost in the weeds? Or get stuck figuring out where to start?

I see lots of people giving this advice, but very few people explain how to do it. 

I’ve found that a good approach to the "how" lies in business goals. By leading with the outcome you want to achieve, rather than the task you want to finish, you naturally begin to see your business holistically, and view the automation potential through that lens. 

Yes, the efficiency outputs are great if you’re building those first quick and easy automations. But for a multi-layered optimization strategy in a small-to-medium business, or a transformation strategy in a large enterprise, we really want to get much more out of these automations. We want our automations to be strategic for our business. We also want to get more bang for our buck.

So often, once we build the automation that saves time, we tend to stop there. With more experience now, I’ve found that trying to build something more deliberate from the outset helps. And one way to do this: map your automations to your business goals. Like you would if you were building a product.  

There is an ongoing debate about whether to build completely new AI-driven workflows or enhance existing ones. But, at the current pace of AI development, even brand-new "greenfield" workflows can become legacy relics pretty fast. So, leaving aside the debate of existing Vs new for a moment, there is risk involved in automating workflows with rigid solutions because these solutions may become out-of-date pretty quickly. 

If you anchor your automation strategy to business goals, you naturally create a more flexible architecture. Goals evolve, as does your business, so you want to be able to pivot, and you want your automation platform to support this. Focusing on the underlying problem (the outcome) allows you to adapt your technical "how" as your business goals evolve.

I’ve realized that often starting with the task is actually backwards. Truly "thoughtful" automation starts with business goals. When you lead with a high-level goal, you begin to discover surprising places where automations can pop up. Or areas where you can repurpose the output of automations. "Boring" administrative data might become a strategic asset. Or that department that popped up once a year with an annual report might suddenly become useful. 

I’ll demonstrate with a simple real-world example.  

My partner runs a software development company that has a YouTube education channel. As a result, he tests out a lot of new software tools every month.

His company has a clear objective: To provide the best coverage of emerging lowcode developer tools on its YouTube channel. Obviously that leads to questions like: what is the coverage like right now? Are there gaps? We need to know the current state of play before we can figure out what to improve. 

Meanwhile, I was helping with the company bookkeeping (yes, I drew a very short straw!), which led me to identify a common overlap: unreconciled transactions. We trial dozens of new tools. Our accounting software often hits a wall when reconciling these transactions because they are too new to have "suggested categories." Usually, this is just a manual, admin headache. 

But because I was already aware of the YouTube coverage business goal, I was able to see how these "unknown" transactions were able to feed into the tool coverage business goal.

I built an automation to solve a friction point in our financial workflow: reconciling unknown transactions using AI. But because I was viewing this through the lens of the business goal, I saw a "second life" for that data: the automation pushes that metadata into our content research pipeline.

The automation revealed data such as:

Without this goal-first mindset, I would have been slow to realize the potential of this small automation. 

The real power of this goal-first approach is that it doesn't stop with one automation. Or two. Once you connect automation to a business goal, you can start to see "stacking" potential and new automations emerge. 

For example, we can take the data from this bookkeeping bot and combine it with other automation outputs, such as:

You get the idea!

By anchoring all of these separate automations to the same business goal—improving tool coverage—they stop being isolated scripts and start becoming a unified intelligence engine, fuelled by the context of your business. 

Admittedly, in a small team, it’s easier to make these connections. It’s easier to zoom out to see the bigger picture. I had access to the bookkeeping, and I was aware of the YouTube business goal, so the link is more obvious to me.

In a large corporation, those two functions might be separated by five floors, three directors, and two different software ecosystems. And of course, not everyone might know the business goals in the first place. Or they may not be top of mind. 

This is why human-first, thoughtful automation is a good overall approach. 

Just like rolling out a large software implementations, planning and rolling out automations need to follow similar human-first best practices, like observing how people do their jobs, common areas of confusion, uncertainty, common overlaps and interdependencies, behavioural insights, cultural insights, interdependencies, in addition to the technical information like architecture, software, data, and so on. Building up this big picture will begin to surface the potential automation connections.

(One of the topics I’ll explore in a later article is around using the “change champion” model for rolling out larger automations.) 

In change management, we look for the "unintended" outcomes (positive and negative) that emerge once a system is optimized. When you map automation to high-level goals, you start to see shifts that have nothing to do with function. Here are examples of some positive things we noticed:

One of the “downsides” we’ve observed is that you can often get so caught up in the automations themselves, we forget about the end user. It goes back to having a human-first automation strategy. 

Sometimes we prioritize output over end-user experience. If you’re building workflows, particularly if you are not the end user of the workflows, don’t forget to involve your end-users and have them review the output and give you feedback on the experience. By end-users, I mean the different people/roles who may use your automation outputs day-to-da

Ultimately, the goal is not to have more automations, but to have more strategic automations. The next time you build or review a workflow, change your perspective from 'what task is this finishing?' to 'what business goal is this feeding into? This simple shift might be the key to unlocking a potential intelligence engine hidden in the daily grind of your business.