Support

Write an internal escalation note handing a ticket to a developer

An internal, non-customer-facing prompt for summarizing a ticket into something a developer can act on without re-reading the whole thread.

Works with Claude / GPT1,100 uses 4.3

The prompt

support-escalation-note-to-developer
A support ticket has been going back and forth for 3 days. The customer's
description evolved across replies and the real issue is now clear, but buried
across 6 messages.

TICKET SUMMARY SO FAR: [customer on PHP 8.1, WooCommerce 8.2, reports that
scheduled discounts stop applying at checkout exactly at midnight local time,
reproduced by support on a test site by setting a discount to expire "today" and
watching it fail 40 minutes before actual midnight; looks like a timezone
handling bug, not a caching issue as first suspected]

Write the internal escalation note handing this to the developer on-call, not a
customer-facing reply.

Requirements:
- Lead with the current best understanding of the bug in one sentence (timezone
  handling, not caching), and flag explicitly that this reverses an earlier
  assumption in the thread, so the developer doesn't waste time chasing the
  original, wrong, caching theory.
- Give exact repro steps as verified by support, with environment details (PHP,
  plugin/WooCommerce versions), not "customer says it's broken."
- State customer impact and urgency honestly: how many customers likely
  affected, not just this one, and whether it's actively costing sales, versus an
  edge case, so the developer can weigh priority correctly rather than the
  agent's tone doing it for them.
- Note what the customer has already been told to expect (a timeframe, if one
  was given) so the developer knows what promise they'd be keeping or breaking.
- Skip pleasantries. This is an internal note, not a message to the customer.

Replace the TICKET SUMMARY SO FAR block with your real ticket details before
running this.

Flagging that the caching theory was wrong, explicitly, saves a developer from re-verifying an assumption support already ruled out. State the customer-facing promise that’s already been made, since that’s often the detail that gets lost between a support thread and a developer’s ticket queue.