The hardest part of business process automation usually isn't the technology, it's deciding where to start. Businesses that stall out often do it at this step: overwhelmed by every possible process worth automating, or picking the flashiest candidate instead of the one that will actually pay back fastest.

This page is a practical starting point: how to pick your first process, what to have ready before you talk to anyone, and the mistakes that derail a lot of first automation projects before they get anywhere.

Start With the Process, Not the Tool

It's tempting to start by researching automation software and working backward to a use case. That order tends to produce automation that fits the tool rather than the actual problem. The better starting point is a specific, painful process — the one everyone complains about, the report that takes six hours to build, the data entry that eats a Friday afternoon — and only then figuring out what kind of automation actually fits it.

How to Pick Your First Automation Candidate

Good first candidates share a few traits:

  • High volume — it happens often enough that fixing it matters
  • Well understood — someone can describe exactly how it works today, step by step, without much disagreement
  • Rule-based, mostly — few genuine judgment calls, even if the input format varies a little
  • A clear, felt cost — hours, errors, or delays that people already complain about

Avoid starting with a process that's still changing, poorly understood, or genuinely judgment-heavy. Those are worth automating eventually, but not as a first project — the ambiguity makes them slow to scope and easy to get wrong.

What to Gather Before You Talk to Anyone

  • A rough description of the process, step by step, as it actually happens, not the official version
  • The systems involved — CRM, ERP, spreadsheets, email, anything the process touches
  • A sense of volume — how often does this happen, and how long does each instance take
  • Examples of what goes wrong — the exceptions, the edge cases, the things that currently need a person to sort out
  • Who does this work today, and who would need to trust the automated version

You don't need this polished. A rough version is enough for a first conversation, and any credible provider will refine it with you during discovery.

Common First-Project Mistakes

  • Starting too big. A first project spanning five departments is much harder to scope, and much slower to show results, than one well-defined process.
  • Skipping discovery. Jumping straight to a tool before mapping how the process actually runs is how automations end up missing the real exceptions.
  • No monitoring plan. Automation that nobody watches after launch tends to fail quietly, eroding trust in the whole effort.
  • Leaving out the people who do the work today. Their knowledge of the real exceptions is the single best source of information you have, and skipping them tends to produce automation nobody trusts.

What Happens Next

Once you've picked a candidate and gathered a rough picture, the next step is usually a discovery conversation — someone maps the process properly, confirms what's worth automating first, and scopes a plan before any building starts. That first project, once it's running and trusted, is usually what makes the second and third automation easier to justify and easier to scope.

What would your team do with the hours they spend on copy-paste?

Show us the process — we'll tell you what's worth automating and what it costs.

Get My Free Consultation →

The business process automation overview covers the categories of work involved, and when you're ready for that first conversation, get in touch and describe the process you picked — that's exactly where a real discovery phase begins.

Frequently asked questions

What's the first step in getting started with business process automation?

Picking one specific, well-understood, high-volume process, not researching software first. The best starting point is the process everyone already complains about, described as it actually happens rather than how it's supposed to work.

How do I choose which process to automate first?

Look for processes that are high-volume, well understood, mostly rule-based, and have a clear, felt cost in hours or errors. Avoid starting with a process that's still changing or genuinely requires judgment calls — those are better candidates once you've had a first success.

What information should I have ready before talking to an automation provider?

A rough step-by-step description of the process, the systems it touches, how often it happens, examples of common exceptions, and who currently does the work. It doesn't need to be polished — a real discovery process will refine it with you.

What's the biggest mistake businesses make when starting an automation project?

Starting too big — trying to automate several processes across multiple departments at once, rather than proving the approach on one well-defined process first. That makes the project slower to scope and slower to show any results.

Do I need a consultant to get started, or can I do the first step myself?

You can absolutely do the first step yourself — picking a candidate process and describing how it works today. Most businesses bring in outside help once they're ready for proper discovery, prioritization, and the actual build.