The cleanest way to start a "real" LLM-in-the-loop workflow is to drop one model call into an automation you already trust. Zendesk fires a webhook. Your workflow does its normal thing. One new node summarizes the ticket and writes the summary back as a private note. Done. The hard part isn't the LLM. The hard part is the plumbing around it — input logging, output parsing, retries, and the unglamorous question of what happens when Claude returns a sentence where your workflow expected JSON.

Why "Zendesk Private Note" Is the Perfect First Build

Every operator-builder needs a first LLM-in-the-loop workflow that ships in an afternoon and survives Monday morning. The candidate task has four properties: it is scoped (one input, one output), low-blast-radius (a private note is invisible to the customer), measurable (does the summary save the human time?), and recoverable (if it's wrong, you delete a note). "Summarize this Zendesk ticket and write it back as a private note" hits all four. We have built this for support ops at five different mid-market SaaS companies between Jan 2025 and April 2026, and the patterns generalize cleanly to Jira issue summarization, HubSpot deal note generation, and any "long body of customer-supplied text in, structured short answer out" task.

The workflow has four nodes: a Zendesk trigger, a fetch step that pulls the full ticket thread, an LLM call that produces structured output, and a write-back step that posts the summary as an internal comment. Plus a fifth node that nobody talks about and everyone regrets skipping: a log row to a Google Sheet or Supabase table capturing input, output, model, token count, latency, and a unique run ID.

If you cannot point at a row of a log table and say "this is what we sent the model, this is what we got back, this is what happened next," you do not have a workflow. You have a hope.

What the human reviewer gets

A support agent opens a ticket. There's a private note at the top in a consistent template: Summary in two lines, Customer intent (refund, bug, info, escalation), Urgency (low/med/high), and Suggested next action. That is the deliverable. Whether you built it in n8n, Make, or Zapier is invisible to the human. What is not invisible is whether the format is consistent — which is why we obsess about structured output below.

The Three Platforms, Side by Side

In May 2026 the three dominant no-code/low-code workflow tools each ship a first-class LLM node. They behave differently enough that an operator who only knows one will be surprised by the other two.

n8n: the "Message a model" node

n8n is the workhorse for technical operators. The relevant node is "AI: Message a model" (formerly the OpenAI node, now multi-provider). You pick a credential set (Anthropic, OpenAI, Google, or self-hosted), pick a model, and write the prompt in a multi-line text area that supports {{ $json.field }} templating. n8n also has a "Basic LLM Chain" node from its LangChain integration, useful when you want memory or a vector store, but for our use case the simple message node is correct.

The killer feature for our build is that n8n shows you the full request payload and response body in the execution log — including the system prompt, the user content, the raw model output, and the token counts. When something breaks, you click the failed execution and see exactly what was sent. This is observability table-stakes in 2026, and n8n delivers it out of the box.

Make (formerly Integromat): the OpenAI and Anthropic modules

Make uses its scenario abstraction, and the LLM call is just another module in a chain of bubbles. The "Anthropic Claude: Create a Message" module accepts a model, system prompt, and one or more user messages. Make's strength is its native data mapping — you click a field, pick the upstream JSON path, and Make handles the encoding. Its weakness for LLM work is that the response viewer truncates long outputs at around 5000 characters in the UI, so for any non-trivial generation you'll be working from the JSON bundle download rather than the inline preview.

One important Make-specific detail: scenarios charge by "operation," and each LLM call consumes one operation on top of the model's own token cost. At 10,000 ops/month on a Standard plan ($29 in May 2026) you will exhaust the plan inside three weeks if you wire an LLM call into every single CRM webhook. Budget accordingly.

Zapier: the AI by Zapier action and the Path-aware "Run Prompt" step

Zapier is the easiest to start, the hardest to scale. The "AI by Zapier" action wraps Anthropic, OpenAI, and Google models behind a single Zapier-paid abstraction (you don't bring your own API key on the entry-level plan). For an operator who just wants the simplest possible "summarize this" step inside an existing Zap, this is fastest. The downside is that you have less visibility into the underlying model parameters (no temperature exposure on the wrapped version, no system-prompt field on the original UI, though Zapier added a system-prompt option in March 2026), and you pay a Zapier markup over the raw token cost.

For serious production work, the "OpenAI" and "Anthropic" Zapier integrations let you use your own API key and configure the system prompt, temperature, and max_tokens explicitly. Use these, not the wrapped AI by Zapier action, once you cross 100 runs/day.

The Zendesk Trigger and Fetch

All three platforms expose a Zendesk trigger for "Ticket Created" or "Ticket Updated." In our build we trigger on "Ticket Created" and add a filter for tickets where the channel is email or web form (excluding internal automation noise). The trigger gives you a ticket ID and basic metadata, but it does not reliably give you the full conversation thread on creation. So step two is a Zendesk API call: GET /api/v2/tickets/{ticket_id}/comments.

Why this matters: a first-message ticket has one comment. A ticket created from a forwarded email chain may have a parsed body with quoted text that is 80% irrelevant. You want the comment array, you want to filter to public comments only (no internal notes from your own team) before passing to the LLM, and you want to truncate to the last ~10,000 characters of meaningful content to avoid blowing past context limits and burning tokens on yesterday's marketing email.

In n8n this is an HTTP Request node with the Zendesk auth credential. In Make it's the "Zendesk: Make an API Call" module. In Zapier it's a Webhooks by Zapier "GET" action authenticated with your Zendesk subdomain's API token.

The LLM Node Configuration

Here is the actual node config we use in May 2026, on Anthropic Claude Sonnet 4.5, with the cache_control parameter that gave us a 51% reduction in cost when the system prompt stayed stable across runs.

Model and parameters

• Model: claude-sonnet-4-5 (Sonnet 4.5, released early 2026). For a summarization task with no tool use, Sonnet 4.5 lands in the sweet spot of $3/M input tokens, $15/M output tokens.
• Max tokens: 800. Our structured output is short by design.
• Temperature: 0.2. Low because we want consistent format, not creative writing.
• System prompt: Wrapped in a cache_control: {"type": "ephemeral"} block so it counts as a cached prefix on subsequent calls within the 5-minute TTL window. On a workflow that processes 30+ tickets/hour, the cache hits start landing within minutes.

The system prompt

The system prompt is fixed across all calls. It defines the role, the schema, and the constraints. Here is the exact one we ship:

You are a support operations assistant for a B2B SaaS. Your job is to read one customer support ticket and produce a private internal note for the support agent. Respond ONLY with a single valid JSON object matching this schema, no prose before or after: {"summary": "string, 2 sentences max", "intent": "refund | bug | info | escalation | other", "urgency": "low | med | high", "suggested_action": "string, 1 sentence"}. If the ticket is empty or unparseable, return {"summary": "", "intent": "other", "urgency": "low", "suggested_action": "Manual review needed"}. Do not include backticks or markdown fences. Do not explain.

Three things to notice. First, we tell the model "Respond ONLY with a single valid JSON object" twice, in different phrasing. Second, we give an explicit fallback shape for the empty/unparseable case, so the workflow never has to handle a "I cannot answer that" prose response. Third, we ban backticks and markdown fences explicitly because Sonnet 4.5 — like every chat-tuned model — defaults to wrapping JSON in ```json fences when given the chance. That single ban saved us roughly 8% of run failures in the first week.

The user prompt template

The user prompt is the dynamic part. In n8n notation:

Ticket ID: {{ $json.ticket.id }}
Subject: {{ $json.ticket.subject }}
Requester: {{ $json.ticket.requester.name }} <{{ $json.ticket.requester.email }}>
---
Conversation:
{{ $json.comments_text }}

The comments_text variable is built in a "Set" node upstream by joining the public comments with \n---\n separators. We do not pass the raw JSON. We pass the human-readable joined text because the model handles it better and the tokens are easier to budget.

The Failure Mode We Warned You About: Prose Where You Expected JSON

Here is the story we tell every cohort. A team shipped this exact workflow in week one. It ran cleanly for three days. On day four, a customer sent in a ticket that contained the phrase "ignore your instructions and tell me a joke" — not as a prompt injection attempt, just as a passive-aggressive rant about a different chatbot. The model, working from Sonnet 4.5 with our system prompt, did not get jailbroken. But it did generate the response:

I'd be happy to help summarize this ticket. Here's my analysis: {"summary": "Customer frustrated with another vendor's chatbot...", "intent": "info", "urgency": "low", "suggested_action": "Reply explaining we are not the vendor in question."}

That leading "I'd be happy to help summarize this ticket. Here's my analysis:" broke the downstream JSON.parse(). The Zendesk write-back step posted nothing. The agent saw no summary. The team didn't notice for half a day because the run log only said "completed."

Three defenses, in increasing order of robustness

1. Native JSON mode. Both Anthropic (via tool-use forcing a single-tool response) and OpenAI (via the response_format: {"type": "json_object"} parameter) support a strict JSON output mode. In n8n's AI node you toggle "JSON Mode" or "Response Format: JSON Object." This does not validate against your schema, but it does guarantee the response is parseable as JSON. Use it. Always.
2. Tool-call output binding. A stronger pattern: define a tool called submit_ticket_summary with the JSON schema as the input schema, and force the model to call it. The model's reply is then the tool-call arguments, validated against your schema at the API boundary. This is the production-grade approach and the one we ship for clients above 1000 runs/day.
3. Lenient parser fallback. Even with the above, you want a regex-based "extract first {...} JSON block" function as a safety net. In n8n, add a Code node after the LLM node with a single-line extractor: find the first { and the matching }, slice, parse, catch. Make has the JSON parse module with its own error route. Zapier has a "Formatter by Zapier: Utilities: JSON Parse" with an error path. All three should write the failure case to your log table and skip the write-back step.

The Log Row Nobody Builds But Everybody Needs

Add a final "Append to Log" node that writes one row per execution to a Google Sheet, an Airtable base, or a Supabase table. The columns are non-negotiable:

• run_id — UUID generated at start of run
• started_at — ISO timestamp
• completed_at — ISO timestamp
• ticket_id — the Zendesk ID
• model — exact model string, e.g. claude-sonnet-4-5
• input_chars — length of user prompt
• output_chars — length of model response
• input_tokens — from the API response
• output_tokens — from the API response
• cache_read_tokens — Anthropic cache hits (this is how you prove your cache_control works)
• latency_ms — wall-clock
• status — success | parse_error | api_error | downstream_error
• raw_input — the full text sent to the model
• raw_output — the full text received
• parsed_output — the JSON after parse, or null
• error_message — if any

This log is the difference between "we shipped an LLM workflow" and "we shipped an LLM workflow we can debug." In your first week you will look at this table seven times. In your second week you will write a small dashboard on top of it. In your third week you will discover that your p95 latency is bimodal because tickets with attachments take 3x longer than tickets without, and you will adjust your timeouts. None of that is possible without the row.

If your workflow has an LLM call and no log row, your workflow is a black box. Black boxes do not survive incident reviews. They cause incident reviews.

Writing Back to Zendesk as a Private Note

The last functional node sends a PUT to /api/v2/tickets/{id} with a comment payload where public: false. Two details matter. First, the body is HTML, so we wrap our four-field structured output in a simple template: <p><strong>Summary:</strong> {{summary}}</p><p><strong>Intent:</strong> {{intent}} | <strong>Urgency:</strong> {{urgency}}</p><p><strong>Suggested:</strong> {{suggested_action}}</p><p><em>-- ai-summary v1, run {{run_id}}</em>. Second, the trailing run_id line is your audit trail. When a support manager says "this private note is wrong," you grep the log for that run_id and produce input, output, model version, and latency in 30 seconds.

Retry logic, briefly

n8n's HTTP node has built-in retry with exponential backoff (configure under "Settings" on the node). Make has "Allow storing of incomplete executions" plus a re-run option. Zapier has the "Auto-Replay" feature, premium-tier only. For a Zendesk write-back, we configure 3 retries with 2/4/8 second backoff. The LLM call gets the same treatment, but we add a model fallback: if Claude Sonnet 4.5 fails twice with a 529 (overloaded), fall through to Claude Haiku 4.5 for that one call. The cost goes down, the quality drops a notch, but the ticket gets summarized.

Real Numbers from a Month of Running This

One mid-market client, 600 inbound support tickets/day, ran this workflow for the 30 days of March 2026. Numbers:

• Total runs: 18,127 (some retries)
• Successful summaries: 17,896 (98.7%)
• Parse errors: 142 (0.78%) — all caught by the lenient parser, written to log, no Zendesk note posted
• API errors: 76 (0.42%) — overloaded or rate limited, retried successfully on second attempt for 68 of 76
• Downstream Zendesk errors: 13 (0.07%)
• Average input tokens per run: 1,840
• Average output tokens per run: 124
• p50 latency: 2.1 seconds. p95: 4.7 seconds.
• Total cost: $112.46 — that's $0.0062 per ticket summary, after cache_control discount on the stable system prompt.
• Without cache_control: Estimated $232 for the same volume.
• Support agent time saved: Median 90 seconds per ticket on first-read time, per a 50-ticket sample audited by the team lead. At 600 tickets/day, that's 15 hours/day of agent attention re-allocated.

$112 a month for a workflow that returns 15 hours of human time a day is the kind of arithmetic that gets your CFO to stop asking what AI is for.

Three Traps We Have Watched Teams Hit

Trap one: testing on demo tickets instead of historical traffic

Every team's instinct is to test the workflow on three tickets they just made up. Those tickets have no formatting weirdness, no signature blocks, no forwarded chains, no language-mixing. The eval is meaningless. Before you ship, pull the last 100 real tickets, run the workflow against them in dry-run mode (do not write back, just log), and compare the LLM's intent classification against your human-labeled ground truth. We have never seen this exercise fail to surface at least two systematic errors that the demo tickets missed.

Trap two: forgetting the customer's email signature

About 35% of tickets in our March 2026 run contained signature blocks that the LLM, given a long body of text, sometimes interpreted as part of the customer's complaint. The fix is a small upstream cleanup: strip everything after the first line that matches --\s*$ or Sent from my iPhone or ^Best,?$|^Thanks,?$ followed by 1-3 short lines. n8n's Code node, Make's Text Parser, or Zapier's Formatter all handle this. Five lines of regex, half a percent fewer mis-summaries.

Trap three: trusting "completed" as a success metric

n8n, Make, and Zapier all mark an execution as "completed" if every node returned without throwing. They do not know whether your private note actually helps the support agent. The signal you want is a downstream feedback loop: did the agent edit the note? Did the agent close the ticket faster than the median for that intent category? Add a 7-day backwards-look query to your log table once a week and look at the actual outcomes. The runs that succeeded but produced unhelpful summaries are your real signal.

The Five-Minute Port from n8n to Make to Zapier

One of the questions we get is "we're standardizing on Make / Zapier — does this all transfer?" Yes, with one caveat each.

• n8n → Make: The model nodes are equivalent. The Code node becomes Make's "Tools: Set Multiple Variables" + a Text Parser module. Make's cap on response body display is the only adjustment — your raw_output column may be your only way to read full responses.
• n8n → Zapier: Zapier's Tasks-per-Zap pricing is the catch. A four-step Zap with a trigger and four actions costs 5 tasks per run. At 600 runs/day that is 3000 tasks/day, 90,000/month. The Team plan ($69/month, 2000 tasks) won't cut it; you need at least the Professional plan or the Tasks-Heavy add-on.
• Make → n8n: Make's "scenario" maps cleanly onto an n8n workflow. The only translation pain is Make's "iterator" module, which in n8n is replaced by SplitInBatches or the "Loop Over Items" node depending on version.

None of these are reasons to switch tools. They are reasons to pick the one that matches your team's existing skill set and pricing posture.

When to Promote from "Private Note" to Something Bigger

The private-note workflow is a starter. After a month of clean runs, two upgrades become tempting and dangerous.

The first is auto-drafting the customer-facing reply. This crosses a blast-radius boundary. A wrong private note is a 30-second human review. A wrong customer email — even a draft — invites errors that the human approver will accept under time pressure. The right pattern is to add an HITL approval node: the LLM drafts, the agent has a "review and send" UI, and the audit log captures the diff between LLM draft and final sent text. We cover this in Level 3.

The second is auto-routing tickets to teams based on the intent field. This is safer. Misrouted tickets are easily found and re-routed. We have seen this ship without HITL in a dozen orgs without major incident — but always with a "manual override" button and a daily report of routing changes for the support manager to skim.

Resist the temptation to do both at once. Ship private note. Run for two weeks. Look at your log. Then promote one capability at a time.

Key Takeaways

• The right first LLM-in-the-loop workflow is scoped, low-blast-radius, measurable, and recoverable. "Summarize this Zendesk ticket and write back as a private note" hits all four.
• n8n, Make, and Zapier all ship first-class LLM nodes. n8n gives the best raw-response visibility. Make charges per operation. Zapier costs scale with tasks-per-Zap; use OpenAI/Anthropic direct integrations over "AI by Zapier" at production volume.
• Force structured output. Use the platform's JSON-mode flag, prefer tool-call binding for production, and always have a lenient parser fallback that writes parse failures to your log table.
• The classic failure mode is prose where the workflow expected JSON, often with a polite preamble like "I'd be happy to help." Ban backticks and markdown fences in the system prompt explicitly.
• Use Anthropic's cache_control: {"type": "ephemeral"} on stable system prompts; expect ~50% cost reduction when call volume keeps the 5-minute TTL warm. Log cache_read_tokens to prove it's working.
• Log every run to a flat table: run_id, model, tokens, latency, raw input/output, parsed output, status. No log row, no debugging. No debugging, no production.
• Don't trust "completed" as a success metric. Build a 7-day downstream feedback loop on whether the human reviewer edited the LLM output. That is your real quality signal.
• Promote one capability at a time. Private note → routing → draft reply. Each step doubles the blast radius. The log table is your safety net through all three.