Make.com for Virtual Assistants: The Beginner Setup Guide (2026)

Concept 1 — Modules

A module is a single automated step. Every module connects to one app or function and performs one action: watch a Gmail inbox, create a ClickUp task, send an HTTP request to an API, transform data, or route the workflow conditionally.

There are five module types:

• Triggers — watch for an event and start the scenario (e.g., ‘New email in Gmail label X’)
• Actions — perform one operation in an app (e.g., ‘Create task in ClickUp’)
• Searches — find existing records in an app (e.g., ‘Search for contact in HubSpot’)
• Aggregators — combine multiple bundles of data into one output (essential for reports)
• Iterators — split one bundle containing an array into individual bundles for sequential processing

You use Triggers and Actions in your first scenario. Aggregators and Iterators appear in the reporting and bulk-processing scenarios in Section 6.

Concept 2 — Operations

An operation is one module execution. Every time a module runs as part of a scenario, each module execution counts as one operation against your monthly plan limit. A scenario with 8 modules that runs 50 times in a month uses 400 operations. On the Core plan’s 10,000-operation monthly allowance, that leaves 9,600 operations for all other scenarios.

Important:  Operations also count when a scenario encounters an error and executes an error-handling module. Configure error handlers deliberately, covered in Section 7.

Concept 3 — Bundles

A bundle is one unit of data flowing through a scenario. When a trigger fires and captures a new Gmail email, that email’s data becomes one bundle (carrying subject, body, sender, and timestamp) available for mapping in every subsequent module.

When a module produces multiple outputs (for example, a search returning five matching ClickUp tasks), it produces five bundles. Each bundle moves through the scenario independently, which is why the Iterator module is required when processing multiple records: it explicitly loops through each bundle one at a time.

Understanding bundles prevents the most common beginner mistake: expecting one module to automatically process multiple records without an Iterator.

Concept 4 — Scenarios

A scenario is the complete automation: one or more triggers, a sequence of connected modules, and all the configuration that tells each module what to do with the data it receives. Scenarios can be:

• Active — scheduled to run automatically at a defined interval or in response to a webhook
• Inactive — saved but not running (use for scenarios under construction or temporarily paused)
• Scheduled — run at set intervals (every 15 minutes, every hour, every Monday at 8am)
• Webhook-triggered — run instantly when an external event sends data to Make

For VA operations, most scenarios are either scheduled (weekly reports, Monday planning tasks) or webhook-triggered (immediate response to form submissions, contract signatures, new bookings).

Concept 5 — Routes and Routers

A Router module splits a scenario into multiple conditional branches. Instead of building separate scenarios for different clients or different trigger conditions, a Router handles all variations within one scenario.

Example: a client intake form arrives. If the service type field says ‘Social Media Management,’ route to Branch A (create a social media client workspace). If it says ‘Admin Support,’ route to Branch B (create an admin client workspace). Both branches continue to shared modules after diverging.

The Router is the feature that makes Make more powerful than Zapier for complex VA workflows. Section 6 includes a scenario with a Router so you can see it in practice.

Step 1 — Create the Scenario

In Make, click Create a new scenario. The canvas opens blank with a prompt to add the first module. Click the + icon.

Step 2 — Configure the Trigger Module

Search for Gmail → select ‘Watch Emails.’ In the module configuration:

• Connection: select your Gmail connection
• Folder: INBOX
• Search filter: label:⚡ Task (exact syntax, use whichever label you apply to action-required emails)
• Mark email as read: Yes
• Maximum number of results: 1

Click OK. Make asks you to run the trigger to find an existing email for test data, apply your label to a real email and click Run to capture it. This test bundle becomes the sample data you use to map fields in the next module.

Step 3 — Configure the Action Module

Click + to add a module after the trigger. Search for ClickUp → select ‘Create a Task.’ In the module configuration:

To map a field: click the empty field → click the lightning bolt icon → select the Gmail module → choose the data field. The mapped value appears in orange.

Step 4 — Add a Notification Module

Click + to add a third module. Search for Slack → ‘Send a Message’ (or Gmail → ‘Send an Email’ if you use email for self-notifications). Configure a brief notification to yourself:

Channel: your #task-alerts channel or your own email

Message: ⚡ New task: {{1.subject}} | ClickUp: {{2.url}}

Where {{1.subject}} maps the Gmail subject and {{2.url}} maps the ClickUp task URL returned by the create action.

Step 5 — Test the Scenario

Click ‘Run once.‘ Apply your label to a real email. Watch the scenario execute module by module, each module turns green on success. Verify the ClickUp task was created with the correct name and description.

If a module turns red, click it to see the error message. Common beginner errors:

• ‘List not found’ — the List mapping is missing or the List ID changed. Reconnect and re-map.
• ‘Insufficient permissions’ — the ClickUp connection needs re-authorization. Go to Connections → refresh.
• ‘No data returned from trigger’ — the Gmail search filter found no emails. Verify the label is applied and the filter syntax is exact.

Step 6 — Activate the Scenario

