How to Automatically Classify Support Emails and Create ClickUp Tasks Using Gmail, OpenAI and Make.com

Introduction

Triage is the recurring cost of inbound email: someone reads messages, decides whether they are support, sales, or noise, then copies context into task systems. That delays first response and wastes skilled time. This guide shows how to offload the first-pass work to Make.com plus OpenAI so you classify incoming Gmail and create or update ClickUp tasks for cases that need human attention, while Slack delivers the exact context people need to act.

What you will know by the end: the exact Make.com modules to use, a safe OpenAI prompt pattern that returns JSON, how to deduplicate webhook runs so you do not create duplicate ClickUp tasks, mapping recommendations for ClickUp fields, and how to route low-confidence cases to a human review queue in Slack.

If you want a Zendesk-focused approach rather than ClickUp, see our classification pattern for Zendesk.

What You’ll Need

• Gmail account with a label for inbound messages Make.com will process
• OpenAI API key (use deterministic settings: temperature 0.0 for classifications)
• Make.com account with connections for Gmail, OpenAI (HTTP is fine), ClickUp (API token), and Slack
• ClickUp List where support tasks will live, plus a custom text field named source_message_id for dedupe
• A Slack channel for alerts (for example #support-triage) and a bot token for posting
• A Google Sheet or Make Data Store for an audit log — useful for debugging and replays

Notes: OpenAI calls cost money; trim email body length to the characters you actually need (500–1,200) to keep costs and latency manageable.

How It Works (The Logic)

1. Gmail (label) → Make.com watches unread messages on that label.
2. Make.com extracts subject, first N chars of the body, message-id, and headers.
3. Make.com calls OpenAI with a strict JSON prompt asking for intent, priority and a one-line summary.
4. Make.com validates JSON and checks confidence against policy thresholds.
5. If confidence and rules indicate escalation, Make.com searches ClickUp by source_message_id (message-id). If a task exists, it appends a comment; if not, it creates a new task and writes source_message_id to the task custom field.
6. Make.com posts a concise Block-like Slack alert with link to the task and the summary.
7. All runs append an audit row to Google Sheets for observability.

This is a decision-first pattern: the model proposes but the automation enforces the gates and records evidence.

Prompt and JSON schema (practical, deterministic)

Use a short, strict prompt and ask the model to reply only in JSON. Keep temperature at 0.0.

System instruction (concise):

You are a triage assistant. Read the email subject and the short email body. Return only JSON with keys: intent, priority, summary, confidence. intent must be one of ["support","sales","spam","other"]. priority must be one of ["P1","P2","P3"]. summary is a one-sentence human-friendly summary. confidence is a decimal between 0 and 1.

User content example (send only what you need):

Subject: {{subject}} Body: {{body_snippet}}

Return JSON only.

Validation rules in Make.com:

• Accept only responses that parse as JSON.
• Ensure intent is in the allowed set and confidence is numeric.
• If confidence < 0.6 or parsing fails: set intent = "other", priority = "P3", confidence = 0.0 and route to manual review.

Store the prompt version string (for example email-v1) in your audit output so you can trace changes later.

Step-by-step Setup (Make.com exact modules and fields)

1. Trigger: Gmail "Watch emails" (label: triage/inbound, unread only)

• Fields to map from the trigger: messageId, threadId, subject, snippet (or body trimmed), and from (email and name).

2. Dedupe check (Google Sheets or Data Store)

• Module: Google Sheets, Search rows where messageId equals incoming messageId.
• If found: stop the scenario (already processed) to avoid duplicates on retries.
• If not found: append a provisional row with status processing and a run ID.

3. Clean body and build the prompt payload

• Module: Tools / Formatter or Set variable
• Create body_snippet = first 800 characters of the plain text body, remove quoted replies by splitting on "On .* wrote:" or similar heuristics.

4. OpenAI call

• Module: HTTP > POST to OpenAI Chat Completions (or Make's OpenAI module if available).
• Request: system + user as above, temperature: 0.0, max_tokens: 200.
• Map subject and body_snippet into the user block.

5. Parse and validate OpenAI JSON

• Module: JSON parse of response content.
• If parse success and confidence >= 0.6: continue.
• Else: mark manual_review = true and route to Slack review channel (do not create a task).

6. Decision rules and routing

• If intent == "support" and priority in ["P1","P2"] and confidence >= threshold (e.g. 0.7), escalate to ClickUp.
• If intent == "sales" and confidence >= 0.65, optionally create a ClickUp lead task or notify sales.
• If intent == "spam" and confidence >= 0.9, label the Gmail message Spam-Auto and archive.

7. ClickUp: Search by source_message_id custom field

• If found: ClickUp > Add Comment to the existing task with the summary and a link to the email. Update task status if needed.
• If not found: ClickUp > Create Task
  • name: Email triage: {{subject}} — {{from_name}}
  • description: include from, subject, snippet, and messageId for traceability
  • custom_fields: set source_message_id = messageId, and map any priority/custom fields you use
  • assignees: a default triage owner or map by routing rules

8. Slack notification

• Module: Slack > Post message
• Channel: #support-triage or #sales-inbound depending on routing
• Message contents: subject, from, confidence, summary, ClickUp task link. Keep short and actionable.

9. Finalise audit row

• Module: Google Sheets > Update row to status succeeded, add intent, confidence, clickup_task_id, and slack_ts.

10. Error handling

• If OpenAI returns 429 or timeout: retry with exponential backoff (1s, 3s, 10s). If repeated failure, log to errors sheet and Slack #ops with run id and payload snippet.
• For ClickUp API 5xx: retry once, then log and alert ops.

Gotchas and production tips

• Trim the body before sending to OpenAI. First 800–1200 chars capture the issue in most support emails and reduces token cost.
• Keep the classification taxonomy small and stable. Changing labels is harder to roll out and breaks historical analysis.
• Always store the messageId and the prompt_version in your audit row. If results drift you can re-run historical payloads against a new prompt and compare.
• Use conservative confidence thresholds for automatic routing to minimize false positives. Route low-confidence cases to a human triage Slack channel.

Real-world example

We implemented a similar pipeline for a SaaS support team receiving 1,000 emails per week. With a conservative confidence threshold and a manual triage channel, the team automated about 60% of incoming categorisation and reduced time-to-first-response for P1s by 40%. The audit sheet allowed weekly QA of the model's classifications and prompt tuning.

Variations and next steps

• Create Zendesk tickets instead of ClickUp tasks if your support stack uses Zendesk. See our Zendesk classification pattern for details here.
• Add an LLM summarisation step to pre-fill the ClickUp description with a one-paragraph summary to speed rep triage.
• For high-volume environments consider a two-stage classifier: cheap rule-based pre-filter and LLM only for ambiguous or high-value messages.

Closing notes

This pattern gives you a predictable, auditable way to classify Gmail with OpenAI and create ClickUp tasks for escalation using Make.com. Start with conservative thresholds, instrument an audit log and a manual review channel, and tune prompts on real examples. If you want help implementing the full scenario for your team, Olmec Dynamics builds these automations and helps tune the prompts and runbooks: see what we do at https://olmecdynamics.com.