Ranking causes by what you’ve actually seen in tickets, not by what seems most technically likely, is what makes the article resolve real cases fast instead of reading like a generic checklist. Naming the edge case where the standard fixes won’t work matters too, sending someone through the same four steps twice just erodes trust in the article itself.
Support
Turn a resolved, recurring support ticket into a public FAQ article
A scenario prompt for converting a pattern you keep answering in tickets into a self-serve FAQ, written in the actual language customers use.
Works with Claude / GPT700 uses★ 4.2
The prompt
support-recurring-ticket-to-faq
Over the last month, 30+ tickets have asked some version of the same question:
"After updating, I see a white screen and can't access my site or wp-admin at
all. Nothing else changed, I only clicked update."
You've resolved every one of these the same way: it's almost always a PHP memory
limit or a conflicting plugin surfacing on activation, not the update itself
being broken.
Write a public FAQ / knowledge base article addressing this.
Requirements:
- Use the title a panicked customer would actually search for ("White screen
after updating [Plugin Name]"), not an internal-sounding title like "WSOD
Troubleshooting."
- Open with the two most common causes, ranked by actual frequency seen in
tickets (memory limit first if that's genuinely more common), not a generic
list of "possible causes" in no particular order.
- Give the fix as numbered, copy-pasteable steps (the actual line to add to
wp-config.php for increasing memory limit, and how to access site files via FTP
or hosting file manager if wp-admin is inaccessible), since someone reading
this can't log into wp-admin to look for a settings page.
- Include the specific edge case where none of the standard fixes work: the site
was already in a bad state before updating (a corrupted database table, a
disk-full hosting account), and point them to contacting support directly
instead of retrying the same steps again.
- End with how to prevent this next time (a staging site or a
backup-before-update habit), briefly, not as the main focus of the article.
Replace [Plugin Name] and the specific fixes with your actual product's real
causes before running this.