Most Companies Are Automating the Wrong Things
Teams automate what's easy and visible, not what's valuable. The result is a lot of impressive demos and very little impact on the numbers that matter.

We get a front-row seat to what companies choose to automate, and a pattern repeats almost everywhere: they automate the wrong things. Not because the tech fails, but because they pick targets by what's easy and demo-able, not by what actually moves the business. The result is a portfolio of slick automations that look great in a slide and barely register on the P&L.
The instinct is understandable. Easy, visible tasks produce fast wins you can show off. But fast and visible is not the same as valuable, and chasing the former is how companies end up busy automating and still wondering where the return went.
Why the conventional wisdom is wrong
The conventional approach is to find the most obviously repetitive task and automate it first. That optimizes for ease of implementation, not for impact. The highest-value opportunities are often messier, less glamorous, and buried in operations nobody wants to demo, which is exactly why they're still done by hand.
Easy-to-automate tasks are often low-value precisely because they were easy.
The biggest costs usually hide in complex, judgment-heavy workflows that don't demo well.
Teams optimize for a quick win to justify the budget, not for the largest return.
What is actually true
The right things to automate are the ones with the highest combination of cost, volume, and pain, regardless of how hard they are to build. That means starting from the business, not the technology: where is the money actually going, where are the bottlenecks, what breaks at scale? Then aim AI at those, even when they're unglamorous.
A boring automation that saves a fortune beats an impressive one that saves nothing. Every time. The most valuable opportunities are usually hidden precisely because they're unglamorous: the reconciliation that eats three days a month, the handoff that quietly fails at volume, the manual step everyone resents but nobody owns. Those don't make good demos, which is exactly why they're still being done by hand and exactly why they're worth so much.
The right starting question is not technical, it's financial. Where does your time, money, and frustration actually go? Map that honestly and the priorities reorder themselves. The flashy use case that impressed everyone in the meeting often drops to the bottom of the list, and a dull, expensive workflow nobody wanted to talk about rises to the top.
What we learned at TTGC
In our own transition, our first automations were the flashy ones, the things that were fun to build and easy to show. They helped a little. The automations that actually changed our economics were unglamorous back-office workflows we'd been ignoring because they weren't exciting. That lesson reshaped how we advise clients: we start with a cost-and-pain map of the business, not a list of cool AI use cases. We point AI at the expensive, painful, invisible work, because that's where the return lives, not in the demo-friendly tasks.
Now our engagements open with discovery, not deployment. Before we build anything, we trace where the real cost and friction sit, and we rank opportunities by impact rather than by how good they'd look in a launch announcement. It's less exciting than leading with a shiny prototype, and it's the single biggest reason our clients see returns instead of a portfolio of clever automations that changed nothing.
The honest take
Stop asking "what can we automate?" and start asking "what is costing us the most, and could AI help?" The easy, visible tasks are tempting and mostly a trap. The valuable targets are usually messy and boring. Follow the money and the pain, not the demo. Automating the wrong things keeps you busy. Automating the right things changes the numbers.
Sources
McKinsey & Company, The State of AI (2024) — on where AI value is actually captured versus where it is attempted. mckinsey.com
TTGC — lessons from our own AI transition and client implementation work.


