Business Ops

Support Triage

An always-on support-inbox triage that investigates every ticket against your real stack, replies or escalates, and turns tickets into product signals and eng fixes.

Advanced setupShort cycleOpen loopVisible first run

Create directly in Loopany

How a run flows

Before first run

Connect inbox + stack

Always on

Hourly · gated

Step 1 · Investigate

Root-cause first

Step 2 · Resolve

Reply or escalate

Step 3 · Capture

File the signal

Fix agent · isolated worktree

Step 4 · Fix

Fix real bugs

Board

Ticket board

Metric

Auto-handled per run

open loop — repeats on the next tick, picking up where it left off

How this loop works

Suggested schedule: Always-on (polls for new messages)
Loop type: Open loop — an ongoing monitor with no finish line.
Exit condition: Runs indefinitely (no finish line).
Notifications: On by default — you're alerted on each run's outcome (completion or failure). Silence with notify: never.
Ease of starting: A guided, multi-step setup (access, accounts, rules) before it can run.
When you see value: Heavy wiring up front (inbox + debugging stack); once connected, the first run triages real tickets.

The prompt this runs

Set up a support-triage loop for this business. Setup is a guided conversation in four steps - confirm each step with me before creating the loop; never create a blind loop.

## Step 1 - The support source
- Ask where customer support actually lives: Intercom, Zendesk, Plain, a shared email inbox, Discord.
- Verify this machine can really work it: fetch recent conversations once as a smoke test, and confirm WRITE ability too - posting a reply, leaving an internal note, setting tags/metadata. A triage loop that can only read is half a loop.
- If no skill for that support system exists on this machine, set one up (install one, or author a small skill wrapping fetch / reply / note / tag) so any session can drive it. Never bury access know-how in the loop folder - it syncs to the shared dashboard.
- If fetching is mechanical, add a deterministic workflow pre-stage: poll for genuinely new customer-authored messages on a persisted cursor and wake the agent only then; bot-only and canned-button noise stays a silent tick.

## Step 2 - The debugging stack
- To resolve issues rather than sympathize, the loop needs the systems your team debugs with. Ask what exists and verify read access to each: product database (read-only role), billing (e.g. Stripe), product analytics / session replay (e.g. PostHog), CRM, deploy or error logs.
- Smoke-test each; where a system has no skill yet, set one up the same way (access method, correct metric definitions, known gotchas).
- Standing triage rule: investigate root cause in these systems BEFORE any reply.

## Step 3 - Contract and boundary
Pull a handful of recent support threads and PROPOSE, from real examples:
- The per-request triage process: investigate first, capture signal, convert where natural.
- The reply boundary: what the loop may answer directly (vetted how-tos, verifiable product facts, honest status updates) versus what is drafted and HELD for human approval - anything that moves money (refunds, credits, plan changes), account deletion, legal or sensitive territory, novel or accusatory wording. Internal notes are always safe.
- The ticket knowledge base: reuse one if it exists, otherwise create one markdown note per conversation whose front-matter `type` is its stage - needs_human | needs_followup | resolved (no note for bot-handled noise). Every note ends with a deep link back to its source thread so a human can open the real conversation in one click. Fetch the template reference (see Step 4) before writing the first note - it carries the exact artifact contract.
- Escalation format: decision-first - ONE sentence carrying enough context to decide on the spot, ending in the bolded question with options; deeper background stays in the note.

## Step 4 - Outputs
- Default per run: handle the window's requests, file or update ticket notes, roll recurring themes into frequency-counted product-signal notes, and file eng-bug notes for real defects (optionally spawning a fix agent that root-causes in a fresh worktree outside the loop folder and opens a verified PR - never merges). Ask me whether more outputs are wanted.
- A run that actions something writes one dated report with front matter `type: report`, a `title`, and `date`; a quiet run is a single log line.
- Report per-run metrics: tickets awaiting a human, new conversations, auto-handled, open product signals, open eng bugs.
- Never copy credentials or personal data into reports.
- Dashboard at creation: fetch this template's reference at `<server-url>/api/skill/references/templates/support-triage/reference.md` (on demand - it is not in this prompt). It holds a validated dashboard layout (tabbed ticket/signal/eng boards + metrics rail + newest-report embed) and the metric state schema. The layout is a reference, not a mandate: keep its overall shape unless the user wants something else, substitute the vocabulary agreed in Step 3, and declare the metric keys so runs report them from day one.

This is the exact intent appended to the bootstrap when you create the loop — your coding agent reads it, then proposes cadence and config and confirms with you before creating anything.