Chandra owns a five-chair barbershop in Austin that also sells grooming products online. She was already using Zapier for a simple booking confirmation when her web developer mentioned Make, formerly known as Integromat, as a more capable option for what she wanted next. She switched, built her first scenario in an afternoon, and within two weeks had an AI workflow running that she had not been able to assemble before: a multi-step process that read the week's customer reviews, used AI to identify recurring complaints, and updated a shared staff note in Google Docs every Monday morning. No developers. No code. Just a visual flowchart and some patience.

What Make Is

Make is an automation platform, a tool that connects the software applications you already use and moves data between them automatically. Like Zapier, it works by linking triggers, meaning something that starts the workflow, to actions, meaning the things the workflow does in response. If you have built a Zap before, none of the vocabulary here will be foreign. What changes is the shape of the thing you are building and how much of your logic can live inside a single one of them.

Make also ships modules for the major AI APIs, including OpenAI's API and Anthropic's Claude API. That matters more than it sounds. When an AI call is an ordinary module you can drop anywhere on the canvas, you can put genuine AI reasoning in the middle of a workflow rather than only at the start or the end. The AI reads what earlier modules produced, and later modules act on what the AI decided. That middle position is where most of the interesting small business automations live.

Scenarios Versus Linear Step Lists

The structural difference is branching. In a linear builder, a workflow is a numbered list of steps that runs top to bottom, and making it do one thing when a condition is true and something else when it is false means splitting the work across separate workflows and finding a way to keep them in step. In Make you draw the branch directly on the canvas: one route continues left, another continues right, and both are visible in the same picture. It is the difference between a flowchart on paper and a numbered list of instructions.

That difference shows up immediately in AI workflows, because AI steps produce judgments and judgments want routing. If the AI classifies an inquiry as high priority, you want one path. If it classifies it as a poor fit, you want another. On a canvas, that is one scenario with two routes leaving a router module. Expressed as a list, it becomes several workflows that each have to re-check the same condition, and the logic stops being visible in one place, which is exactly when it starts to drift.

Anatomy of a Make Scenario

A scenario in Make is the visual diagram of your workflow. It contains modules connected by lines, like a flowchart. Each module represents one action: get a new Google Form submission, send the text to OpenAI, post the result to Slack. You build it by dropping modules onto the canvas and joining them, and you can watch data flow through the connections when you run it, which makes debugging a matter of looking rather than guessing.

Every scenario starts with a trigger module, the event that kicks off the workflow. Common triggers for small businesses:

• A new row appears in a Google Sheet
• A form is submitted, through Typeform, Google Forms or JotForm
• A new email arrives in Gmail matching a filter
• A new order is placed in Shopify or WooCommerce
• A scheduled time, for example every Monday at 8 AM

After the trigger you add action modules, the things Make does with the triggered data. The AI power comes from the OpenAI or Anthropic modules, which take text from your data and return AI-generated text you can then route into another action. Between those, Make provides utility modules that do no external work at all: aggregators that bundle many records into one block of text, iterators that do the reverse, filters that stop a route when a condition is not met, and routers that split one path into several.

One piece of vocabulary is worth learning early because it governs your bill. Make meters usage in operations, where one operation is one module executed in one scenario run. A scenario that runs once consumes one operation for every module it executes, not one for the run. This is a different mental model from paying per workflow run, and it has a design consequence: filtering early, so that routes stop before they reach expensive modules, is both a correctness habit and an efficiency habit.

Chandra's Review Analysis Scenario, Step by Step

This is a real workflow you can build for any business that collects customer reviews. Here is exactly how Chandra's scenario is assembled, module by module.

Module 1, the trigger: Scheduled, running every Monday at 7 AM. Nothing external starts this workflow. It wakes itself up.

Module 2: Google Sheets, reading all rows added to a "Weekly Reviews" sheet in the previous seven days. Chandra keeps a separate, simpler Zap that pastes new Google and Yelp reviews into this sheet as they arrive, so by Monday the sheet is already the week's raw material.

Module 3: Text Aggregator, Make's built-in tool that bundles the review text from multiple rows into a single block of text. Without this module the scenario would send one AI call per review, which would cost more operations and, worse, would prevent the AI from seeing patterns across reviews, which is the entire point.

Module 4: OpenAI, which receives the bundled review text with this prompt: "You are analyzing customer reviews for a barbershop. Identify the top 3 recurring complaints and the top 3 recurring compliments from this week's reviews. Format your response as two short bulleted lists."

Module 5: Google Docs, appending the AI's output to a shared document called "Weekly Staff Notes," including the date. Appending rather than replacing means the document becomes a running history, and a run of entries side by side shows whether a complaint is being fixed or repeating.

Every Monday morning Chandra's staff opens the Google Doc and finds a clean summary of what customers said that week. Nobody sorts through 15 reviews individually. The whole scenario runs in about 45 seconds, and the AI module bills through the API on the amount of text it processed, which for a week of short reviews is a small fraction of what the time saved is worth.

