A Simple Automation Project Plan for Small Businesses

TL;DR / Key Takeaways

• Automation projects fail most often because the workflow was not understood clearly before anyone built anything.
• A good automation project follows six stages: discovery, workflow mapping, prototype, testing, handoff, and maintenance.
• The business owner needs to be involved in discovery and testing — those two stages cannot be handed off entirely to a developer.
• You should be able to see and understand what the automation does before it goes live.
• Start with one workflow that is genuinely painful, not with the biggest or most impressive idea on the list.

---

What Most Automation Projects Get Wrong

The most common mistake is skipping to the build.

Someone has an idea, a tool gets picked, someone starts connecting things, and three weeks later the automation is either broken or doing something slightly different from what anyone actually wanted.

The fix is not a better tool. It is a better process.

Here is how a real automation project should go, in plain English, and what you should expect at each step.

---

Stage One: Discovery

Before anything gets built, someone needs to understand the problem.

That means asking basic questions. What is the workflow right now? Who does it? How often? What triggers it? What breaks it? What does the output look like when it works correctly?

This sounds obvious but it almost never happens thoroughly enough. People describe what they think the workflow is, which is often different from what it actually is.

If you are working with a consultant or developer, this stage should feel like an interview. They should be asking you questions, not presenting solutions yet.

If someone skips discovery and goes straight to proposing a tool, slow down.

What you should expect: One or two conversations. Maybe a short questionnaire. A summary of what was discussed that you can confirm or correct.

---

Stage Two: Workflow Mapping

Once the workflow is understood, it needs to be written down in a way everyone can follow.

This does not have to be a formal diagram. It can be a simple list. Step one happens, which causes step two, which requires this piece of data, which goes to this person or system. If this condition is true, it goes here. If not, it goes there.

The point is to make the logic visible before anyone writes a line of code or sets up a single automation tool.

This is also when you discover the edge cases. What happens when a customer submits the form twice? What if the data is missing a field? What if the downstream system is unavailable? These are much cheaper to solve on paper than in production.

What you should expect: A written summary or simple diagram of the workflow. A short list of edge cases and how each one should be handled. Your review and sign-off before anything gets built.

---

Stage Three: First Prototype

Now someone builds the first working version.

The goal here is not perfection. The goal is something real that you can actually look at and react to. A prototype should do the core job under normal conditions. It does not need to handle every edge case yet.

This is where the tool choice matters. The right tool depends on what the workflow touches, how complex the logic is, and whether the business needs something simple and maintainable or something more custom.

A good prototype should be demonstrable. You should be able to watch it run and confirm that it is doing what you expected.

What you should expect: A working version of the core workflow. A short walkthrough from the builder showing you what it does and how. This is not the finished product — it is a starting point for feedback.

---

Stage Four: Testing

Testing is not the developer checking their own work. Testing is you and your team running real scenarios and looking for problems.

This means feeding the automation real data, or data that looks exactly like real data. It means trying the cases that are slightly unusual. It means having the person who normally does this job manually watch the automation run and flag anything that looks wrong.

Testing usually surfaces two or three things that need to be adjusted. That is normal and expected. The prototype was designed to be iterated on.

Do not skip this stage to save time. Issues found in testing are cheap. Issues found after something goes live are not.

What you should expect: A defined testing period, usually one to two weeks depending on the complexity. A way to report issues. A second version of the automation that addresses what testing found.

---

Stage Five: Handoff

Once testing is complete and the automation is working correctly, it needs to be handed off properly.

Handoff means three things.

First, documentation. What does the automation do, where does it live, and how does someone turn it off in an emergency? This does not need to be a manual. It needs to be enough that someone other than the builder can understand what is running.

Second, access. The right people need to have access to the tool or platform the automation runs on. It should not live only in a developer's account.

Third, a walkthrough. The person or team responsible for this workflow should see how the automation works, understand what it does when something goes wrong, and know who to call if it breaks.

What you should expect: Short written documentation. Access credentials or account ownership transferred appropriately. At least one walkthrough with whoever owns the workflow going forward.

---

Stage Six: Maintenance

Automations are not set-and-forget systems.

They depend on APIs that change, forms that get updated, data formats that shift, and downstream systems that occasionally do unexpected things. A working automation today can break in six months because something upstream changed.

Someone needs to own maintenance. That might be an internal person, a developer on retainer, or a consultant you can call when something breaks.

The maintenance burden for a simple automation is usually low. But it is not zero. Build that expectation in from the start.

What you should expect: Clarity on who owns maintenance before the project closes. A basic monitoring setup so someone gets notified if the automation fails instead of quietly stops working.

---

How Long Does This Take?

For a simple automation — one workflow, one or two systems, no complex branching logic — you are typically looking at two to four weeks from discovery to handoff. More complex projects take longer, usually because testing and edge cases take more time than expected.

The stages do not always run perfectly in sequence. Testing sometimes sends you back to the prototype. Discovery sometimes surfaces a second workflow that is tangled up with the first one. That is fine. The structure is a guide, not a rigid timeline.

---

Where to Start

If you have never done an automation project before, start with the workflow that is genuinely the most annoying. Not the most impressive one. The one that someone on your team does manually every week and quietly dreads.

Start there, do it right, and you will learn more from that one project than from any amount of planning ahead of time.

If you want help thinking through discovery and workflow mapping before committing to anything, that is usually the most valuable place to start.