Click the toggle switch from Off to On. Set the scheduling interval, for email-to-task, every 15 minutes on Free or every 5 minutes on Core. The scenario is now live. Every email you label triggers a ClickUp task without your involvement.

Scenario 1 — Client Intake Form → Full Workspace Setup

What it does: Converts a new client intake form submission into a complete operational setup (Google Drive folder structure, ClickUp client list, and welcome email) without manual intervention.

TRIGGER: Webhooks → 'Custom Webhook'
(Paste webhook URL into Tally or Typeform submission settings)

MODULE 1: Google Drive → 'Create a Folder'
  Name: map from form field 'Client Name'
  Parent: /Clients/ (your master client folder)

MODULE 2: Google Drive → 'Create a Folder' (repeat ×3 for subfolders)
  Parent: output URL from Module 1
  Create: Admin / Deliverables / Assets

MODULE 3: ClickUp → 'Create a List'
  Name: map from form field 'Client Name'
  Folder: Client Work

MODULE 4: Gmail → 'Send an Email'
  To: form field 'Client Email'
  Subject: 'Welcome, [Client Name] — Here's What Happens Next'
  Body: welcome email template with workspace link

MODULE 5: Slack → 'Send a Message'
  Message: '✅ [Client Name] workspace ready — ClickUp + Drive configured'

Router variant: Insert a Router between the webhook trigger and Module 1. Configure the Router’s filter to read the ‘Service Type’ field from the form. Branch A runs the standard admin template; Branch B runs a social media client template with a different ClickUp list structure. One scenario handles all service types without duplication.

Scenario 2 — Weekly Client Task Report with AI Narrative

What it does: Pulls every completed task from a client’s ClickUp list for the current week, compiles them via Iterator and Aggregator, sends them to Claude for a narrative summary, and delivers the formatted report via email every Friday at 4:00 PM, without manual production work.

TRIGGER: Make Scheduler → Every Friday at 4:00 PM

MODULE 1: ClickUp → 'Search Tasks'
  List: [client list ID]
  Status: Done
  Date Completed: after {{formatDate(addDays(now; -7); 'YYYY-MM-DD')}}

MODULE 2: Iterator → processes each task bundle
  Array: output from Module 1

MODULE 3: Tools → 'Set Variable' (per iteration)
  Value: '• {{task.name}} — completed {{formatDate(task.date_closed; 'DD MMM')}}'

MODULE 4: Text Aggregator
  Source module: Iterator (Module 2)
  Text: {{3.task_entry}}
  (Combines all task strings into one block)

MODULE 5: HTTP → Anthropic Claude API
  URL: https://api.anthropic.com/v1/messages
  Method: POST
  Headers: Content-Type: application/json
           x-api-key: [your Anthropic API key]
  Body: JSON prompt referencing aggregated task list

MODULE 6: Gmail → 'Send an Email'
  To: [client email]
  Subject: 'Weekly Update — [Client Name] — {{formatDate(now; DD MMM)}}'
  Body: AI output from Module 5 + Looker Studio dashboard link

MODULE 7: Google Sheets → 'Add a Row' (reporting log)
  Data: client, date, task count, report sent date

The Iterator + Aggregator combination is the key Make capability this scenario demonstrates. Without it, a Zapier equivalent would send one email per task. Make compiles all tasks into a single professional summary.

👉 How to Automate Client Reporting as a Virtual Assistant — for the complete 4-layer reporting stack including Google Looker Studio dashboards.

Scenario 3 — Content Approved → Multi-Platform Scheduling (with Router)

What it does: When a content item in a Notion database is marked ‘Approved,’ routes it to the correct Buffer channel based on platform, schedules the post, and notifies the client automatically.

TRIGGER: Notion → 'Watch Database Items'
  Database: [Content Calendar database ID]
  Filter: Status = 'Approved'

