How to Automate Customer Service Email Triage for Shopify with n8n + Claude (2026)

Most stores have at least four inbound channels: a shared Gmail or Outlook inbox ([email protected]), a Gorgias instance receiving Shopify Inbox forwards, a WhatsApp Business number, and the contact form on the storefront. The first job is normalising every one of them into a single n8n webhook payload so the rest of the pipeline doesn’t care where the message came from.

Use n8n’s native Gmail trigger for the inbox, a Gorgias webhook trigger (configure it inside Gorgias under Settings → REST API → Add HTTP Integration), and a Twilio WhatsApp webhook for messaging. Each one transforms into the same canonical envelope:

{
  "channel": "gmail | gorgias | whatsapp | form",
  "external_id": "thread-or-message-id",
  "received_at": "2026-05-03T09:14:22Z",
  "from": {
    "email": "[email protected]",
    "phone": "+15551234567",
    "name": "Jane Buyer"
  },
  "subject": "Where is my order?",
  "body_text": "Hi, I ordered last Tuesday and...",
  "body_html": null,
  "attachments": [],
  "store_id": "shop-us-main"
}

De-duplicate aggressively. Buyers forward, reply-all, and CC themselves. Hash external_id + from.email in a Postgres table and skip anything you’ve seen in the last 60 seconds.

