The cheapest AI automation starts on paper

Automation gets expensive when it starts in the wrong place.

It sounds backwards, but many small teams make the same mistake: they open a tool, browse app modules, and try to decide whether the workflow should start in Gmail, Google Sheets, Facebook Lead Ads, or the CRM. An hour later there may be five boxes on the screen. The actual job is still unclear.

Make points in a more useful direction with Maia, its AI automation builder: describe the workflow in ordinary language first, then let the tool propose the scenario. That matters for small businesses, schools, and solo operators because the threshold moves away from knowing the no-code tool and toward describing the job clearly.

That second skill is cheaper to practice. You do not need a large project to begin. Start with a sheet of paper, fifteen quiet minutes, and an honest description of what actually happens when a customer, student, supplier, or colleague asks for something.

Source: Why natural language is the future of AI and workflow automation | Make

Why the Make signal matters for small teams

Make writes about natural-language automation, meaning automation built by describing the desired workflow in everyday language. In one of its examples, a user asks for every new Facebook Lead Ads lead to be logged in Google Sheets and followed up with a WhatsApp message. Maia then helps create a Make scenario from that description.

This is not just a new button. It changes where the work begins.

No-code automation has long promised that non-developers can connect apps. Often, that is true. But it does not make the work simple. You still need to choose the right trigger, connect the right account, map the right fields, handle errors, and test what happens when the data is messy. For a small organization, this is where projects stall. Not because the idea is bad, but because the workflow has not been described clearly enough.

Natural-language automation is useful when it forces a better first question: "What job should be done, in what order, with which exceptions?" If the answer is vague, the AI builder will be vague too. If the answer is concrete, AI can produce a draft that a human can review faster.

Start with the job, not the app list

A restaurant owner might think: "I want to automate bookings." That is too broad.

A better start is: "When someone sends a booking request through the form, we check date, party size, and allergies. If information is missing, the customer receives a short follow-up draft. If everything is present, the request goes into the booking list and the responsible person receives a notification. No booking is confirmed automatically until someone has checked capacity."

Now there is a workflow. Not perfect, but clear enough to discuss with an AI builder, a consultant, or a colleague.

The same applies to schools and training providers. "Automate course administration" is too vague. "When a participant signs up, create a row in the participant list, draft a welcome message for the responsible teacher, and flag missing consent" can be built, tested, and improved.

For a solo operator, the workflow may involve quote requests, receipts, reminders, supplier emails, or weekly reports. The point is the same: first write what a human does today. Then build.

The difference between a prompt, automation, and autonomy

These terms get mixed together quickly.

A prompt is an instruction to an AI model. It can write a reply, summarize an email, or suggest a next step.

An automation is a workflow between systems. It usually has a trigger, such as a new form response, followed by several actions.

Autonomous AI starts only when the system can make a bounded recurring judgment and act on it. Make describes this as more than one model call: the system needs to interpret context, choose a path, execute the next step, and document why it chose that path.

That is a useful definition for small teams. It slows down the worst kind of AI optimism. Not every workflow needs autonomy. Many only need better structure, a draft, and a clear human approval point.

Source: Autonomous AI: build it, trust it, scale it (2026) | Make

Choose decisions small enough to delegate

Make recommends autonomous workflows for decisions that are frequent, low risk, and clearly bounded. That is sensible.

Good candidates in a small organization:

• Sort incoming requests by type: booking, support, quote, invoice, or other.
• Suggest which template fits a customer email.
• Mark cases that lack required information.
• Draft a reply while leaving sending to a person.
• Move a task to the right list when the status is clear.

Poor first candidates:

• Give binding discounts.
• Approve invoices with no limit.
• Answer sensitive student or employee matters.
• Promise delivery times that affect the customer relationship.
• Change important records without an audit trail.

This is not an argument against integrations. Quite the opposite. Integrate properly. Use separate API keys, scoped permissions, logs, approval gates, and clear stop rules. Then AI can do useful work without putting every secret and decision into a chat window.