ROUTER → branches by Platform field:
  Branch A: Platform = 'Instagram'
  Branch B: Platform = 'LinkedIn'
  Branch C: Platform = 'X'

  [Each branch]
  MODULE: Buffer → 'Create Update'
    Profile: [client's channel for this platform]
    Text: map from Notion 'Caption' field
    Scheduled At: map from Notion 'Publish Date' field

MODULE 4: Notion → 'Update a Database Item'
  Status → set to 'Scheduled'

MODULE 5: Gmail → 'Send an Email'
  To: [client email]
  Subject: 'Content scheduled: [post title] — [publish date]'

The Router handling all three platform branches in one scenario, versus three separate Zapier Zaps with identical triggers, is the practical demonstration of why Make is the right tool for content pipeline automation.

👉 How to Automate Social Media as a Virtual Assistant — for the full social media automation system this scenario belongs to.

Scenario 4 — New Lead → AI Scoring → Conditional CRM Routing

What it does: Receives a new lead from a contact form, sends the data to Claude for AI scoring, routes high/medium/low leads to different follow-up sequences, and creates the appropriate ClickUp task with priority set by the AI score.

TRIGGER: Webhooks → 'Custom Webhook' (form submission)

MODULE 1: HTTP → Claude API (Anthropic)
  Prompt: 'Score this lead 1–10. Criteria:
  Budget mentioned: +3 | Timeline <30 days: +2
  Service matches specialty: +2 | Referral source: +1
  Complete form submitted: +1 | Specific project described: +1
  Output: JSON { score: N, rationale: '...' }
  Lead data: {{webhook.body}}'

MODULE 2: JSON → 'Parse JSON' (extract score from AI output)

ROUTER → branches by score:
  Branch A: score >= 7 (High priority)
    → Gmail: personalized response + discovery call link
    → ClickUp: Priority = Urgent, Due = Today
    → CRM: Status = Hot Lead

  Branch B: score 4–6 (Medium priority)
    → Gmail: intake form sent
    → ClickUp: Priority = High, Due = Today + 2
    → CRM: Status = Warm Lead

  Branch C: score <=3 (Low priority)
    → Gmail: standard info email
    → ClickUp: Priority = Normal, Due = Today + 5
    → CRM: Status = Cold Lead

Scenario 5 — Monday AI-Generated Weekly Plan

What it does: Every Monday at 7:30 AM, pulls all open tasks across active client lists, sends the combined data to Claude, and creates a prioritized weekly plan task in ClickUp, ready for review when the VA starts work.

TRIGGER: Make Scheduler → Every Monday at 7:30 AM

MODULE 1: ClickUp → 'Search Tasks' (across all active client lists)
  Status: not Done
  Due date: before {{formatDate(addDays(now; 14); 'YYYY-MM-DD')}}

MODULE 2: Text Aggregator
  Combines task names, due dates, and client labels into one block

MODULE 3: HTTP → Claude API
  Prompt: 'Create a prioritized weekly plan from this task list.
  Priority logic: Deadline within 2 days = URGENT.
  Client-flagged = HIGH. Blocking client next step = HIGH.
  All else = by deadline proximity.
  Output: structured Mon–Fri plan with time blocks.
  Tasks: {{aggregator.text}}'

MODULE 4: ClickUp → 'Create a Task'
  Name: 'Weekly Plan — {{formatDate(now; DD MMM)}}'
  List: Admin & Operations
  Description: AI output from Module 3
  Due Date: this Friday

MODULE 5: Gmail → 'Send an Email'
  To: [your email]
  Subject: 'Your weekly plan is ready'
  Body: AI plan output + ClickUp task link

Setting Up an Error Handler

In any scenario module, right-click the module to access the contextual menu. Click ‘Add error handler.’ Make adds an error route branching from that module, a separate path that executes only when the module fails. For most VA scenarios, the error handler should send a notification:

Error Handler → Gmail → 'Send an Email'
  To: [your email]
  Subject: '⚠️ Automation failure: [scenario name]'
  Body: 'Module [X] in [scenario name] failed at {{now}}
         Error: {{error.message}}'

This notification arrives within minutes of any failure with enough context to diagnose and fix the issue before it affects a client.

Using the Execution Log

In every active scenario, the History tab shows every execution: modules that ran, bundles processed, operations consumed, and errors encountered. For debugging unexpected output, the execution log is the first place to check, it shows exactly what data each module received and returned.

On the Core plan, execution logs are retained for 30 days. On Pro, full-text log search is available, which is valuable when debugging a specific error that occurred in one execution among dozens, one practical reason to consider Pro if you build automation as a billable service.

Monthly Maintenance Habit

Once a month, open the History tab for each active production scenario and verify all executions show ‘Success’ status. Quarterly, check that all app connections are still authorized, OAuth tokens for Google and Slack expire periodically and require reauthorization. A 20-minute monthly check prevents the client trust damage of a silent failure caught three weeks late.

The Three Conventions That Enable Duplication

Convention 1: Name every scenario with a client prefix.

Format: [Client Name] — [Scenario Type]. Example: Acme Corp — Weekly Report. This keeps the scenario list scannable and makes the copy-rename-reconfigure flow obvious when onboarding client 5.

Convention 2: Store all client-specific variables in a Data Store, not hardcoded in modules.

A Make Data Store is a simple key-value database within Make that scenarios can read from. Instead of hardcoding ‘client email = sarah@acme.com’ in a Gmail module, store it in a Data Store record for ‘Acme Corp’ and map from there. When the email changes, you update one Data Store record, not every module in every scenario.

Set up a Data Store named ‘Client Config’ with records for each client: email, ClickUp list ID, Google Drive folder ID, Slack channel, and preferred reporting cadence.

Convention 3: Save scenario blueprints before duplicating.

Make allows export of any scenario as a JSON blueprint file (Scenario → More → Export Blueprint). Save every template scenario as a blueprint in your local drive. When building for a new client, import the blueprint, rename it, and update the Data Store values. Never rebuild the module sequence from scratch.

The 20-Minute New Client Setup

1. 5 minutes: create a new Data Store record with the client’s config values
2. 10 minutes: import the blueprint for each scenario type needed, rename with the client prefix, verify Data Store connection
3. 5 minutes: run each scenario once in test mode to confirm Data Store values are reading correctly and all connections are authorized

That is the return on the investment made in structured design during the first client setup.