What to Automate First When You Don't Have an IT Team

A 60-person company doesn't decide to automate. Someone on the finance team finally says out loud that they spend every Friday re-keying the same numbers into three different spreadsheets, and suddenly automation is on the agenda. The problem is what happens next: without anyone whose job is technology strategy, the company either automates the loudest complaint instead of the most expensive one, or buys a tool that promises to fix everything and ends up fixing very little.

The default approach gets the order wrong

Companies with a dedicated IT function or a fractional technology leader usually start automation with an inventory: what takes the most time, what carries the most risk, what's already breaking. Companies without that function tend to start with whichever process just caused the most visible pain. A missed invoice, a botched onboarding, a compliance deadline nearly blown. That's a reasonable trigger for paying attention, but it's a poor way to prioritize, because the process that just embarrassed someone is rarely the one costing the company the most money over a full year.

The stakes of getting this wrong are bigger than they look. Research from Asana's Anatomy of Work Global Index, based on a 2023 survey of more than 9,600 knowledge workers across six countries, found that 58 percent of the average workday goes to "work about work," things like status updates, duplicated data entry, and chasing down information, rather than the skilled work someone was actually hired to do (Asana Anatomy of Work Global Index 2023). At a 60-person company, that's not an abstract statistic. It's more than half of the payroll budget going toward coordination overhead instead of the work that grows the business.

Why "just hire someone" isn't the fast answer it sounds like

The instinct to solve this by hiring a dedicated systems administrator or IT manager runs into a cost problem quickly. The median annual wage for a network and computer systems administrator was $96,800 as of May 2024, and for a computer and information systems manager, the role usually responsible for owning automation and infrastructure decisions, it was $171,200, according to the U.S. Bureau of Labor Statistics (BLS Occupational Outlook Handbook). Add benefits and overhead, and a single full-time hire at the management level can run close to $220,000 a year, for one person, at a company that may only need 10 to 15 hours a week of that expertise once the highest-value automation work is done.

That gap is exactly why most companies in the 25-to-200-employee range end up automating in fits and starts: a manager buys a point tool, a founder signs up for a workflow platform, someone on the team builds a spreadsheet macro. None of it is coordinated, because nobody owns the decision of what to automate first and why.

A framework for choosing the first project

Instead of automating the loudest complaint, score each candidate process against four questions. A process that scores high on all four is where to start.

How often does it happen, and how many people touch it? A monthly task performed by one person is a lower priority than a weekly task touched by five. Frequency times headcount is a rough proxy for total hours at stake.
What does an error actually cost? Not every manual process is equally risky. A typo in an internal spreadsheet is an inconvenience. A typo in a client invoice, a payroll run, or a compliance filing has a real dollar cost and sometimes a legal one.
Is the process stable, or does it change every few months? Automation pays off fastest on processes with clear, repeatable rules. A process that's still evolving, still being figured out by the team doing it, is a poor first candidate. Automate the workflow after it stabilizes, not while it's still being designed.
Can it be automated without custom software? The first project should be achievable with existing platforms and off-the-shelf integration tools, not a development project. If the answer requires custom code, it's not a first project, it's a roadmap item.

The processes that score highest on all four are almost always back-office and repetitive: data transfer between systems that don't talk to each other, approval routing, scheduled reporting, and structured onboarding steps. The processes that score lowest are the ones involving judgment calls, exceptions, or relationships, which is exactly why those are the ones to leave alone for now.

Where the highest-value first projects usually are

Across growth-stage companies without dedicated IT leadership, the same five categories consistently produce the best first automation projects.

Category	Typical example	Why it scores well
Data transfer	Moving new customer records between CRM and billing	High frequency, low judgment, clear rules
Approval routing	Expense reports, PTO requests, purchase orders	Repeatable logic, visible time savings
Scheduled reporting	Weekly sales or pipeline summaries	Stable format, currently manual and recurring
Reconciliation	Matching invoices to payments	High error cost, rules-based, auditable
Structured onboarding	New employee account provisioning, new client setup	Consistent steps, high headcount impact

Data transfer and reconciliation tend to have the highest dollar impact because they touch finance directly and because errors compound. A reconciliation mismatch that goes unnoticed for a quarter is a bigger problem than a late weekly report.

What this actually looks like as a first project

Say a 70-person professional services firm identifies invoice-to-payment reconciliation as its top candidate. It happens weekly, touches two people, an error means either chasing a client for money already paid or double-billing them, the matching rules are stable, and it can run through the integration layer already built into most accounting platforms rather than custom development. That's a strong first project on all four criteria.

