Somewhere between your fourth copy-pasted email of the day and yet another spreadsheet update, you wonder: should I just automate this? It’s a fair question; and honestly, a tempting one. But context is everything. Before diving in, it’s worth pausing and asking yourself a few grounded questions. Think of this as a guided conversation with your future self (and hopefully someone from governance).

1. Who’s affected, and how badly?

Start with the scope. If this automation is just for your own inbox triage or filing PDFs you get daily, go ahead: low risk, low impact. The worst-case scenario is you create a Frankenstein flow, spend an afternoon debugging it, and walk away with a valuable lesson. But as soon as your automation starts to touch more than just your own workflow, it enters a different league. Automating a small handover between two people might seem harmless, but even simple automations can introduce fragility. What happens if your colleague is on leave? If they change the file name? If your flow breaks, will it quietly fail or silently drop the ball on a customer order? Let’s take it further. Automating a process that supports onboarding, procurement, or customer communication? Now you’re interfering with how others work, and you’re also reshaping accountability. You’re influencing SLAs, timelines, and expectations. If you’re working on payroll, compliance reports, or IT provisioning, the potential for damage gets even more real. These aren’t just workflows; they’re risk surfaces. That’s where architecture, stakeholder alignment, and robust testing come in. It’s not about being slow or bureaucratic but about building solutions that can withstand change, edge cases, and shared responsibility. You wouldn’t rewire the office network just because you read a blog post about routers. Don’t do it with processes either.

In short:

Personal automations are great playgrounds.

But the moment others rely on your output, it’s no longer just about your efficiency but about shared trust. And shared trust deserves structure.

2. Process quality: clarity or chaos?

Let’s assume the intent is noble. Automating repetitive work sounds good in theory, but is the process itself stable and well-understood enough to be automated? A well-documented, consistent, mostly manual process is a strong candidate. Think of steps like check incoming support tickets, assign them based on category, or send a weekly summary to stakeholders.These are clear, repeatable, and generally predictable.

Now compare that to a process that involves chasing people down via chat, digging up templates from someone’s personal OneDrive, or interpreting vague instructions like do what we did last time. That’s not a process, it’s folklore. If your workflow includes steps like just ping Sandra, she knows, or send a friendly reminder, automation won’t solve the real issue. You’ll just bury a flawed process under layers of technology. And that’s not just opinion. According to a McKinsey study, around 70% of large transformation efforts fail, often due to unclear or shifting processes. Automating something that’s ambiguous doesn’t reduce the problem, it reinforces it. It gives people a false sense of reliability while quietly perpetuating all the same inefficiencies.

Let me repeat this:

Automating junk processes is how you turn temporary inefficiencies into permanent confusion.

Before automating, consider mapping the process end-to-end. Identify who does what, when, with what inputs and expected outcomes. If you can’t write that down in a way others understand, automation isn’t the next step, clarity is. (if you need help with this step, hit me up)

3. Data quality: dream or disaster?

You can’t automate what you can’t trust. High-quality data (clean, structured, accessible via APIs or databases) is the fuel automation runs on. If your information lives in a reliable system of record, is updated consistently, and communicates in formats that other systems understand, you’re in a strong position. Automating with this kind of data feels like adding a turbocharger to a well-built engine.

But let’s be honest: many of us aren’t dealing with ideal conditions. If you’re scraping Excel files from email attachments or copy-pasting values from PDFs, you’re already on thin ice. These data sources often come with missing fields, inconsistent naming, and formatting quirks that break flows without warning.

A simple rule of thumb: if it takes a human 15 minutes to clean the data every time, automating that cleanup will likely take 15 hours, and it will still break the moment someone renames a column or inserts a rogue emoji into a free-text field. And when things break, they often do so silently, leading to incorrect outputs, corrupted records, or decisions made on flawed inputs. This isn’t just inefficient or expensive, but also dangerous. Bad data at scale is worse than no data at all. You’re not improving a process; you’re just accelerating your mistakes.

If you want a horror story, look no further than organizations still using spreadsheets as the backbone of operations, something we explored in this blog post. These legacy systems often masquerade as structured data sources but behave like digital sandcastles. So before you start automating, ask: is the data fit for purpose? If not, clean the foundation first. Otherwise, you’re building a robot that trips over the same mess every day.

4. Time saved vs. time spent

This is where that brilliant XKCD chart comes in handy. The premise is simple but powerful: how often do you do the task, how much time does it take, and how long will it take to automate it? This is the math behind whether your automation effort is worth it.

Say you spend five minutes per day manually doing a task. Over five years, that adds up to just over 21 hours. If your automation takes more than two to three full days to build, test, deploy, and occasionally fix, you may never see a return on that investment. Especially if the task is tolerable and unlikely to change. Now, this doesn’t mean all small automations are a waste. If the process is prone to human error, causes frequent context switching, or is a bottleneck for others, the value may go far beyond the raw time saved. Speed is only one axis of improvement, quality, accuracy, and scalability matter too.