Three More Scenarios Worth Building

New lead qualifier

Trigger: a new contact form submission on your website. AI step: send the inquiry text to OpenAI with a prompt that classifies the lead as "High priority," meaning ready to buy with a specific request, "Nurture," meaning browsing and vague, or "Not a fit," meaning wrong geography or wrong service. Action: route to different Gmail labels and Slack alerts based on the classification. High-priority leads trigger a Slack ping to you immediately, nurture leads enter an automated email sequence, and not-a-fit leads receive a polite auto-reply.

This is the canonical branching scenario, and the reason to build it second rather than first is that it acts on the AI's judgment without you reading it. Run it with every route also logging to a sheet, and check how often you disagreed with the classification before you let the not-a-fit route send anything on its own.

Invoice to expense category auto-tagger

Trigger: a new email from a known vendor in Gmail. AI step: extract the invoice amount and description from the email body, then ask the AI to classify the expense as one of your standard categories, such as supplies, rent, marketing or equipment. Action: add a row to the Google Sheet your bookkeeper uses for monthly reconciliation, pre-filled with vendor, amount, date and category.

Note that the AI here is doing extraction as well as classification, pulling an amount and a description out of prose that was never designed to be machine-readable. That makes the reliability of the output worth watching in a way the review summary is not, because the row lands in a sheet your bookkeeper trusts. Send the extracted values through to the sheet and keep the original email reference in a column beside them, so a wrong figure is traceable back to its source in seconds rather than being an orphan number in a reconciliation.

Appointment no-show follow-up

Trigger: scheduled, running hourly during business hours. Make step: check your booking system, through its API or a connected Google Sheet, for appointments marked "no-show" in the last hour. AI step: generate a personalized re-booking message using the customer's name and original appointment type. Action: send it by SMS through Twilio, or by email.

All three share the same skeleton as Chandra's: something arrives or a clock ticks, data is gathered, an AI module turns that data into a judgment or a piece of writing, and an action module puts the result where a person or a system will meet it. Once you can see that skeleton, most of the automations your business wants become variations on it, and the design question stops being "what can this tool do" and becomes "which of my recurring decisions is worth handing over, and what would I need to see to trust the handover."

Error Handling Paths

Make lets you attach error handling to a module directly on the canvas. Right-click a module and you can add an error handler, a separate path the scenario follows if that module fails. Instead of one broken step silently killing the run, the failure becomes a route you designed, going somewhere you chose. Because the handler is drawn on the same canvas as the happy path, you can see at a glance which modules have a fallback and which are still one bad response away from stopping the scenario.

At minimum, put an error handler on your AI module, because API calls fail occasionally for reasons that have nothing to do with your design, and have it send you an email notification. That takes about thirty seconds to set up and saves a great deal of confusion later, because the failure mode it prevents is the worst kind: a workflow that stopped working weeks ago and told nobody. A scenario you trust is not one that never fails. It is one that tells you when it does.

Anti-Patterns

• Shipping a scenario with no error handler on the AI module. An occasional failed API call is normal. A scenario that fails silently for a month while you assume it is running is not, and the gap between them is one right-click wide.
• Calling the AI once per record when the pattern lives across records. Chandra's summary works because the aggregator bundles the week into one call. Loop the AI over each review instead and you spend more operations for an answer that cannot see the pattern you asked about.
• Filtering after the expensive module instead of before it. Every module that executes consumes an operation, so a filter placed after the AI call pays for a result you were about to discard, on every run.
• Letting a classification act on the world before you have audited it. Routing on an AI judgment is powerful and irreversible in equal measure. Log the classification against the outcome for a while first, and read the log.
• Treating the visual layout as documentation. A diagram shows what connects to what, not why. Name modules for what they do in your business, or you will later be reading "Google Sheets, Google Sheets, OpenAI" and guessing.

Practice Prompts

• Turn a manual routine into modules. "Here is a task I do by hand every week: [describe it, including where the information starts and where it ends up]. Break it into a sequence of automation modules. For each, tell me what it takes in, what it puts out, and whether it needs to be an AI step or an ordinary data step."
• Find the branch. "This workflow currently does the same thing for every record: [describe it]. Identify the decision points where different records should be treated differently. For each, tell me what the AI would need to see in order to decide, and what should happen on each route."
• Write a classification prompt that routes cleanly. "Write a prompt for an automation step that reads a customer inquiry and returns exactly one of these labels and nothing else: [list your labels]. Define each label with an example that fits and a borderline one that does not. The output will be used to route the message, so it must be one label with no explanation."
• Write an aggregate analysis prompt. "Write a prompt for a step that receives a block of text containing every [review, ticket, inquiry] from the past week concatenated together. It should return recurring themes rather than a summary of each item, in two short bulleted lists, under [n] words, for a staff team reading it on a Monday morning."
• Plan the failure paths. "Here is my scenario: [list the modules in order]. For each, tell me what a failure would look like from the outside, and what the error path should do: notify me, retry, skip the record, or stop the run."

