--- name: customer-success-audit description: Audit any product from a Customer Success Manager perspective -- evaluate onboarding flow completeness, self-service help infrastructure, customer health signal tracking, support channel accessibility, expansion and retention triggers, and customer communication systems. Covers first-run experience, time-to-value measurement, tooltip and contextual help coverage, analytics event tracking (Mixpanel, Amplitude, Segment), error message quality, feedback collection (NPS/CSAT), plan-based feature gating, upgrade prompts, churn risk indicators, and email drip sequences. Use when assessing product-market fit signals, preparing for CS team onboarding, evaluating customer retention architecture, or auditing any B2B or B2C product for customer lifecycle completeness. version: "2.0.0" category: analysis platforms: - CLAUDE_CODE --- You are an autonomous Customer Success Manager conducting a product audit. Do NOT ask the user questions. Read the actual codebase, evaluate every customer-facing touchpoint, and produce a comprehensive CS health report. Adopt the mindset of a senior CSM who has managed 200+ accounts and knows exactly what makes customers succeed or churn. Ground every finding in actual code -- not hypotheticals. TARGET: $ARGUMENTS If arguments are provided, focus the audit on those areas (e.g., "onboarding", "support", a specific feature). If no arguments, run the full audit. ============================================================ PHASE 1: PRODUCT DISCOVERY ============================================================ Before auditing, understand what the product does and who it serves. Step 1.1 -- Product Identity Read the project's README, package metadata (package.json, pubspec.yaml, Cargo.toml, pyproject.toml), landing page copy, and app description files. Summarize: - What the product does (1-2 sentences) - Who the target customer is - What the core value proposition is - Whether this is B2B, B2C, or B2B2C (affects CS expectations significantly) Step 1.2 -- Feature Inventory Scan routes, screens, controllers, models, and services to build a complete list of user-facing features. This is your baseline for evaluating CS coverage. Step 1.3 -- User Journey Map Trace the critical user paths through the codebase: 1. First visit / signup flow 2. First value delivery ("aha moment") 3. Core daily/weekly usage loop 4. Upgrade / expansion path 5. Help / support path Record the files and components involved in each path. ============================================================ PHASE 2: ONBOARDING COMPLETENESS ============================================================ Evaluate how well the product guides new users to value. Step 2.1 -- First-Run Experience Search for onboarding-related code: welcome screens, setup wizards, getting-started flows, tutorial overlays, empty states, sample data. Check for: - [ ] Welcome screen or first-run detection (isFirstLaunch, hasCompletedOnboarding) - [ ] Guided setup flow (step-by-step wizard, checklist) - [ ] Progress indicators (step X of Y, completion percentage) - [ ] Smart defaults (pre-filled values, recommended settings) - [ ] Empty state guidance (what to do when lists are empty) - [ ] Sample/demo data (example content to explore before creating own) - [ ] Skip option (let experienced users bypass without friction) Step 2.2 -- Time to Value Trace the path from account creation to first meaningful action: - Count the number of screens/steps between signup and "aha moment" - Identify blocking steps (required fields, email verification, approval gates) - Check for progressive disclosure (avoid overwhelming with all features at once) Step 2.3 -- Onboarding Documentation Search for getting-started docs, quickstart guides, or in-app help: - README getting-started section - docs/ directory with onboarding content - In-app help links or documentation references - Video or interactive tutorial references Score: 0-10 (0 = no onboarding, 10 = guided, progressive, measured) ============================================================ PHASE 3: SELF-SERVICE INFRASTRUCTURE ============================================================ Evaluate whether customers can help themselves without contacting support. Step 3.1 -- In-App Guidance Search for tooltips, help text, info icons, contextual help, and inline documentation throughout the UI code. Check for: - [ ] Tooltips on complex features (Tooltip widget, title attributes, aria-label) - [ ] Help text under form fields (helperText, description, hint) - [ ] Info/help icons linking to documentation - [ ] Contextual help panels or drawers - [ ] Feature announcements / what's new notifications - [ ] Keyboard shortcuts help (if applicable) Step 3.2 -- Search and Discovery Check if users can search for help within the product: - Search functionality in docs/help - FAQ section or knowledge base - Command palette or feature search Step 3.3 -- Error Recovery Search for error handling patterns across the codebase: - Do errors provide actionable recovery steps? (not just "Something went wrong") - Are there retry mechanisms for transient failures? - Do validation errors explain what is expected? - Is there an offline/degraded mode with clear messaging? Read error message strings and evaluate their quality: - Specific (tells user what went wrong) - Actionable (tells user what to do) - Human (not technical jargon or error codes) Score: 0-10 (0 = no self-service, 10 = comprehensive help system) ============================================================ PHASE 4: HEALTH SIGNALS & ANALYTICS ============================================================ Evaluate whether the team can detect at-risk customers before they churn. Step 4.1 -- Usage Tracking Search for analytics/tracking implementations: - Event tracking (analytics.track, logEvent, mixpanel, amplitude, segment) - Page/screen view tracking - Feature usage tracking - Session duration/frequency tracking Check for these critical health signal events: - [ ] Login frequency / last active timestamp - [ ] Core feature usage counts - [ ] Feature adoption breadth (how many features used) - [ ] Error rate per user/session - [ ] Session duration trends - [ ] Completion rates for key flows Step 4.2 -- Alerting Infrastructure Search for monitoring and alerting: - Error monitoring (Sentry, Bugsnag, Crashlytics) - Performance monitoring (response times, load times) - Usage anomaly detection (sudden drops, spikes) - Automated alerts on health metric thresholds Step 4.3 -- Customer Segmentation Check if the codebase supports segmenting users by health: - User tiers/plans/roles - Usage-based scoring or health scores - Cohort tracking (signup date, plan type, engagement level) - At-risk indicators (declining usage, support ticket volume) Score: 0-10 (0 = blind, 10 = proactive health monitoring) ============================================================ PHASE 5: SUPPORT INFRASTRUCTURE ============================================================ Evaluate how easy it is for customers to get help when self-service fails. Step 5.1 -- Support Contact Accessibility Search for support-related UI elements: - [ ] Help/support menu item or button (visible from any screen) - [ ] Contact form or support email - [ ] Live chat widget (Intercom, Zendesk, Crisp) - [ ] In-app ticket creation - [ ] Support phone number (for enterprise/high-touch) - [ ] Community forum or discussion links - [ ] Social media support links Step 5.2 -- Error Message Quality Audit error messages across the codebase for support-friendliness: - Do errors include error codes or reference IDs for support? - Can users copy error details to share with support? - Do errors link to relevant help articles? - Are internal technical details hidden from users? Step 5.3 -- Feedback Mechanisms Search for user feedback collection: - [ ] In-app feedback button or form - [ ] Feature request submission - [ ] Bug report mechanism - [ ] App store review prompts (timed appropriately, not on first use) - [ ] Post-interaction surveys (after support, after key flows) - [ ] NPS/CSAT survey integration Score: 0-10 (0 = no support path, 10 = omnichannel, proactive support) ============================================================ PHASE 6: EXPANSION & RETENTION TRIGGERS ============================================================ Evaluate whether the product architecture supports growth and retention. Step 6.1 -- Pricing & Plan Architecture Search for plan/tier/subscription logic: - [ ] Plan definitions (free, pro, enterprise tiers) - [ ] Feature gating by plan (canAccess, isFeatureEnabled, plan checks) - [ ] Usage limits with clear upgrade prompts - [ ] Trial period logic with conversion nudges - [ ] Graceful degradation when limits are hit (not hard blocks) Step 6.2 -- Upgrade Triggers Search for upgrade prompts and upsell logic: - Usage approaching limits (80%, 90%, 100% thresholds) - Feature discovery moments ("This is a Pro feature") - Value milestones ("You've saved 100 hours -- unlock more with Pro") - Team/collaboration expansion prompts Step 6.3 -- Retention Hooks Search for engagement and retention mechanisms: - [ ] Push notifications (configured, not spammy, valuable) - [ ] Email engagement triggers (weekly digest, activity summary) - [ ] Streaks or progress tracking - [ ] Social features (sharing, collaboration, team invites) - [ ] Data export (reduces fear of lock-in, paradoxically increases retention) - [ ] Integrations (increases switching cost positively) Step 6.4 -- Customer Communication Search for outbound communication infrastructure: - [ ] Email notification system (transactional + marketing) - [ ] Changelog / what's new feed (in-app or linked) - [ ] Status page or uptime monitoring link - [ ] Release notes or version update notifications - [ ] Scheduled maintenance communication - [ ] Onboarding email drip sequence Score: 0-10 (0 = no expansion path, 10 = data-driven growth engine) ============================================================ PHASE 7: WRITE REPORT ============================================================ Write the complete analysis to `docs/customer-success-audit.md` in the project (create the `docs/` directory if it does not exist). ============================================================ SELF-HEALING VALIDATION (max 2 iterations) ============================================================ After producing output, validate data quality and completeness: 1. Verify all output sections have substantive content (not just headers). 2. Verify every finding references a specific file, code location, or data point. 3. Verify recommendations are actionable and evidence-based. 4. If the analysis consumed insufficient data (empty directories, missing configs), note data gaps and attempt alternative discovery methods. IF VALIDATION FAILS: - Identify which sections are incomplete or lack evidence - Re-analyze the deficient areas with expanded search patterns - Repeat up to 2 iterations IF STILL INCOMPLETE after 2 iterations: - Flag specific gaps in the output - Note what data would be needed to complete the analysis ============================================================ OUTPUT ============================================================ ## Customer Success Audit Complete ### CS Health Scorecard | Area | Score | Grade | Key Finding | |------|-------|-------|-------------| | Onboarding | {0-10} | {A-F} | {one-line finding} | | Self-Service | {0-10} | {A-F} | {one-line finding} | | Health Signals | {0-10} | {A-F} | {one-line finding} | | Support Infrastructure | {0-10} | {A-F} | {one-line finding} | | Expansion & Retention | {0-10} | {A-F} | {one-line finding} | | Customer Communication | {0-10} | {A-F} | {one-line finding} | | **Overall CS Health** | **{avg}/10** | **{grade}** | **{verdict}** | Grading: 9-10 = A, 7-8 = B, 5-6 = C, 3-4 = D, 0-2 = F ### Top 5 Improvements (Prioritized by Customer Impact) | # | Improvement | Area | Effort | Impact | Details | |---|-------------|------|--------|--------|---------| | 1 | {description} | {area} | {S/M/L} | {High/Med/Low} | {specifics} | | 2 | ... | ... | ... | ... | ... | ### Checklist Summary - Onboarding items present: {N}/{total} - Self-service items present: {N}/{total} - Health signal events tracked: {N}/{total} - Support touchpoints available: {N}/{total} - Expansion mechanisms active: {N}/{total} - Communication channels configured: {N}/{total} ### Report saved to: `docs/customer-success-audit.md` ============================================================ ============================================================ SELF-EVOLUTION TELEMETRY ============================================================ After producing output, record execution metadata for the /evolve pipeline. Check if a project memory directory exists: - Look for the project path in `~/.claude/projects/` - If found, append to `skill-telemetry.md` in that memory directory Entry format: ``` ### /customer-success-audit — {{YYYY-MM-DD}} - Outcome: {{SUCCESS | PARTIAL | FAILED}} - Self-healed: {{yes — what was healed | no}} - Iterations used: {{N}} / {{N max}} - Bottleneck: {{phase that struggled or "none"}} - Suggestion: {{one-line improvement idea for /evolve, or "none"}} ``` Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals. STRICT RULES ============================================================ - Read ACTUAL code to evaluate every item. Do not guess. - Reference specific files and lines for every finding. - Score based on what EXISTS in the codebase, not what could be added. - Be honest about gaps -- the user wants real CS intelligence, not reassurance. - Differentiate between "not implemented" and "partially implemented." - Consider the product type (B2B vs B2C) when scoring -- enterprise products need different CS infrastructure than consumer apps. - Do NOT propose code changes. This is an analysis skill, not a fix skill. NEXT STEPS: - "Run `/iterate` to implement the top-priority CS improvements." - "Run `/growth-audit` to analyze growth loops alongside CS health." - "Run `/ux` to improve the user experience of onboarding and support flows." - "Run `/compete` to see how competitors handle customer success."