Design Your First AI Automation

You have the pieces: triggers, actions, data flow, AI steps, and a task you picked in the earlier lesson. Now you will put them together. This lesson walks through designing a complete automation the way experienced builders do it: on paper first, then in the tool.

We will design a real example end to end, an inbox lead responder, and the process will map directly onto whatever task you chose.

What You'll Learn

• The five step design method that works in any tool
• A complete worked example you can copy
• How to build in the right order: skeleton first, AI second, actions last
• How to run a safe pilot before going live

Why design before building

Opening the tool first is the beginner move, and it usually ends with seventeen browser tabs and no automation. The tool asks precise questions immediately: which trigger, which fields, which format. If you have not decided what you are building, every question becomes research.

Ten minutes of design turns building into assembly. Here is the method.

The five step design method

Write these five answers down for your task. Plain text, no diagrams needed.

1. Trigger: what exactly starts a run? Name the app and event. "New submission on my website contact form." Check: does this fire once per item? Can it fire twice for the same item?

2. Input: what data arrives? List the fields the trigger provides. "Name, email, company, message text."

3. Thinking: what must be judged, and what is the question? Phrase the AI step as a single clear question with a fixed set of answers. "Is this a sales lead, a support request, or other? And summarize it in one sentence."

4. Routes: what happens for each answer? One line per case, including the do-nothing case. "Sales lead → Slack alert with summary plus a drafted reply saved to my drafts. Support → forward to the support inbox. Other → just log it."

5. Delivery: where does the result land, and how will I know it ran? "Slack for leads, a Google Sheet row for every run as my log."

If you can fill in these five answers, you have designed an automation. If one answer stays fuzzy, that is exactly the part to think through before opening any tool.

Worked example: the inbox lead responder

Here is the design filled in for a freelancer who gets mixed inquiries through a contact form.

• Trigger: new form submission (form app → new response event).
• Input: name, email, company, message.
• Thinking: AI classifies the message as lead, support, or other, and writes a one sentence summary. Prompt sketch: role line, the message labeled clearly, "Reply in exactly this format" with a Category line and a Summary line, and an edge rule: "If unclear, use: other."
• Routes: lead → Slack message with name, company, summary, plus an AI drafted first reply saved as a draft, never auto-sent. Support → forward to support email. Other → no action beyond logging.
• Delivery: every run appends a row to a sheet: timestamp, sender, category, summary. The sheet is the flight recorder.

Notice two deliberate choices. The drafted reply is human in the loop, a person reviews before anything reaches a customer. And the log row happens on every run, so silence in Slack still leaves a trail you can check.

Build in this order

In your tool, resist building left to right in one pass. Build in layers, testing each.

1. Skeleton first. Trigger plus the log action only. Run it. You now have a working pipeline and proof that data flows.
2. Add the AI step. Wire the message field into your prompt. Test with a normal, a weird, and a trick input, as covered in the last lesson. Fix the prompt until the format is exact.
3. Add the branch. Route on the AI's category. Point every route at the log action for now, with different text, so you can see routing work without real consequences.
4. Add real actions last. Slack, forwarding, draft creation. These touch other people, so they go in only after the thinking and routing are proven.

Each layer takes minutes, and at every point you have something that runs. Compare that to building all eight steps blind and then debugging the whole chain at once.

The pilot week

Before you call it done, run a pilot: the automation runs on real input, but its outputs stay private. Drafts instead of sent emails, a private channel instead of the team one, a log you review each evening.

During the pilot, check three things daily: did it run when it should have, did the AI classify the way you would have, and did anything land in the wrong route. Fix the prompt or the mappings as you go; small prompt edits solve most issues. After a week of clean runs, flip the private outputs to real ones. You now have an automation you actually trust, because you watched it earn that trust.

And keep the log running forever. Future you, wondering "did the form thing fire yesterday?", will be glad it exists.

Your turn

Take the task you circled in the earlier lesson and write your own five answers: trigger, input, thinking, routes, delivery. Keep the first version small, one AI step, two or three routes, one log. Shipping a modest automation this week beats planning an impressive one forever.

Key Takeaways

• Design on paper first: trigger, input, thinking, routes, delivery. Fuzzy answers reveal exactly what needs thought.
• Phrase the AI step as one clear question with a fixed set of answers, and always define the do-nothing case.
• Build in layers: skeleton, then AI, then branching, then real actions, testing each layer as you go.
• Pilot for a week with private outputs before letting the automation touch other people.
• Log every run to a sheet. It is your flight recorder when something looks off later.