Before any classification, enrich the message with order context. Extract candidate identifiers from the body — order number (#1234, SHOP-1234), email, phone — using a small regex node, then query Shopify Admin GraphQL. Always GraphQL, never REST: REST is rate-limited per call (2/sec), GraphQL is rate-limited by query cost (50 points/sec) and you can fetch order, fulfillment, and refunds in a single trip.

query OrderContext($q: String!) {
  orders(first: 1, query: $q, sortKey: CREATED_AT, reverse: true) {
    edges {
      node {
        id
        name
        email
        phone
        createdAt
        displayFinancialStatus
        displayFulfillmentStatus
        totalPriceSet { presentmentMoney { amount currencyCode } }
        customer { id numberOfOrders tags }
        shippingAddress { city provinceCode countryCode }
        fulfillments(first: 5) {
          status
          trackingInfo { number url company }
          updatedAt
        }
        refunds(first: 5) {
          createdAt
          totalRefundedSet { presentmentMoney { amount } }
        }
      }
    }
  }
}

Pass q as email:[email protected] or name:#1234. If no order matches, set order_context: null and let the classifier handle it as a pre-purchase question.

For WooCommerce stores, swap the query for a GET /wp-json/wc/v3/orders?search=... call and merge the shape; for BigCommerce use GET /v2/orders?email=.... The classifier downstream doesn’t care which backend produced the context — only that the shape matches.

The classifier is the brain. We send Claude the message body plus a redacted order summary and ask for a single JSON object with a fixed enum of intents. No free-form output, no creative interpretation. The schema below is what we run in production.

You are a customer-service triage classifier for a Shopify store.
Return ONLY a JSON object matching this schema. No prose.

{
  "intent": "refund_return | shipping_tracking | product_question
           | sizing_fit | defective_damaged | lost_order
           | change_address | cancel_order | fraud_suspect | other",
  "confidence": 0.0-1.0,
  "sentiment": -1.0 to 1.0,
  "urgency": "low | normal | high | critical",
  "language": "ISO-639-1",
  "requires_human": boolean,
  "rationale": "max 30 words, plain English"
}

Rules:
- If order_context.totalPrice > 500 USD, set requires_human = true.
- If sentiment < -0.4, set requires_human = true.
- If intent = fraud_suspect, ALWAYS requires_human = true.
- If confidence < 0.85, set requires_human = true.
- Never invent order numbers, tracking numbers, or refund amounts.

Use Claude Sonnet for this — Haiku is too literal with sentiment, Opus is overkill at the volume. Pin the model version (claude-sonnet-4-7@20260301 or whichever is current) and treat it like a contract. Schema drift will silently break your downstream branches.

Validate the JSON output with a strict schema before routing. If parsing fails (it will, occasionally) fall back to requires_human=true, intent=other and let a human triage it.

For every intent with confidence ≥ 0.85 and requires_human = false, generate a personalized reply that cites the actual order. The trick is to compose the reply from two layers: a hand-written template per intent, and Claude's job is to fill the slots — not to write English from scratch.

{
  "shipping_tracking": {
    "subject": "Your order {{order.name}} — tracking update",
    "body": "Hi {{customer.firstName}},nnYour order {{order.name}} shipped on {{fulfillment.updatedAt | date}} via {{fulfillment.company}}. Tracking: {{fulfillment.trackingNumber}}nnLatest status from the carrier: {{carrier.status}} (ETA {{carrier.eta | date}}).nn{{closing}}",
    "max_confidence_required": 0.90
  },
  "refund_return": {
    "subject": "Return for order {{order.name}}",
    "body": "Hi {{customer.firstName}},nnYour order was placed on {{order.createdAt | date}}, which is {{daysSincePurchase}} days ago. Our return window is 30 days, so you're {{returnEligible ? 'eligible' : 'past the window'}}.nn{{instructionsBlock}}",
    "max_confidence_required": 0.92
  }
}

For shipping queries, do a parallel call to the carrier API (EasyPost wraps UPS, USPS, FedEx, DHL behind one endpoint) so the reply contains a live status, not a stale "shipped on Tuesday." For refunds, compute eligibility against the return window in n8n — never let the LLM decide policy.

Anything flagged requires_human = true goes to Gorgias as a new ticket with a structured internal note. The note is the difference between a 12-minute resolution and a 4-minute one — give the agent everything they would have looked up themselves, plus a draft reply they can accept, edit, or discard.

POST https://YOURSTORE.gorgias.com/api/tickets
Authorization: Basic {{base64(email:apikey)}}

{
  "channel": "email",
  "from_agent": false,
  "customer": {"email": "{{from.email}}"},
  "subject": "{{subject}}",
  "tags": ["ai-triaged", "{{intent}}", "urgency-{{urgency}}"],
  "messages": [{
    "channel": "email",
    "from_agent": false,
    "sender": {"email": "{{from.email}}"},
    "body_text": "{{body_text}}"
  }],
  "meta": {
    "ai_intent": "{{intent}}",
    "ai_confidence": "{{confidence}}",
    "ai_sentiment": "{{sentiment}}",
    "order_name": "{{order.name}}",
    "order_total": "{{order.totalPrice}}",
    "lifetime_orders": "{{customer.numberOfOrders}}",
    "suggested_reply": "{{draftedReply}}"
  }
}

Route by intent: fraud and chargebacks to a dedicated reviewer, sizing/fit to the merchandising team if you have one, the rest to general queue. Use Gorgias' "rules" engine to enforce SLAs based on the urgency tag.

Every resolved ticket pushes a custom event into Klaviyo. This event is the trigger for win-back flows after refunds, post-purchase NPS asks after happy resolutions, and a "we've fixed it" check-in 7 days after a defective-product replacement. The event payload should be lean and queryable.

POST https://a.klaviyo.com/api/events/
Authorization: Klaviyo-API-Key {{KLAVIYO_PRIVATE_KEY}}
revision: 2026-04-15

{
  "data": {
    "type": "event",
    "attributes": {
      "metric": {"data": {"type": "metric", "attributes": {"name": "CS Ticket Resolved"}}},
      "profile": {"data": {"type": "profile", "attributes": {"email": "{{from.email}}"}}},
      "properties": {
        "intent": "{{intent}}",
        "outcome": "{{outcome}}",
        "resolved_by": "{{ai|human}}",
        "first_response_seconds": {{firstResponseSeconds}},
        "order_name": "{{order.name}}"
      },
      "time": "{{resolvedAt}}"
    }
  }
}

In Klaviyo, build flows that branch on the intent property: refund_return triggers a 14-day win-back; defective_damaged triggers a quality-assurance follow-up; shipping_tracking + resolved_by=ai goes into a "first-time positive AI experience" segment for the brand team to tag. Respect email_consent — Klaviyo enforces this, but n8n should pre-check before the POST to avoid wasted API calls.

Common failure modes and how we caught them in production

Every team building this hits the same six bugs. Here is the short list, ordered by how much money they cost before we noticed.

Privacy & compliance — the non-negotiables

A customer-service pipeline touches PII on every execution. The compliance regime depends on where your buyers live, but four standards always apply.

Anthropic's API does not train on your inputs by default, but log retention is 30 days. If your DPA requires zero retention, request the zero-data-retention amendment before go-live. Klaviyo's consent rules are stricter than the law in most jurisdictions — never push events for un-consented profiles.

Results — what a 12-month rollout looked like

Numbers from a US-based apparel brand running roughly 800 inbound tickets per week across Shopify Plus, Gorgias, and WhatsApp Business. Twelve months from go-live.

The refund-cost number is worth dwelling on: proactive shipping updates (Step 4) intercepted enough "where is my order" panic to suppress a measurable share of speculative chargebacks.

Four-week implementation timeline

Frequently asked questions