support-followup

name

support-followup

description

Track open support tickets and chase the ones that have gone quiet. Lists what is outstanding across every vendor with how long each has been waiting against the response time the vendor committed to, drafts a chase that quotes that commitment back rather than asking "any update", walks the registry's escalation ladder when the window has passed, and closes tickets out — recording the resolution and folding what was learned back into the service entry. Use when the user asks what tickets are open, whether support ever replied, how long something has been waiting, how to escalate, or to chase, nudge, or close a case.

support-followup

Tickets are not answered because they are filed. They are answered because someone is counting.

Modes

The user's phrasing picks one:

• Status — what is open, what is overdue. Default when nothing else is clear.
• Chase — draft a follow-up on a specific ticket.
• Escalate — the window has passed; work the ladder.
• Close — it resolved; record the outcome and harvest what it taught.

Status

ls -1 ~/.claude-plugins/contact-support/tickets/*/*.md 2>/dev/null

Read the front matter of each. Report only what is actionable, newest first:

Field	Read as
status: open, response_due in the past	Overdue. The number of days matters and belongs in the report.
status: open, response_due future	Waiting. Say when it comes due.
status: awaiting-user	The user is the blocker. Lead with these — an unanswered request for information is a stalled ticket that looks like the vendor's fault.
status: resolved / abandoned	Omit unless asked.

Group by service. Against each overdue item, name the committed window from the registry and the first step of escalation[], so the report ends in an action rather than an observation.

Nothing open: say so in one line.

Chase

1. Establish the facts before writing

Read the ticket log. Then check whether the silence is real: a reply may have arrived in email outside the log, or the ticket may be awaiting-user and waiting on the user. Chasing a desk that already answered is a bad look and costs standing that matters later.

2. Compute the elapsed time honestly

Against the vendor's window, in the vendor's business hours from the channel's hours. Twenty working hours over a weekend is not overdue against a nine-business-hour commitment. Getting this wrong and asserting a breach undermines the escalation that follows.

3. Draft

Reply on the existing thread. Never a new ticket.

A chase must add something. The strongest form quotes the vendor's own commitment:

This is priority "degraded service" on the Production plan, where the committed first response is 6 business hours. It has now been 31 business hours. Please escalate.

Weaker but valid additions, in order of usefulness: a new occurrence with fresh timestamps, a narrowing of the cause, a widening of impact. Any update? adds nothing and is trivially deprioritised.

Keep it short. The original ticket has the detail; this message exists to restart the clock.

Then hand to support-send, which will confirm before anything goes out.

Escalate

Work escalation[] in order. The steps are conditional — apply the one whose after condition is actually met, and do not skip ahead because the situation feels urgent. Skipping to the escalation line on a first miss spends leverage that is needed later.

Common rungs and what each needs:

• Escalation request on the thread. The elapsed time and the committed window, stated as fact.
• Chat or phone with the ticket number in hand. The aim is to get the existing ticket escalated, not to restate the problem to a new person.
• An SLA credit claim. Usually time-barred — Twilio's is 30 days from the end of the month in question. Check the deadline before anything else, because a missed window forfeits the remedy entirely, and tell the user the deadline even if they decide not to claim.
• Sales or the account team. When the blocker is commercial rather than technical. Often faster, because the account team owns the outcome the support queue does not.
• A public channel. Last, and only with the user's explicit agreement, understanding that it is permanent and public. Identifiers never go into it. It works on some vendors and burns goodwill with others; say which this looks like if the entry's gotchas know.

If the ladder is exhausted, say so plainly and lay out what remains — a chargeback, a regulator, a migration off the vendor. Do not pretend there is another rung.

Close

1. Append the resolution to ## Correspondence, with the date.

2. Fill ## Outcome: what fixed it, who fixed it, and the real elapsed time from filing to resolution.

3. Set status: resolved.

4. Harvest the entry. This is the step that makes the plugin worth having:

   • Real first-response time versus the published window → gotchas, if they diverge.
   • A queue that bounced the category → not_for on that channel.
   • A field the form demanded → required_fields.
   • An address that bounced → known_dead, with the date and what worked instead.
   • A check that would have avoided the ticket → before_you_contact.
   • A faster route discovered by accident → reorder channels[].

   Write these into ~/.claude-plugins/contact-support/services/<slug>.json. If the finding is about the vendor rather than about this user's account, it also belongs upstream in the shipped entry — say so, so it can be contributed.

5. Record what changed under ## Registry changes made as a result.

Guardrails

• Never open a duplicate ticket. Every mode here operates on the existing thread.
• Never assert a breach of a commitment without computing it in the vendor's business hours.
• Do not chase daily. Chasing faster than the vendor's window is noise and it trains the desk to ignore the account.
• Never escalate to a public channel without explicit permission, and never with identifiers in it.
• Do not close a ticket the user has not said is resolved. A last reply from the vendor is not agreement that the problem went away.