Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Case status update generator

Converts raw case notes, ticket logs, or activity data into clean, consistent status update summaries formatted separately for internal stakeholders and customers, with a status classification, next steps, owner, and…

download .md

Purpose

Turn messy case notes, ticket threads, or raw activity logs into polished, consistently structured status updates — one version for internal stakeholders and one for customers — so case managers can push out clear, professional updates fast without rewriting from scratch for every case.

When to Use

Invoke this skill when the user asks to:

  • Write a status update for one or more open cases
  • Summarize case notes into a clean progress update
  • Draft a customer-facing update on a case, ticket, or claim
  • Draft an internal update for a supervisor, team lead, or cross-functional partner
  • Clear a backlog of pending case updates quickly and consistently
  • Standardize how their team writes and formats case updates

Inputs Required

Before starting, collect:

  • Raw case material: The notes, ticket thread, activity log, or data dump to convert
  • Case identifier: Case/ticket number and (if relevant) the customer or account name
  • Audience: Internal stakeholder, customer-facing, or both versions
  • Case type: What kind of case this is (support ticket, claim, escalation, service request, investigation, etc.)
  • Current status: What has just happened or what stage the case is at, if not obvious from the notes
  • Known next step or owner: If already decided — otherwise the skill infers from the notes
  • Tone preference: Neutral-professional / warm-reassuring / firm-direct (defaults to neutral-professional)

If audience is not specified, produce both an internal and a customer-facing version. If case type is unclear, infer it from the notes and state the assumption.

Instructions

Step 1: Parse and Classify the Raw Material

Read the raw case material and extract the essential facts:

  • What has happened since the case opened or was last updated (actions taken, findings, communications)
  • What is currently blocking or pending (waiting on customer, waiting on internal team, waiting on vendor, under review)
  • What is decided vs. still open
  • Strip filler, duplicate log entries, and internal shorthand that won't read cleanly.

Assign a single status classification from this standard set:

  • New / Triaging — received, not yet actioned
  • In Progress — active work underway
  • Pending – Customer — awaiting customer response or action
  • Pending – Internal/Third Party — awaiting another team or vendor
  • Escalated — elevated for priority or specialist handling
  • Resolved — closed with outcome
  • On Hold — intentionally paused

Pick exactly one. If the notes suggest more than one, choose the one that reflects the immediate blocker.

Step 2: Build the Core Update Facts

Assemble the reusable facts both versions will draw from:

  1. One-line summary: A single sentence capturing where the case stands right now
  2. What we did: 2–4 bullet points of concrete actions or progress, in plain past tense
  3. Current status: The classification from Step 1 plus a one-line reason
  4. Next step: The single most important next action, with an owner (us or the customer) named
  5. Expected resolution / next update date: A specific date or timeframe — never "soon" or "shortly"

If any of these cannot be determined from the notes, flag it explicitly rather than inventing it.

Step 3: Generate the Internal Stakeholder Version

Write for a supervisor, team lead, or cross-functional partner who needs signal fast:

  • Lead with the status classification and one-line summary
  • Include specifics the customer wouldn't see: root cause notes, internal blockers, risk flags, effort/time spent, escalation triggers
  • Be direct — no softening, no reassurance language
  • Call out anything requiring a decision or help from the reader

Step 4: Generate the Customer-Facing Version

Write for the customer or external stakeholder:

  • Open with a clear statement of where things stand, in accessible language
  • Translate internal jargon into plain terms; remove internal names, tools, and blame
  • Confirm what has been done and what happens next, with a date
  • Set expectations honestly — if delayed, say so and why, briefly
  • Close with a clear point of contact or next-update commitment
  • Apply the tone preference; default to neutral-professional and reassuring without over-apologizing

Step 5: Handle Batches (If Multiple Cases)

When given multiple cases:

  • Process each one through Steps 1–4
  • Keep formatting identical across all cases so the batch reads as one consistent set
  • Present them in a numbered sequence, each with its case identifier as a header

Output Format

  • Structure: Per case — a short header (case ID + status classification), then the internal version and/or customer-facing version as labeled blocks
  • Length: 120–200 words per version per case; scale linearly for batches
  • Format: Structured update — one-line summary, short bulleted "what we did," and a clear next-step line; prose for the customer-facing body
  • Sections: Case header → Status classification → Internal version → Customer-facing version → Next update date
  • Tone: Internal version is direct and signal-dense; customer-facing version is clear, calm, and professional — never vague, never over-apologetic

Quality Checklist

Before delivering output, verify:

  • [ ] Each case has exactly one status classification from the standard set
  • [ ] Every update names a specific next step with an owner (us or customer)
  • [ ] Every update includes a concrete date or timeframe — no "soon," "shortly," or "ASAP"
  • [ ] The customer-facing version contains no internal names, tools, jargon, or blame
  • [ ] Any fact not present in the source notes is flagged, not invented
  • [ ] Batch updates use identical structure and formatting across every case

Notes

  • The most common failure in case updates is a vague next step — always force an owner and a date, even if the date is "next update by [specific day]."
  • If the raw notes contain conflicting information, surface the conflict in the internal version rather than smoothing it over in the customer version.
  • For sensitive or escalated cases, keep the customer-facing version shorter and more measured — less detail reduces the risk of committing to something the team can't deliver.
  • This skill standardizes format; it does not make case decisions. When the notes don't support a next step, say what's needed to determine one.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills