From zero to your first working automation in 90 days, without an IT team

Most small businesses don't fail at automation because the technology is hard. They fail because they start from the wrong end: they buy a tool, look for something to do with it, and three months later they're paying for a subscription nobody touches.

This article is the right order. Not theory about why you should automate, but the concrete path from day one to having a real flow running in production, without an IT team and without the project dying in a "someday" folder.

Why 90 days and not two weeks

Two weeks are enough to build a test flow. They're not enough to know if the flow survives real use. Ninety days give you time to choose well, build carefully, launch, see what breaks, and fix it before anyone depends on it to do their job.

The goal at day 90 is not to have ten automations. It's to have one that runs by itself, that someone on your team understands, and that has saved measurable time for a real person.

Weeks 1 and 2: pick the process most likely to win

Don't automate what sounds most impressive. Automate what has all of these characteristics at the same time:

Repetitive and predictable. If the process has different exceptions every time, it's not ready to automate. Standardize first, then automate.

Manual and with clear steps. It has to be something a person does today by following steps you could write on paper.

With visible impact. If nobody notices when the process fails for a week, it's not the right process.

No subjective decisions in the middle. If someone has to "evaluate" or "decide" at any step, the automation gets complicated. For your first one, look for processes where the logic is: if X happens, do Y.

Typical candidates in small businesses: sending proposals after a sales call, registering web form leads into a CRM, internal notifications when a payment comes in, weekly reports that someone assembles by hand every Monday morning.

Pick one. Just one.

Weeks 3 and 4: map the process before touching any tool

Here is the most common mistake: opening Make or Zapier before understanding the process on paper. The result is a flow that automates the chaos instead of eliminating it.

Sit down with the person who does this process today. Ask them this, step by step:

1. What triggers this process? What has to happen for you to start?
2. What do you do first? What information do you need for that first step?
3. What happens if that information doesn't arrive or arrives incomplete?
4. What do you do next? And after that?
5. How do you know the process finished correctly?

Write the answers in a simple document. No diagramming software, no Miro, no flowcharts yet. Just text with numbered steps and exceptions noted in the margin.

At the end of this exercise you should be able to answer: what is the trigger, what data comes in, what are the actions in order, and what is the expected result. If you can't answer that, the process isn't ready.

Weeks 5 to 8: build the first flow without code

With the map in hand, now you open the tool. The most commonly used options in small businesses are Make (formerly Integromat), Zapier, and n8n. All three let you connect applications and create flows without writing code.

Zapier is the easiest to start with but the most limited for complex logic. Make has more flexibility and a pricing model that scales better as volume grows. n8n can be self-hosted (there's also a cloud version), which matters if you have data privacy restrictions. For a first automation without a technical team, any of the three works.

The basic flow in these tools always has the same structure: a trigger that detects something happened, actions that run in order, and optionally conditions that change the path based on data.

A concrete example: a contact form on your website fills a row in Google Sheets. That triggers the flow. The flow reads that row, creates a contact in your CRM, sends a welcome email from your account, and notifies the salesperson on Slack or WhatsApp. All without anyone touching anything.

During these four weeks, don't try to make the perfect flow. Make the flow that handles the most common case. Handle exceptions in the next stage.

What you must do before launching:

• Test the flow with real data, not invented test data.
• Verify that the fields you're connecting exist in all the apps, not just one.
• Define what happens if the flow fails: does someone get an alert? Does the process fall back to manual?

Weeks 9 and 10: connect the tools you're already paying for

Before adding a new app, check whether the ones you already have can connect directly. Most small businesses already pay for a CRM, an email tool, a form builder, and some kind of internal communication app. Connecting them to each other is almost always faster than learning something new.

HubSpot, Notion, Google Workspace, Typeform, Slack, WhatsApp Business API, Stripe, WooCommerce: all of them have native integrations with Make and Zapier. Check the connector list of whichever tool you choose before assuming you need something different.

If a step requires an app without a native connector, check whether that app has a documented API. Make and n8n allow direct HTTP calls, which opens up almost everything. But that's a more advanced level; for your first automation, stay within native connectors.

Week 11: launch in production with someone watching

Don't launch on a Friday at 6pm. Launch on a Tuesday or Wednesday morning, when you have time to watch the logs and react if something fails.

During the first days in production, manually verify that the results are what you expected. Compare the flow's output with what the person used to do manually. If there are differences, understand why before assuming the flow is wrong.

Document the flow somewhere the team can find it: what it does, who's responsible if it breaks, and how to pause it if there's an urgent problem. That sounds bureaucratic but it saves the project when the person who built it goes on vacation.

Weeks 12 onward: what to do when it breaks (and it will break)

Every automation in production eventually fails. A field changes its name in the CRM, an app updates its API, an email format changes and the parser doesn't recognize it. That's not failure, it's the normal cycle.

What separates a team that keeps their automations alive from one that abandons them is a simple monitoring system:

• Error alerts turned on. Make, Zapier, and n8n can send you an email or a message when a flow fails. Enable that from day one.
• A 15-minute weekly review. Look at the week's logs, find failed executions, understand why they failed.
• One named person responsible. Not "the team." One person who knows this is their responsibility.

When something breaks: first pause the flow so it stops generating errors, then understand the root cause, then fix it, then test with real data before reactivating.

When this approach doesn't fit

If the process has complex logic with many exceptions, if it involves sensitive data that can't pass through third-party services, or if it requires integrating proprietary systems without an API, 90 days with no-code tools won't be enough. In those cases the right path starts with a technical assessment, not a flow in Zapier.

It also doesn't fit if the process itself is broken. Automating a bad process just breaks it faster.

The result that actually matters

At the end of 90 days, the question isn't "how many automations do we have?" The question is: is there one person on your team who now uses that time for something more valuable because the flow runs on its own?

If the answer is yes, you have everything you need to scale.