Copy this: the paper prompt for a first Make workflow

Use this prompt in ChatGPT, Gemini, Claude, Copilot, or directly in an AI builder such as Maia. Replace the bracketed parts.

You are my automation technician. Help me describe a small workflow before we build it in Make, Zapier, Airtable, Google Workspace, or another tool.

Organization: [example: small restaurant, driving school, consultant, association, school]
Team size: [number of people]
Current task: [what do we do manually today?]
Start signal: [what starts the job: email, form, DM, calendar event, file, payment?]
Goal: [what should be done when the workflow is finished?]
Systems we use: [Gmail, Google Sheets, Outlook, Fortnox, Slack, Teams, Notion, etc.]

Do this:
1. Write the workflow in no more than seven steps in plain English.
2. Mark which information must exist before the workflow can continue.
3. Suggest which steps AI can help with.
4. Put "human approves" on every step where a customer message is sent, money is affected, or personal data is handled.
5. Suggest a simple log: what should be saved, when, and why?
6. Write a test plan with five test cases, including one case with missing information and one where the AI is uncertain.
7. Finish with a short build brief that I can give to a consultant or paste into an AI automation builder.

If the AI gives you a perfect diagram immediately, be skeptical. The first thing you want is not perfection. You want to see whether the workflow can be explained without people in the room having to guess.

A concrete example: quote requests

Say you run a small trade business. Customers email photos and short descriptions. Today you read everything, ask for the address, check your calendar, and write half a reply.

The paper version could look like this:

• A new email arrives in the quote inbox.
• AI suggests a category: urgent, quote, warranty, other.
• AI checks whether address, photos, preferred date, and contact details are present.
• If something is missing, it creates a follow-up draft.
• If everything is present, it creates a row in the quote list.
• The responsible person gets a notification with a summary and link to the original email.
• No quote is sent automatically. A human chooses the next step.

It is a small workflow. That is why it works. You can build it, test it on ten old emails, and see whether it saves time before adding more steps.

Why AI projects stall even when the tools exist

Make also published data from its AI Playbook. The useful, slightly uncomfortable point: AI projects often do not stall because of technology. They stall because of ownership, priority, business value, and skills.

For Hammer Automation's typical customers, this is even clearer. In a team of two to ten people, there is rarely an AI department. The person who owns the workflow may be the same person who answers customers, books meetings, and locks the door at the end of the day.

That is why the first step has to fit into a normal week. One workflow. One owner. One metric. One Friday review.

Source: The real reason your AI projects stall: what hundreds of companies taught us about fixing it | Make

The one-week test: 60 minutes, not six months

Do this before buying more tools or building a larger system.

Monday: Choose one manual workflow that repeats at least five times per week. Write it on paper.

Tuesday: Run the paper prompt above. Ask AI to suggest seven steps, approval points, and test cases.

Wednesday: Build only the first two steps in your automation tool, or ask someone to build a draft. Do not connect automatic customer communication yet.

Thursday: Test with old examples. Save what AI got right, what it missed, and where a person had to step in.

Friday: Decide whether the workflow should continue, change, or pause. If nobody can explain the value in two minutes, it is not ready.

This fits especially well in Tool Forge, where Hammer helps teams move from a loose idea to a working workflow. If the team first needs shared language, exercises, and decisions about what AI is allowed to do, Skill Forge is a better starting point. The tool is rarely the first problem. The fog is.

What to measure

Do not measure "we use AI". It says almost nothing.

Measure this instead:

• How many minutes did the workflow save per case?
• How many cases needed more information?
• How often did AI suggest the right category?
• How many drafts had to be rewritten completely?
• Was the approval point clear to the person who owns the job?
• Could you trace what happened afterwards?

If the answers are boringly concrete, you are on the right path. This is how small teams get value from AI automation: not by chasing the most advanced agent, but by making one recurring job clear enough to build, test, and trust.