Automation Consumption Theory

Who are the consumers of the automations you build? And how does this affect your decisions?

April 03, 2021
966 words (5 min read)
Development
Process Design

Who consumes an automation?

Whenever you embark on a new project (unless it’s just for fun), presumably you have a target audience in mind. You know, that special someone who’s going to benefit most from what you create.

Arguably, your consumers are one of the most important groups of stakeholders, so you should definitely make sure that you serve them as best you can. But how? If you’ve read this blog for any length of time, say it with me: “it depends!”

Consumers vs Customers

Before we delve in, let me share a useful distinction that I lifted from the book Playing to Win by A.G. Lafley: consumers are the people who use your product; customers are the ones who pay for it. Lafley was the CEO of Procter & Gamble for a long time and for them, consumers are the shoppers, while customers are the retailers who sell their products.

For automation, similar to the situation at P&G, consumers and customers are rarely the same. Customers tend to be the executive sponsors who own the automation, while consumers are either the people running the automation (for attended) or the process owners (for unattended). Our focus here is on consumers.

Consumer archetypes

One helpful way to reason about your consumers is to divide them into subgroups and then choose a representative for these groups. These are sometimes referred to as archetypes, and imagining how archetypes will react to changes you make is a powerful mental model indeed. Don’t take it too far, though: this line of thinking can lead to prejudice very quickly

Some care is required to choose useful archetypes, however. It is very easy to either make your categories too broad (in the extreme, putting everyone into a “users” group), or too narrow (90% of pink/indigo striped unicorns with fluffy tails and grooved hooves approve of this message). Don’t be afraid to reorganize them later if you find that your archetypes aren’t working well.

If you can, create a virtual focus group of real in-the-flesh human representatives for your archetypes, rather than just imagining them. Your colleagues are often quite willing to help you out with testing and feedback, especially if you’re developing the automation for them personally.

Attended vs unattended

Generally speaking, in attended automation, your primary consumer groups will be the people who run the automation. Putting their needs first is paramount. They tend to care most about reliability, ease of use, and speed (in that order). One of the challenges with attended automation is that users don’t care how difficult developing an automation is: if it doesn’t work, or is harder to use than the manual process, they ain’t gonna go for it.

In unattended automation, the situation is more nuanced: In user-triggered automations, such as via a chatbot/e-mail, Apps, or Action Center (Processes), the same principles as for attended apply, and users are largely going to care about the same things.

On the other end of the spectrum we have scheduled back-office processes, which connect systems to each other for a regular data sync. In this case, the situation is usually more relaxed.

Consumers of these automations are typically the line of business managers who own the process KPIs. They tend to care only that the job gets done, but are typically not very sensitive to how quickly or how often the robot fails before finally succeeding.

In this case, the most important problems are logic errors, such as creating bad records or missing a process variant, due to their potential impact on KPIs and the ensuing expensive manual rework.

How you impact consumers

For me, the most important thing to keep in mind is that consumers treat your automation as a black box. This means they only care about the pretty pictures on the box, and any improvements to what’s within — such as code quality — are largely irrelevant to them. Yes, I realize that a black box doesn’t have pictures on it by definition. Work with me here.

This may sound cynical, but to keep them happy during development, it may be a good idea to put some work into fluff that is visible from the outside, even if — strictly speaking — it’s a distraction. But psychologically, it will feel to your consumers like you’re making progress.

You should also be very careful about any changes that may introduce new logic errors or impact reliability in a negative way. Users very quickly feel that an automation “got worse” because you introduced a new bug or two, even if you doubled the amount of power it has. Automated testing is a great tool to avoid breaking existing functionality.

Communication

Another thing to be aware of (and that I personally struggle with) is to keep your consumers informed. This is another solution to the black box problem: make the box a little more transparent by telling people what you’re doing. Even just bringing your consumers into the loop — ideally by asking them to participate in testing, etc. — can make a big difference psychologically.

By the way, even with all the focus on consumers, don’t forget to talk to your customers (i.e. the economic buyers of your automation). They need to know what you’re doing and why, or they will quickly feel you’re wasting their money.

Wrapping up

I’m sure there’s much more to say, but the post is getting long and I don’t want to bore you with my incessant rambling. See you next time and happy Easter if you’re in the Catholic/Protestant Christian part of the world!


© 2021, Stefan Reutter