Support automation logo

Support automation

Project
0
by · 6 items · 2 flows · 4 resources anthropic github sendgrid slack

Support intake: Slack webhook to classified triage thread

Flow
Triggers (2) disabled on import
  • email Runs when an email is sent to the configured address. Re-register URL after import
    Email prefix
    support@…
  • http Slack Events API endpoint for the customer support channel. Point your Slack app's Event Subscriptions request URL at this route and subscribe to message.channels. The intake flow echoes the url_verification challenge via early_return, so the sync request type is required. For production, switch authentication_method to signature with a Slack signing-secret resource. Re-register URL after import
    Route
    POST /support_automation/slack_events
    Auth
    none

README

Support automation (minimal)

A minimal version of the AI + human-in-the-loop support automation described in Automating quality support at scale: a customer message, arriving from Slack or by email, is classified, triaged by AI, and answered on the channel it came from with a human-approved draft, while clear-cut fixes are dispatched in parallel.

How it works

Slack message ── HTTP trigger (slack_support_webhook) ──┐
Email ────────── email trigger (support_email) ─────────┤
                                                        ▼
  support_intake flow
    ├─ acknowledge          (early return: acks Slack, echoes url_verification)
    ├─ classify_message     (fast AI call: title, category, severity)
    ├─ open_triage_thread   (thread in the team triage channel)
    └─ trigger_post_processing  (async hand-off, never blocks new messages)
         └─ triage_post_processing flow
              ├─ analyze_ticket   (AI: root cause, draft reply, fix assessment)
              ├─ post_triage      (analysis + draft into the triage thread)
              └─ dispatch_parallel (branchall, parallel)
                   ├─ request_approval → check_approval → send_reply
                   │    (suspend: a human approves, edits or rejects; only then
                   │     does the reply go back where the customer wrote from,
                   │     Slack thread or email)
                   └─ dispatch_fix
                        (high-confidence clear-cut fixes become a labeled
                         GitHub issue, independent of the reply approval)

Two flows on purpose: intake is fast and always responsive, analysis is slow and runs async, so a long analysis never queues new incoming messages.

Try it without credentials

Every integration step has a demo mode: when its credential is empty (the default right after import), it logs what it would send and returns canned data instead of calling out. So you can run either flow immediately - for example triage_post_processing with just a message - watch every step go green, and approve the reply from the approval page URL printed in the pause for human approval step's logs. Fill in the resources below and the same steps switch to doing the real thing.

Setup

  1. Fill in the resources in this folder:
    • slack_bot: a Slack bot token (xoxb-...) with chat:write in the support and triage channels and channels:history for events.
    • anthropic: your Anthropic API key.
    • github: a token with issues:write on the fix repository.
    • sendgrid (email input only): a SendGrid API key for outbound replies.
  2. Set the variables:
    • triage_channel_id: channel id of your internal triage channel.
    • fix_repo: org/repo for auto-dispatched fix issues.
    • support_from_email (email input only): verified sender address for replies.
  3. In your Slack app, enable Event Subscriptions, subscribe to message.channels, and set the request URL to this workspace's route for support_automation/slack_events. The trigger answers the url_verification handshake automatically.
  4. Invite the bot to both channels.
  5. Email input (optional): the support_email trigger reserves the support local part, so mails to <workspace>-support@<your windmill email domain> flow into the same intake. Forward your public support address there. Approved replies are sent with SendGrid, threaded onto the customer's message via In-Reply-To.

What the full version adds

This is the skeleton of the system in the blog post. The production version replaces analyze_ticket with a sandboxed coding agent that has the codebase, the docs and the customer's telemetry mounted (that is what makes the root causes good), takes tickets from Discord too, hands clear-cut fixes to a coding agent that drafts the PR, pings the customer when the fix is merged and released, escalates unanswered tickets, and feeds approval edits back into the drafting prompt.