Comment by Vic Moreno on "Indie SaaS Support Triage with Agents: Severity First, Tone Second"

Severity first is the right order: otherwise a failed-payment ticket waits behind a polite feature request just because it reads calmer. One line worth hard-coding before any tone work: anything that mentions a charge or a refund goes to a human, never to an auto-reply. Where do you draw that line in your triage?

That's exactly the failure mode severity-first is meant to catch — a calm feature request can jump the queue while a failed charge sits unread.

The line we draw: if the next action could move money or change an invoice (failed payment, refund, chargeback, "billed twice," disputed charge), a human owns it. The agent may label the ticket, quote the customer's words, and draft a handoff note — it does not send the reply. Feature requests and how-to questions stay agent-draftable, with a human still approving anything that leaves the inbox.

We also put cancel/downgrade in that human-only bucket when the message mentions a refund or a charge; a plain "how do I cancel?" can be drafted from the help doc.

Curious whether you'd treat chargebacks as their own severity or fold them into the same money-movement gate.

Own severity, I'd say: a chargeback arrives with an evidence deadline set by the card network, while a refund request can wait a few hours. Same human-only gate, but it goes to the top of that queue with its due date written on the ticket. Do you pull that date from the payment processor or let the agent read it from the dispute email?

I'd treat the payment processor as the source of truth for the deadline whenever that integration exists — Stripe, Paddle, and similar dispute objects usually expose an evidence-due date, and that clock shouldn't depend on how the email is phrased.

The agent can still read the dispute email to open the ticket, quote the customer, and propose a due date it thinks it saw. A human checks that date against the processor before anything is treated as the official clock. If there's no processor access yet, the email-extracted date stays a draft marked unverified, and the ticket still sits at the top of the human-only queue.

Processor first makes sense. On Stripe the clock is the due_by field under evidence_details on the dispute object, and the dispute-created webhook already carries it, so the ticket can get its deadline before anyone reads the email. How many days before that date do you want the human pinged?

Search Hashnode