Still, it’s important to be honest about the cost-benefit tradeoff. Many developers (I might be guilty of that as well) enjoy automating things for the intellectual challenge or the elegance of the solution. But sometimes, the smartest move is to keep doing that task manually, especially if you’ll spend more time maintaining the automation than you ever did on the task itself.

In short: let data and context, not just curiosity, guide the decision.

5. Cost: Labor and lost weekends

Automation is often sold as a quick win, an easy way to improve productivity without adding headcount. But the true cost of automation isn’t just the time it takes to build a flow. It’s also the maintenance, the troubleshooting, and the late-night Teams messages when it fails. Now add labor: time spent planning, building, testing, fixing edge cases, explaining it to stakeholders, and documenting the flow. Then sprinkle in the debugging hours (because we all know a 42-step flow with nested conditions never works perfectly on the first try). And then there’s the human bottleneck factor. If you’re the only one who understands how the automation works and you’re out of office, congratulations, you’ve just made yourself a critical point of failure. There’s a difference between being helpful and being irreplaceable in a way that stresses out your team.

Before jumping in, ask yourself: do we have the right tooling in place? Is this within our supported platform stack? Who else knows how this works, and are they empowered to help if something breaks? If you can’t answer those clearly, what you’re building isn’t just automation, it’s a support ticket waiting to happen.

6. Are you automating a moving target?

Some processes are beautifully stable: They’ve run the same way for years and aren’t likely to change next week. Others are in constant flux: driven by shifting regulations, changing business models, or the latest reorg. If you’re working with a process that evolves every quarter, take a step back. Automation only pays off when what you’re automating stays more or less the same. Otherwise, you’ll spend more time updating the automation than the task ever cost in the first place. This is especially common in fast-growing companies or departments undergoing digital transformation.

Think of it this way: Would you write a user manual for something that changes every few weeks? Probably not. So why commit it to code? That said, if you absolutely need to automate, consider designing for flexibility. Build modular flows with clear entry and exit points. Document them. Include versioning. And make peace with the fact that you might need to revisit and revise regularly, because the process isn’t done evolving just because your flow is live.

7. Ownership: Who owns this thing?

Ownership might sound like a formality, but it’s the backbone of every sustainable automation. When your flow fails at 3:27 am on the last day of the quarter, someone will be asked: Who owns this?. If the answer is I think I built it during a hackathon, that’s not just risky, it’s irresponsible. Every business process, no matter how small, should have a named owner. Someone who knows what the flow is supposed to do, who approves changes, and who can say yes or no when someone asks to tweak it. Ownership isn’t about bureaucracy, but only about clarity. It’s the difference between having a fire drill and a coordinated fire response.

Without clear ownership, automations slowly decay. A once-useful flow becomes a mystery nobody wants to touch, living somewhere in a forgotten environment, still trying to send weekly reports to a mailbox that no longer exists. And when it fails, the silence lasts until someone’s task goes missing, and fingers start pointing. So before you build, ask: who will own this a month from now? Six months? Will they know it exists? And if they leave, is anyone else ready to take over?

If the answer is me, I guess, and you’re not the person accountable for the business process, you might be building more technical debt than value. And no, dear IT-departments: It is not sufficient to just co-own every Power Automate flow owned by a user - you need to make sure that you know what it is doing.

8. Compliance, risk, and audits

Even if your automation runs beautifully and always triggers on time, processes the right data, and emails the right people, that doesn’t mean it’s safe. In fact, the more reliable it seems, the more dangerous it can be if it’s quietly doing the wrong thing with the wrong data. If your flow handles personal data, financial transactions, or anything that might touch compliance or regulatory frameworks, you’re no longer in casual territory. You’re in the land of data protection, security policies, and audit readiness. That means your automation must include:

• Proper access control
• Audit trails
• Robust error handling
• Clear fallback paths

These aren’t just nice to haves, they’re non-negotiables. One missed field, one hardcoded email address, or one forgotten permission level can turn a minor issue into a full-blown incident. A small bug becomes a data breach in the time it takes to hit Send.

And yes, automation absolutely counts as data processing under regulations like GDPR and its international cousins. If you wouldn’t be allowed to do something manually without compliance approval, you definitely shouldn’t automate it without the same scrutiny. Before deploying, ask: Would this pass an audit? Would I be comfortable explaining it to a privacy officer, or a journalist? If the answer is no, pause. It’s easier to build compliance in from the start than to retroactively secure a system that’s already caused harm.

9. Human touch vs. human error

Not all manual work is a waste of time. Some tasks genuinely benefit from human involvement, especially those that require context, empathy, or nuanced judgment. Think of reviewing a customer escalation, handling a sensitive HR case, or making an exception in a policy-driven workflow, humans still outperform even the best logic trees. Automating these interactions can unintentionally strip away the very qualities that build trust and engagement. A rejection email sent by a bot, no matter how well phrased, rarely lands the same way as one written by a person who understands the situation. Also AI won’t fix that. #justsayin