Compare that to a request to automate client proposal generation. Proposals vary by client, by deal size, and by what sales negotiated. The rules aren't stable, and forcing automation onto a process that's still fundamentally judgment-driven usually produces a tool nobody trusts and everybody routes around. That's a second-year project, once the underlying process has been standardized, not a first one.

The scale of what's actually automatable

It's worth being precise about how much of this work can realistically be automated, because the honest answer disciplines expectations. Research from the McKinsey Global Institute published in November 2025 estimates that currently available technology could, in theory, automate activities accounting for about 57 percent of U.S. work hours today, with software-based tools accounting for roughly 44 percentage points of that figure and physical automation the remainder. The same research is clear that fewer than 5 percent of jobs could be fully automated with existing technology. Almost every role keeps a meaningful share of work that still requires human judgment (McKinsey Global Institute). The goal of a first automation project isn't eliminating a role. It's removing the repetitive share of a role so the person doing it spends more time on the parts that actually require them.

That distinction matters for adoption, too. A team that believes automation is coming for their jobs will quietly resist it. A team that understands automation is removing the reconciliation grind so they can spend more time on client relationships tends to help make it work.

Signs a company is ready to move past its first project

A single successful automation project usually surfaces the next one. Watch for these signals that it's time to expand rather than stop:

The first automated process runs for at least one full reporting cycle without manual correction.
Someone on the team can explain what the automation does and why, without referring to documentation.
A second team, not just the one that requested the first project, starts asking for something similar.
The company can point to a specific number, hours saved, errors avoided, days shaved off a close, that justifies the next investment.

Companies that skip this checkpoint and move straight to a second, third, and fourth automation project at once tend to end up with the same coordination problem they started with, just now spread across more tools.

Adoption data worth knowing before you start

Growth-stage companies aren't automating in a vacuum. Verizon Business's sixth annual State of Small Business Survey, fielded in April 2025, found that 38 percent of small and midsize businesses were using AI in some capacity, 28 percent specifically for marketing and social media tasks, and 24 percent for written communications, while 47 percent had updated their cybersecurity posture in the prior year (Verizon 2025 State of Small Business Survey). Automation adoption at this scale is now common enough that a company with none of it in place is behind its peers, not ahead of some hype curve.

Where this fits with your existing IT support

None of this replaces the IT support already in place, whether that's an outsourced provider handling help desk tickets and device management or an internal generalist keeping the network running. That operational layer still matters and still needs to exist. What's usually missing at a 25-to-200-employee company is the layer above it: someone who can look across finance, operations, and client-facing workflows, apply a consistent framework to what gets automated first, and make sure the second and third projects build on the first instead of duplicating tools.

Fractional IT leadership fills that specific gap. It provides the prioritization and oversight a full-time technology executive would bring, sized to what a growing company actually needs, without displacing the team or provider already keeping day-to-day operations running.

Frequently Asked Questions

How much does it cost to automate a first process if we don't have an IT team?

Cost depends heavily on the process and the platform, but most first projects use integration or workflow tools already licensed or available as add-ons to existing software, which keeps the direct cost far below a full-time hire. The bigger cost is usually the time spent mapping the process correctly before automating it, not the automation tooling itself.

Will automation replace our IT provider or our internal generalist?

No. Automation and fractional IT leadership both work alongside the team or provider already handling day-to-day IT support, device management, and network maintenance. The goal is to add prioritization and strategic ownership above that operational layer, not to replace the people keeping systems running today.

How do we know if a process is too complex to automate first?

If the rules for how the process should work change frequently, if it depends heavily on individual judgment calls, or if it would require custom software rather than existing integration tools, it's not a good first project. Standardize the process first, then revisit automating it once it's stable.

What's a realistic timeline for seeing results from a first automation project?

Simple, well-scoped projects like approval routing or scheduled reporting typically show measurable time savings within four to eight weeks of going live. Projects involving reconciliation or cross-system data transfer often take a full reporting cycle, usually a month, to confirm the numbers are matching correctly before the time savings can be trusted.

How do we get started without hiring a dedicated automation specialist?

Start with the four-question framework: frequency and headcount touched, cost of an error, process stability, and whether it can run on existing tools without custom development. Score your current candidate processes against those four questions, pick the highest scorer, and treat it as a single, fully finished project before starting a second one.

Is this only relevant to companies with no technology staff at all?

No. It applies just as much to companies with an IT provider or a generalist handling support, since that role is usually focused on keeping systems running rather than deciding what to automate and in what order. The gap this addresses is strategic prioritization, not day-to-day technical support.