How to Pick Your First Automation Project (Without Wasting Three Months)

Most teams automate the easiest workflow first, then wonder why revenue didn't move.

I watch this happen on repeat. Someone in ops or marketing gets the green light to automate something, and instead of going after the workflow that's actually bleeding pipeline, they go after the one that's simplest to wire up in HubSpot or n8n. Lead form to Slack notification. Deal stage to email alert. Technically satisfying, operationally invisible six months later.

The problem isn't that these builds are wrong. It's that nobody asked whether they were the highest leverage thing to build first. When the CEO asks what changed in the pipeline, the answer is usually a shrug and a screenshot of a workflow diagram nobody outside the team will ever look at.

Here's how to pick better, using four filters I run every client through before we touch a single build.

Find Where Deals Actually Stall, Not Where People Complain

Complaints and bottlenecks are frequently two different problems wearing the same shirt. Sales complains about lead quality. Marketing complains about sales not following up. Both might be true and neither might be the actual leak.

I had a client, a 40-person industrial services company, where sales swore leads were garbage. Pulled the HubSpot data. Leads weren't garbage, they were fine. The real story: qualified leads sat in a queue for an average of four days before an SDR touched them. By day four, half of them had already talked to a competitor or lost urgency. The complaint was about lead quality. The bottleneck was dwell time.

You find this by pulling deal stage timestamps, not by sitting in a meeting where the loudest voice sets the agenda. Look at time-in-stage for every stage in your pipeline for the last two quarters. The stage with the longest average dwell time relative to deal value is your starting point, almost every time.

Measure Handoff Friction in Hours or Days, Not Vibes

If you can't put a number on the friction, you can't prove you fixed it. This sounds obvious and almost nobody does it before they start building.

Going back to that four-day number: that's not a vibe, that's a metric you can automate against and then re-measure. We built a simple routing and alert workflow that triggered SDR assignment the moment a lead hit marketing qualified status, with an escalation ping if it sat untouched for two hours. Four days dropped to under six hours within three weeks. Close rate on inbound leads went from 11 percent to 17 percent over the following quarter. That's a number you can put in front of a board.

Compare that to the alternative: a team automates a nice-to-have report that saves someone twenty minutes a week of manual export work. Real time saved, sure, but nobody can draw a line from that automation to a dollar of closed revenue. Both are legitimate automations. Only one should be first.

When you're evaluating candidates, ask each one: what's the current number, in hours or days, and what would fixing this move? If you can't answer both halves, it's not ready to be prioritized yet, it's still in the complaint phase.

Rank by Dollar Impact if Fixed, Not by Build Effort

This is where most prioritization exercises get hijacked by whoever's writing the code or building the workflow. Engineering effort is real, but it's the wrong first filter. Easy and impactful are rarely the same workflow, and if you sort by effort first, you'll always land on easy.

I use a simple two-axis exercise with clients: list every candidate workflow, then score dollar impact if fixed on one axis and build effort on the other. Nine times out of ten, the highest impact item is a mid-effort build, not the easiest one on the list. A lead routing fix that touches CRM permissions, notification logic, and a couple of custom properties is more work than a Slack alert, but it's the one moving the close rate.

One SaaS client had six candidate automations on the table. The easiest was a weekly digest email summarizing new trials. The highest dollar impact was fixing a stalled handoff between marketing-qualified and sales-accepted that was losing them an estimated 15 deals a quarter based on historical conversion rates. Same team, same backlog. They almost built the digest first because it was a two-hour job. We built the handoff fix first because the math wasn't close.

Start With One Workflow You Can Actually Isolate

The instinct on a lean team is to batch three or four automations into one project because it feels efficient. It isn't. If you change three things at once, you can't tell your CEO which one moved the needle, and you definitely can't tell if one of them made things worse.

Pick one. Measure the before state cleanly, in hours, dollars, or conversion percentage. Build it. Measure the after state using the same metric, same time window length. If close rate moved from 11 to 17 percent over a quarter, you want to be able to say that with a straight face in a leadership meeting, not hedge it with three other changes that happened in the same window.

This is slower in the short term. It's the only way you build a track record that gets you budget and buy-in for the next project. Nobody funds a second automation initiative off a story that starts with we changed a bunch of stuff and things got better somehow.

The Real Question to Ask Your Team This Week

Most teams build what's fun or fast, then can't explain what changed in the pipeline. If that sounds familiar, the fix isn't more automation tools. It's a different first filter.

Before your next build, pull time-in-stage data for your pipeline, find the stage with the worst ratio of dwell time to deal value, and put a real number on the friction. Rank what's on your list by dollar impact first, build effort second. Ship one thing you can measure cleanly before you touch the next.

If you want a second set of eyes on which workflow actually deserves to be first, that's the kind of thing LangLine Consulting gets called in for. Reach out and we'll look at your pipeline data together before anyone writes a single automation.