That said, automation shines in areas where the rules are clear and the data is structured. Examples are routine approvals with fixed thresholds, data validation between systems, or moving files and values between platforms. These tasks are low-value for humans but high-frequency and error-prone, making them ideal for automation. And sometimes the best path isn’t full automation but augmentation. Let the system do the prep work: gather data, check conditions, suggest actions. Then let a person decide. That hybrid model keeps humans in the loop without overwhelming them with routine work. It’s efficient and thoughtful. So when you evaluate a process, ask not just can I automate this? but also what part of this benefits from a human touch—and which parts don’t need one at all? And I know, the lines are blurring with LLMs and we see lots of agents who will handle interaction in our fast paced digital world 🤡 - but trust me… some things should just not be executed by AI.

10. Tool chaos and platform fit

Technology should make your life easier, but too often, automation becomes another layer on top of a confusing stack. If your organization already uses ten different tools for task tracking, approvals, and reporting, and everyone is using their own combination of them, your automation might not solve the problem. It might just add one more patch to a system that’s already showing stress fractures. Inconsistent tooling isn’t just an IT headache; it creates user confusion, duplicate work, and brittle processes. An automation that integrates two tools nobody else uses isn’t strategic, it’s just more siloed glue. Instead, look for opportunities to consolidate. Build on platforms your organization already supports and standardizes. If your IT team has blessed a core toolset, use it. Not because it’s perfect, but because it’s supported. That means security patches, maintenance windows, backup plans, and someone to call when things break.

When you align with platform strategy, your automation has a chance to scale. When you don’t, even a brilliant flow might die in obscurity the moment you change teams or someone sunsets one of the systems involved. So ask yourself is this the right place to automate it? Because sometimes, what looks like a workflow issue is really a tooling problem in disguise.

11. Transparency and traceability

People like to know what’s going on, especially when their work depends on it. Manual processes, for all their flaws, often have one major advantage: they’re visible. You see the handoff, you know who’s working on what, and there’s usually a paper trail, however informal. Automation can quietly remove all of that. A task that used to involve an email or a verbal confirmation now disappears into a black box. If it succeeds, great. But if something goes wrong and no one knows why or where it stopped, frustration builds fast. To avoid that, your automation should include visibility by design. Build in notifications that let people know when something’s been submitted or completed. Provide logs or dashboards that track status. Even a simple confirmation email or SharePoint update log can make the difference between trust and suspicion. The first time someone asks what happened to my task? and nobody knows, you’ll wish you had built in just a few more breadcrumbs.

Remember, automation should reduce uncertainty, not introduce it.

12. Just because you can doesn’t mean you should

This is the line that often gets skipped in enthusiastic automation conversations. Tools like Power Automate make it incredibly easy to stitch together workflows, call APIs, and spin up integrations in a matter of minutes. It feels powerful, and it is. But just because you can automate something doesn’t mean it’s wise to do it alone. As soon as your automation affects more than your own work, especially if it reaches into cross-functional workflows, customer-facing systems, or business-critical operations, it stops being a personal time-saver and starts becoming part of your organization’s digital infrastructure.

That comes with responsibility. You need testing. Documentation. Version control. Monitoring. You need to think like an engineer, even if you’re not one. And if you’re operating in a professional environment, you also need to engage with governance and architecture. Not to slow you down, but to protect the people who depend on the outcome. Rogue automation can create fragile systems, introduce silent errors, or violate compliance without anyone noticing, until it’s too late. Involving a subject matter expert doesn’t just make your flow better; it ensures it’s built for scale, clarity, and supportability.

The best automation is collaborative. It lives on a supported platform, it follows design principles, and it doesn’t break when you go on vacation. You might still enjoy building it, but you’ll also sleep better knowing you’re not the only one holding it together.

Conclusion: should you automate it?

The honest answer? Please don’t kill me:

It depends.

But it genuinely does. If the process you’re looking at is stable, well-understood, and worth the investment, if the data is clean, the impact is clear, and the scope is manageable, then yes, you should probably automate it. You’ll free up time, reduce errors, and maybe even improve morale. But automation isn’t always the answer. If you’re dealing with an unstable process, murky ownership, questionable data, or unclear value, then automating might just amplify existing issues. And once an automation is live, people assume it’s reliable, even when it’s quietly making the same mistake 1,000 times a day. Done well, automation scales good decisions. Done poorly, it scales dysfunction. That’s why every quick win deserves at least a few deeper questions before you dive in.

So take your time. Involve the right people. Document what matters. Build with care and intention. Because the goal isn’t just to automate, it’s to make work better, safer, more transparent, and yes, sometimes faster too.