What Tasks Should I Automate First?

The first question is rarely "which tool should we use." It is "which process should we fix first." Get the second question wrong and the first one does not matter, because the project will produce a partial result, the team will lose confidence, and the next attempt will be harder to fund.

The right starting process is almost never the most painful one. It is almost never the one the founder is most frustrated about. It is the one that meets a specific combination of conditions: high frequency, structured data, clear rules, and is visible in the business's day-to-day operations. The filter is simple. Applying it well is not.

This article walks through the framework we use with new clients to identify the first automation project, the three signals that confirm a process is the right starting point, and the most common mistake that causes first projects to underperform.

Start with what your team does every day that a system could do instead

The first filter is observation, not opinion. Walk through a normal Tuesday with each member of the team whose work involves moving information between tools. Note the points in the day where the work stops being judgment and becomes data movement. Those are the candidates.

A few patterns show up consistently across the businesses we work with. A sales rep finishes a call, opens the CRM, copies the call notes from the calendar invite, pastes them into the contact record, updates the deal stage, sends a follow-up email from a template, and notifies the account manager in Slack. None of that is judgment. It is data movement, and a workflow can do the whole sequence in about 20 seconds, end to end. An ops person reconciles transactions between the e-commerce platform and the accounting system by exporting a CSV from one, importing it into the other, and resolving the mismatches line by line. A workflow can pull from the source systems, normalize the data, and produce a reconciliation report that flags only the items that need a human eye.

The first filter is the easiest one in the framework and the one most often skipped. Most teams pick the first project based on what the founder complains about, not based on what the operations team actually does every day. Those two lists overlap, but they are not the same. The founder is usually frustrated by a high-visibility problem. The operations team is usually losing the most time to a low-visibility one.

The first project should come from the operations team's list, not the founder's. This is the single most reliable predictor of whether the project lands well.

The second filter: does it have an API or webhook?

Once you have a short list of candidates from the first filter, apply the second. For each process, ask whether the systems involved expose an API or a webhook. If yes, the process is automatable at the system level. If no, it can only be automated at the interface level, which is more fragile, more expensive, and usually not the right starting point.

The distinction matters because it determines the kind of automation that fits the problem. API-level automation connects the systems directly. It runs against documented contracts, it does not break when an interface changes, and it can be built and maintained by a competent automation engineer in a few days for most SMB processes. Interface-level automation clicks buttons and reads screens. It is the kind of automation that RPA platforms do, and it is the kind most teams should avoid unless the underlying systems genuinely have no other option.

For a small or mid-sized business running mostly modern SaaS tools, almost every process on the operations team's list will pass the API test. That is a good sign. It means the first project can be built as a durable system-level automation rather than a fragile screen-scraping workaround.

For a business running older on-premise software, some processes will not pass. Those processes belong later in the roadmap, not in the first project. The first project should be the one that lets the team build confidence, prove value, and learn the workflow of designing and shipping an automation. The harder projects come after, when the team has the experience to take them on.

The three signals that confirm something should move up the list

Beyond the first two filters, three signals reliably separate a good first project from a bad one. The signals are not guarantees. They are the indicators that the project is more likely to land well, recover time quickly, and produce a result the team can point to when the next project is being scoped.

The first signal is volume. The process happens many times per day or per week, and the time spent on each occurrence is small. This is the inverse of the usual way teams pick projects. The instinct is to chase the slow, painful process that happens rarely. The math usually favors the fast, frequent one. A 10-minute task that happens 30 times a week consumes 5 hours of team time. A 4-hour task that happens twice a month consumes 8 hours. The fast, frequent process is often the bigger drain, and it is almost always easier to automate.

The second signal is data structure. The inputs and outputs are clean fields, not unstructured documents. A process that reads from a CRM, transforms a few values, and writes to another system is an ideal first project. A process that reads a 12-page PDF, interprets a contract clause, and decides what to do is a project for later, after the team has built and shipped a few of the easier ones.

The third signal is visibility. The recovered time shows up in a place the team and the leadership can see. A workflow that eliminates 8 hours of weekly reporting work is a more visible win than one that eliminates 3 hours of a back-office task that nobody was looking at. Visibility is not a quality of the process. It is a quality of the choice. Picking the visible project as the first one builds the internal momentum that the next few projects will need.

The mountain road rule: prerequisites before peak automation

One more idea is worth introducing because it explains a pattern we see in nearly every engagement. Call it the mountain road rule.

On a mountain road, the switchbacks at the bottom of the hill are not optional. You cannot get to the summit by going straight up. The first switchback enables the second. The second enables the third. Each one is a step on the way to the top.

Automation projects work the same way. The most valuable end-state automation in a business is usually a multi-process build that connects a full operational function from end to end. That build is the summit. It is rarely the right place to start. The starting point is the switchback at the bottom of the hill: a single, contained, well-understood process whose build produces the data structure, the integrations, and the team capability that the next project needs.

Pick the first project as if you are picking the first switchback, not the summit. The summit comes later. Trying to start at the summit is the most common reason first automation projects fail to deliver the value the business was sold on.

The most common mistake we see

The most common mistake in first automation projects is also the simplest to avoid. Teams pick the process that is most visible to leadership, scope the project around the visible parts of the process, and discover halfway through the build that the visible parts depend on invisible parts that were never documented and never scoped.

The fix is to map the process in full before scoping the project. The map should include the happy path, the exception paths, the approval steps, the people involved, the systems touched, and the data fields that change at each step. This is not a fun activity. It is not the part anyone is excited about. It is the single most important activity in the project, and skipping it is the most reliable way to turn a six-week build into a twelve-week build with a partial result.

The businesses that get the most out of their first automation project are the ones that invest two to three weeks in process mapping before they invest a dollar in building. The businesses that get the least are the ones that skip the mapping, trust the verbal description, and discover the gap during testing.

The short version

Pick the first automation project as the one that combines high frequency, structured data, API access, and visibility in the business. Map the process in full before scoping the build. Sequence the projects so each one produces the foundation for the next. The first project should produce visible recovered time within 30 days, not a 12-month transformation that nobody can point to until it is done.

The businesses that follow this sequence end up with a portfolio of automations that grow in scope and value over time. The ones that try to skip the sequencing end up with a single ambitious project that consumes a year of internal attention and produces half of what was promised. The first filter is the one that determines which side of that line you end up on.