Reflection

• Which of your workflows are really two workflows, doing identical steps for records that deserve different treatment?
• Chandra's scenario runs on a schedule rather than an event. Which of your recurring questions would be better answered weekly than continuously?
• If one of your automations stopped working today, how long would it take you to notice, and what would tell you?
• Which decisions are you willing to let an AI classification make unattended, and which should stop for a person?

Glossary

• Scenario. Make's name for a workflow: a visual diagram of modules connected by lines, built and viewed on a canvas.
• Module. A single step in a scenario, performing one action such as reading a sheet, calling an AI service, or writing to a document.
• Trigger module. The first module in a scenario, defining the event that starts it: either an external event or a schedule.
• Operation. Make's unit of usage: one module executed in one scenario run. A scenario that runs once consumes one for every module it executes.
• Text Aggregator. A built-in module that bundles text from many records into a single block, so one AI call can see all of them at once.
• Router. A module that splits one path into several, so different records follow different routes through the same scenario.
• Filter. A condition on a connection that stops a route when the condition is not met. Placed early, it saves operations as well as mistakes.
• Error handler. An alternative path attached to a module and followed when that module fails, making a failure a designed outcome rather than a silent stop.
• Branching logic. Workflow structure in which the path taken depends on a condition, drawn on the canvas rather than split across separate workflows.

Related Lessons

• Zapier AI Actions: Step-by-Step Guide builds the linear version of the same idea, and is the better first platform for a single-path workflow.
• API Basics: Connecting AI Services Directly explains what the OpenAI and Anthropic modules are doing underneath.
• Error Handling and Monitoring AI Workflows takes the error handler idea from one module to a whole portfolio of automations.
• Multi-Step AI Workflow Architecture covers how to structure things once one scenario is no longer enough.
• Troubleshooting AI Integrations: Common Issues is the diagnostic companion for the day a module turns red.

Closing

Chandra did not become technical. She learned one idea, that a workflow can be a picture rather than a list, and that picture let her put an AI judgment in the middle of a process instead of at the end of one. The Monday morning note is not impressive engineering: a scheduled read, a bundle, one AI call and an append. It replaced a job nobody was doing because nobody had time to read fifteen reviews looking for a pattern. Build that same shape first, put an error handler on the AI module before you turn it on, and judge the result after a few weeks by whether anyone used it.

Key Takeaways

• A scenario is a visual flowchart of modules. A trigger starts it, action modules process data, an AI module from OpenAI or Anthropic adds reasoning in the middle, and output modules deliver the result somewhere a person will see it.
• Branching is the reason to build on a canvas. When the route depends on a condition, drawing it in one picture keeps the logic visible; splitting it across separate linear workflows is where logic starts to drift.
• AI modules put reasoning mid-workflow, not just at the edges. Earlier modules gather the input, the AI decides something about it, and later modules act on that decision.
• Make meters operations, not runs. One module executed in one run is one operation, so filtering early and aggregating before an AI call are efficiency decisions as much as design decisions.
• Aggregate before you analyze. Bundling a week of reviews into one call is what makes the summary possible; calling the AI once per review costs more and cannot see across the set.
• Always add an error handler on your AI module. API calls fail occasionally, and a silent failure is far harder to diagnose than an email telling you it happened.
• Start with a scheduled trigger, an AI analysis and a document output. It is the simplest useful pattern, which is why the review summary is a good first project.

Frequently Asked Questions

Should I switch from a linear builder to Make?

Only if your workflow has a branch in it. A single-path automation, meaning one trigger, one AI step and one action, is easier to build and maintain on a linear builder, and switching platforms for it buys nothing. The moment you find yourself building a second workflow whose only job is to handle the case the first one does not cover, a canvas would hold the whole thing in one place.

Can I run Make and my existing automations side by side?

Yes, and Chandra does. Her simpler Zap collects reviews into a Google Sheet while her Make scenario reads that sheet on a schedule. Using a shared spreadsheet or database as the handover point between two platforms is a common and durable pattern, because each side only has to know about the sheet rather than about the other platform.

How do I keep the operation count under control?

Filter early and aggregate before expensive steps. Every module that executes in a run consumes an operation, so a filter at the top of a route stops the route before it spends anything, while the same filter at the bottom pays for everything above it first. Aggregating many records into a single AI call rather than looping is the other large saving, and it usually produces a better answer too.

What happens when the AI module returns something unexpected?

Whatever the next module does with it, which is why the error handler and the prompt both matter. An outright API failure follows the error path if you built one. A response that arrives but is shaped differently from what you expected is the more insidious case, because the run counts as successful while the downstream module writes something wrong. Constrain the output format whenever the response will be routed on or parsed.

Do I need a developer to use the OpenAI or Anthropic modules?

No. The module handles the request; what you supply is an account with the provider, the credential from that account, the input fields and the prompt. The work that remains is prompt writing and workflow design, both closer to giving clear instructions to a new employee than to programming.