I built the first version of this support auto-responder with a basic idea: customer email comes in, ChatGPT reads it, Zapier sends a reply. It looked fine in the editor. Then I started feeding it the emails that cause support teams trouble. Shipping delays mixed with refund requests. Angry messages with legal language. Customers replying to old threads with half the original conversation quoted below.
The version below uses ChatGPT (OpenAI) inside Zapier and keeps the AI between two human-controlled points. Gmail decides which messages are worth processing. The model classifies the message and drafts a reply. Zapier checks the result before anything is sent. Sensitive cases go to a person. The current ChatGPT (OpenAI) app in Zapier uses the OpenAI Responses API for its Conversation action, and Zapier has also moved away from the older Assistants-based actions. If you are building this now, use the current Conversation or Send Prompt action instead of an old Assistant action.
What I Keep Automatic
The workflow handle the repetitive part of support: finding the right kind of email, cleaning the message, pulling the relevant help text, writing a short answer, and sending it when the request is low risk. I keep refunds, account security issues, and complaints in the human queue.
Split comes from the mistakes I got when i was building the flow. A customer can ask “where is my refund?” and the model may see Billing as the main category. The same email can also contain a delivery problem, a promise made by another agent, and a request for a refund. A single label does not capture all of that. I use the category for routing, then I run a separate safety check over the email text before sending anything.
The Gmail part is also narrower than a normal “new email” trigger. Zapier's Gmail integration supports New Email Matching Search, and it trigger only looks back one hour for matching mail. The search field to keep newsletters, internal mail, and automated notices out of the AI step.
The Gmail Filter I Start With
For a shared support inbox, I use a search string close to this:
to:(support@yourcompany.com) -from:(noreply@yourcompany.com) -from:(*@yourcompany.com) -has:userlabels
I change the last line to match the way the inbox is organized. Some teams already label support mail in Gmail. In that case take the label as the trigger filter and let Gmail do the sorting before Zapier sees the message.
I also test the search directly inside Gmail before putting it into Zapier. If Gmail returns the wrong messages, the Zap will do the same thing. Zapier's current Gmail documentation also points out that “New Email Matching Search” is a polling trigger. Matching mail older than one hour will not be picked up by that trigger.
Clean Message Before Sending It to the Model
Raw email bodies are usually much longer than the customer's actual question. There can be five replies under the newest message, a signature, legal text in the footer, and an HTML version of the same email. Sending all into the model makes the prompt longer and gives the model more text to misread.
I pass the plain-text body into a Formatter step first. The first version used one regex to cut off the quoted reply. It worked for some mail clients and failed on others. Outlook users gave me the most annoying examples because the separator text changes between desktop, web, and mobile mail.
Stopped trying to find one perfect regex. I strip obvious signatures first, then remove common quoted-reply markers. If the cleaned result is empty, the message goes to human review instead of being sent through the AI reply path.
Customer message:
{{cleaned_email}}
Original subject:
{{subject}}
Sender:
{{from_email}}
I keep the original email available in the helpdesk ticket too. The cleaned text is for the model. The original message is for the agent.
The Prompt Is Shorter Than My First Version
My first prompt tried to describe every possible support rule in one block. It became hard to maintain and harder to debug. I now keep the instructions tight and move company policies into the context sent with the request.
You are the customer support assistant for [Company]. Read the customer message and return JSON with: category risk reply category must be one of: Billing Shipping Technical Support Feature Request Complaint Other risk must be one of: low review Set risk to review when the email includes: refund disputes legal threats account security issues requests for compensation claims of damage or loss unclear policy questions Write a short reply using only the supplied company information. Do not invent prices, timelines, refunds, guarantees, or policy details. If the supplied information does not answer the question, means support agent will verify it.
The output format is deliberate. I don't want Zapier searching through a paragraph to find “Billing” and then trying to guess where the reply starts. The current OpenAI API supports structured JSON output through JSON Schema, and that is a better fit for this kind of automation than relying on a parser to hunt for labels inside free text.
Inside Zapier, use the current ChatGPT (OpenAI) action. The old Assistant-based actions are being removed, so new builds should not depend on them.
I Keep the Knowledge Base Small on Purpose
Then I tested idea of dumping the support handbook into every request. It made the prompt harder to manage and pushed a lot of irrelevant text into the model. A billing question does not need the shipping policy, and a password reset email does not need the refund rules.
The Zap can choose the relevant block from a Google Sheet, Airtable table, Notion database, or another source your team already maintains.
Billing: Refund window: 14 days Refund requests after 14 days need agent review. Refunds go back to the original payment method. Shipping: Standard delivery: 3–5 business days Tracking link is sent after dispatch. Delayed shipments go to agent review.
This also gives the team one place to change a policy. If the refund period changes, I update the source once instead of editing a giant prompt in several Zaps.
The Reply Path and the Human Path
After ChatGPT returns the category, risk and reply, the Zap branches.
Low-risk billing, shipping, and basic technical questions can continue to the reply step. Complaints, legal language, account security issues, and unclear policy requests go to the review path.
Zapier Paths is built for this type of branching. Each path has its own rules, so the same incoming email can go to different actions based on the AI result and the original email content.
┌─ Low risk → Draft/Send Reply
Incoming Email ───→ AI
└─ Review → Helpdesk / Slack / Human Queue
I also check the raw email for words. A customer can write “billing” and still be threatening legal action. The model can call it Billing. My second check sees “lawyer” or “legal” and sends it to review.
I Prefer Drafts Before Full Auto-Reply
I do not turn on automatic sending on day one. The first stage creates a Gmail draft or helpdesk draft. An agent can open it, edit the wording, and send it.
Keep that mode long enough to inspect the same types of messages the live inbox receives. Ten clean test emails are not enough. I need replies with missing details, long thread history, angry wording, short messages like “still waiting,” and customers who change topics halfway through an email.
After that review period, low-risk categories can move to automatic sending. The review categories stay manual.
The Email Footer I Put on Automatic Replies
I tell the customer - the message was generated automatically and give them an easy way to reach a person. The wording is short:
This message was generated automatically from our support information. If it does not answer your question, reply to this email and a support agent will take over.
I send from the real support address. I don't use a no-reply address for this workflow because the whole point is to keep the conversation open.
Zapier's Gmail integration supports sending mail from connected Gmail accounts and can also work with aliases configured in Gmail.
The Review Ticket Contains the Original Message
For escalated mail, I create a helpdesk ticket with the original subject, cleaned message, category, risk flag, and the AI draft. The agent can see what the model saw and what it was about to send.
I also keep the original email in the ticket or link back to it.
If there is no helpdesk, the same data can go to a Slack channel or a dedicated Gmail label. I avoid sending these alerts into the same inbox that receives the customer mail because it gets noisy fast.
The Log to Check
The Google Sheet for the early version of the workflow. One row per message is enough to spot patterns.
- Time
- Customer email
- Category
- Risk
- Auto reply sent
- Escalated
- Agent edit made
The last field is the one I care about after the Zap has been running for a while. If agents keep rewriting the same kind of reply, the prompt or knowledge snippet needs work. If agents almost never edit shipping replies but often rewrite complaint responses, those two categories should not have the same automation rules.
What I Measure Before I Increase Automation
I track four numbers for the first batch of messages:
Correct category Safe reply Useful reply Human edit required
“Safe” and “useful” are separate checks. A reply can be factually safe and still be useless. “Please contact support” is safe. It also isn't much help if the email was asking where an order is.
I also look at the reasons agents edited a reply. The pattern tells me what to fix. Too formal means the writing instruction needs work. Wrong policy means the source context needs work. Wrong route means the path rules need work.
One Test Case I Always Include
I send an email that looks harmless at first: “My package has not arrived. I already contacted you twice. If this isn't resolved today I will contact my lawyer.”
A model can classify this as Shipping. The routing layer should still send it to a person because the email contains a legal escalation. This is why I never let the category alone decide if a message is safe to auto-send.
Another Test: The Policy Trap
I also test a customer asking for something the knowledge base does not answer. The correct response is not a guess. The model should say that a support agent needs to verify the request.
Remove the answer from the supplied support information and send the question again. If the model invents a policy, the Zap is not ready for auto-send.
The Token Problem Is Easier to Control This Way
The old approach of putting a whole support wiki into every request makes the system expensive and harder to update. Smaller category-specific context keeps the request focused.
There is another benefit. The team can see which policy text the model received for a reply. It makes a bad answer easier to trace later.
What I Do When the Model Returns Bad Data
If the AI response is missing a category, missing a reply, or returns invalid JSON, the Zap stops the send action and sends the message to human review.
I don't try to repair a bad support reply with another AI call automatically. That can turn one bad answer into two layers of generated text.
The recovery path is boring: keep the customer email, keep the failed AI output, create the review ticket, and let a person handle it.
One More Thing: Security
Support mail can contain order details, phone numbers, addresses, account information, and other private data. I keep the Zap limited to the fields the model actually needs. I also keep customer data out of places where the support team does not already work.
For account-security messages, I route to a human before the model generates a customer-facing reply. The automation can still tag the message and create the ticket. It just does not make the final decision.
The Workflow I Keep
Gmail ↓ Search / filter ↓ Clean message ↓ ChatGPT (OpenAI) ↓ Structured result ↓ Risk + keyword check ├── Low risk → Draft or Send └── Review → Helpdesk / Slack ↓ Log result
I started with a single AI reply step. The extra checks came from the test emails. That is the part I keep in production because support mail is messy and the customer only sees the final message.
When to Keep it as a Draft System
For a small support inbox with unusual questions, keep the workflow in draft mode. The AI can do the reading and writing while a person clicks Send.
Full auto-reply makes more sense for repetitive questions with clear answers: shipping status instructions, password-reset steps, invoice copy requests, business hours, and other cases where the answer comes straight from a stable knowledge source.
I would not automate refunds, legal complaints, account security, compensation requests, or policy exceptions without human review.
What This Workflow Is Really Good At
It handles the waiting time between the customer asking a common question and a human getting around to the inbox. A customer can receive a useful first reply quickly, while the harder messages wait in the human queue with the original message and the AI's work already attached.
The setup also gives the support team a record. When agents start editing the same kind of reply again and again, I can see where the workflow needs changing.
The AI does the repetitive reading and drafting. People stay in the parts of support where a wrong answer can cost trust, money, or a customer.