I don’t love opening blost posts with buzz words (or even using the phrase “buzz word”. Blegh!)

But today’s topic is one of the buzziest words in tech right now. So *rips bandaid* let’s talk automation.

It’s probably good to know that there are different classes of automations. For my fellow data nerds, I really like this simple list of definitions provided by Salesforce, along with their overarching definition:

Automation is a streamlined process that reduces or eliminates manual steps.

For all the hype we see with automation, there’s less discussion around how tech peeps should be making those calls.  And for data systems (CRMs, fundraising platforms, email marketing platforms, etc…) where there’s often lots of manual steps, the eagerness to automate can be palpable within our teams.

But just cause we can doesn’t mean we should. The key to building useful automations is balancing what it takes to get there with the rewards/consequences.

So before you run off to automate that latest request! Here are some questions I often ask myself, to properly balance that scale.

1. What does it take to set up your automation?

Think about up-front costs. How much time (and/or money) will it take to get your automation built, tested & implemented? What pre-work needs to happen — in your system and with your team — before you even get to the development stage?

p.s Lengthy prep time isn’t a bad thing. For complex automations especially, it’s worthwhile to spend extra time planning, diagramming, & getting those details right

2. What does it take to maintain?

Those furthest removed from the system may see automation as a set-it-and-forget-it deal. But systems peeps don’t have that luxury. 😞

Tech inevitably hiccups. So consider what it will take to maintain this particular automation. How easy will it be to adjust down the road? Is the data that it’s referencing reliable? Is the way you’re reflecting that data consistent, or constantly in flux?

Consider too if other teams should be responsible for revisiting/assessing relevance. Email automations are a good example of this. (In theory, your content person will want to regularly check that any email copy continues to make sense)

3. What does your org stand to gain?

Good automations go beyond sparing individual team members from isolated tasks. Does this automation really bring value? More specifically:

• By automating x, what does that enable us to do that we can’t do now?
• How much time & frustration will be saved?
• How much more reliable will our data/process be as a result?

Remember, an automation doesn’t have to be fancy to make an impact

4. What’s the likelihood of errors?

This one’s important, especially if you’re a lean (or even solo) data team. What are the chances that automating actually creates more of a headache?

We like to think of automation as the solution to an efficiency problem. But for automations highly reliant on data, they only work when you can trust those data points. So if the accuracy is lacking, or your team’s data entry isn’t quite up to snuff, then think twice. Automation is likely to exacerbate those issues & give you more work/things to fix.

p.s. Bad data isn’t the only reason for errors. Things like resource limits, shoddy integrations, and conflicting processes can also cause issues. It all depends on your use case, and how well your systems can support that need.

5. What are the consequences of a worst-case scenario?

This question is probably easier to answer once your automation is in development. But if you’re fairly expert at your system’s features (& understand your use case), then you may be able to reflect on this sooner.

Some errors are bigger than others. What’s the worst, technically feasible error that can happen with this automation? What does that error mean: for your stakeholders, data quality, privacy, equity, etc…? 

There isn’t really a formula for this. But you ultimately want to weigh the severity of those potential consequences with the likelihood of them happening, and with the benefits of the automation overall. 

Let’s not lose sleep over a worst-case scenario. For risky automations, we (systems peeps) can help our teams dissect whether the need really outweighs the risk. And if it does, we can work with teams to put safeguards in place that mitigate those consequences

6. Is there another option that works just as well?

To answer this question, zoom waayyy out.

Put your use case and automation knowledge to the side. Is there a practical intervention you can think of, that would invalidate the need for this thing to be automated at all?

I’ve found that the answer to this question is often yes! But it isn’t always obvious at the start, especially when we’re in the weeds with data & decision logic.

Think of interventions that are feasible, reasonable and pre-emptive. Some ideas to get your gears turning

• Your automation needs to correct data once it’s manually entered into your system. Instead of fixing it after-the-fact, is there something you could provide to your staff (training, written guidance, a prompt) to help them enter data correctly the first time?
• Your automation needs to flag duplicate records and act on them. Instead of jumping to automation, does it make sense to start with a report and have someone monitor weekly? (Even better, can you figure out a way to prevent duplicates in the first place?)
• You need to build a data entry process that will allow volunteers to save records to your database, but prefer not to give them access. Does it make sense to build a system that feeds into a spreadsheet instead (like Google Forms), and then have a staff member bulk import records?

To wrap up…

Automation is great, but not all automation opportunities are made equal. And when you’re a lean data systems operation, a good chunk may not even be worth the effort.

Not to mention, automation isn’t limited to software! Sometimes, how we organize manual processes can lend to automation better than any tech can. (I’ll spare you that schpiel though, because that could be a whole other blog post.)

Ultimately, part of automating smartly is recognizing when the benefits outweigh the costs. The more we can all consciously take on the exercise, the better off our orgs will be in the long-run.