A small company should automate work that is high-volume, rule-based and low-risk first, where one person clearly owns the process and you can measure how long it takes today. Good first candidates are usually data handoffs between systems, intake and routing, and recurring reports. Save judgment-heavy or customer-facing decisions for later.

The point of a first automation is not the biggest possible payoff. It is a reliable win that teaches your team how automation works in your systems, so the second and third projects go faster.

What makes a process a good first automation?

A good first automation scores well on five criteria: it happens often, follows clear rules, has low consequences if something goes wrong, has a single owner, and has a baseline you can measure. If a process fails two or more of these, move it down the list, however annoying it is.

  • Volume: it happens daily or weekly, not quarterly.
  • Rules: a new hire could follow a written checklist to do it.
  • Risk: an error is easy to catch and cheap to fix.
  • Owner: one person is responsible and will tell you when it breaks.
  • Baseline: you know, or can easily measure, the time and error rate today.

Score each candidate from one to three on each criterion and rank them. The exercise also forces useful conversations about who owns what.

Which processes usually qualify?

In most small companies the strongest early candidates are the handoffs people do by copying and pasting between systems. These include lead intake and routing, new client or employee onboarding steps, invoice and receipt capture, recurring report assembly, and moving meeting notes into a CRM or project tool.

  • Lead intake: a web form creates a CRM record, assigns an owner and sends an acknowledgment.
  • Onboarding checklists: a signed contract or new hire triggers accounts, folders and task lists.
  • Document intake: invoices or receipts arriving by email get extracted and queued for approval.
  • Recurring reports: weekly numbers pulled from several systems into one summary.
  • Meeting follow-up: call notes summarized and logged against the right client record.

Each of these is repetitive, has a clear trigger, and produces an output someone can check.

What should you avoid automating first?

Avoid processes that are rare, undocumented, disputed between teams, or where an error would reach a customer, a regulator or a bank account without a person seeing it first. These may be worth automating eventually, but they make poor first projects because failures are expensive and hard to diagnose.

  • Payments and refunds without an approval step.
  • Customer-facing replies sent without review.
  • Processes that work differently depending on who does them.
  • Anything where the team cannot agree on what "done" looks like.

If a risky process is also your most painful one, automate the preparation and leave the final action to a person.

Which tools should a small company use?

Pick the tool to fit the process, not the other way around. Simple handoffs between popular SaaS apps fit Zapier or Make. Flows with more logic, or where you want to self-host, often fit n8n. Steps that require reading unstructured text or making judgment calls can use Claude with connectors.

  • Zapier and Make: fast to set up, large app libraries, good for straightforward triggers and actions.
  • n8n: more control, self-hosting option, suited to branching logic and custom code.
  • Claude with MCP: the Model Context Protocol is an open standard for connecting AI models to tools and data, and Claude supports custom connectors built on it. Use it where a step needs reading, summarizing or classifying.

Many good automations combine these. A workflow tool handles triggers and data movement, and Claude handles the step that needs language understanding.

How do you run a first automation project?

Run it as a short, scoped project with a clear before-and-after. Pick one process, document it, measure it, build the smallest version that works, run it alongside the manual process briefly, then switch over and measure again. Expect to find exceptions you did not know about.

  1. Document the current process. Write the steps, inputs, outputs and exceptions with the process owner.
  2. Measure the baseline. Record time per run, volume per week and error rate.
  3. Build the minimum version. Handle the common case and route exceptions to a person.
  4. Run in parallel. Compare automated and manual results for a week or two.
  5. Cut over and monitor. Set up alerts for failures and name who responds.
  6. Re-measure. Compare against the baseline and decide what to automate next.

How do you keep automations from breaking?

Automations break when connected systems change, credentials expire, or data arrives in an unexpected format. Plan for maintenance from the start: give every automation an owner, log every run, alert on failures, and keep a short written description of what it does and why.

  • Store credentials in the platform's secure credential store, not in shared documents.
  • Send failure alerts to a person or channel someone actually watches.
  • Review each automation quarterly to retire ones nobody uses.

How Dorje Group can help

Our one-week Automation Opportunity Sprint identifies three ranked workflows with an ROI estimate and scope for each, so you start with the right one. We can then build a single workflow or run a longer automation sprint, and offer managed automations for ongoing upkeep. We work on-site in Denver, Boulder and the DTC, or remotely.