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 →

Customer business requirements translator

Converts free-form customer requirements — call notes, RFP responses, email threads, discovery docs — into a structured product configuration specification with mapped features, policy rules, approval workflows…

download .md

Purpose

Turn messy, free-form customer requirements into a clean, build-ready configuration specification that maps each business need to a specific platform capability, flags gaps between what the customer wants and what the product does, and surfaces the open questions that block implementation. Eliminates the ambiguity that causes rework, scope creep, and misconfigured go-lives.

When to Use

Invoke this skill when the user asks to:

  • Translate discovery call notes or a requirements doc into a configuration spec
  • Turn an RFP response or customer email thread into an implementation blueprint
  • Map customer business rules to product features before a build
  • Identify gaps between customer needs and platform capabilities
  • Prepare a configuration handoff for a solutions or implementation team
  • Structure spend policy, approval, or integration requirements for setup

Inputs Required

Before starting, collect:

  • Requirements source: The raw material — call notes, RFP responses, email threads, discovery doc, or transcript (paste the text)
  • Platform: The product being configured and its category (e.g., spend management, expense, AP automation, fintech/banking)
  • Customer profile: Company size, industry, and org structure (number of departments, entities, or cost centers)
  • Known constraints: Existing systems to integrate, compliance requirements, or non-negotiables
  • Product capability reference: Known features/limits of the platform, if available — otherwise flag capability assumptions
  • Timeline / go-live target: When implementation must be complete
  • Primary stakeholder: Who owns sign-off on the final spec

If the product capability reference is missing, map to common capabilities for the platform category and clearly label each as an assumption to verify.

Instructions

Step 1: Extract and Classify Requirements

Read the entire source and pull out every discrete requirement. Assign each to one of these categories:

  • Policy/Rules: Spend limits, category restrictions, budget controls, expense policies
  • Workflow/Approvals: Who approves what, thresholds, routing, escalations
  • Access/Roles: User roles, permissions, hierarchy, delegation
  • Integrations: ERP, accounting, HRIS, SSO, banking, data sync direction and frequency
  • Reporting/Data: Required reports, exports, GL coding, dimensions, reconciliation
  • Onboarding/Adoption: Rollout phasing, training, migration of historical data

For each requirement, capture: the raw quote/paraphrase from the source, the category, and the implied business goal behind it (the "why").

Step 2: Distinguish Explicit vs. Implied Requirements

  • Explicit: Directly stated ("cards must be capped at $5,000/month")
  • Implied: Not stated but necessary to satisfy an explicit requirement (a $5K cap implies a limit-enforcement rule and an over-limit exception workflow)
  • Flag implied requirements clearly — these are the most common source of missed scope.

Step 3: Map Each Requirement to a Configuration Object

For every requirement, produce a mapping row with:

  • Business requirement: One-sentence plain-language statement
  • Platform feature/setting: The specific object that satisfies it (e.g., "Spend Policy → Category Rule," "Approval Workflow → Threshold Trigger")
  • Configuration detail: The concrete values to set (limits, thresholds, roles, sync fields)
  • Coverage: Fully supported / Partial / Workaround required / Not supported

Step 4: Gap and Risk Analysis

For any requirement rated Partial, Workaround, or Not supported:

  • State the gap precisely
  • Propose the closest viable configuration or workaround
  • Rate the risk to go-live: Low / Medium / High
  • Note whether it requires a product exception, custom work, or a customer process change

Step 5: Sequence Approval Workflows and Policy Logic

  • Lay out approval chains as ordered logic: trigger condition → approver(s) → escalation → fallback
  • Resolve conflicts (e.g., overlapping thresholds or ambiguous routing) and flag them
  • Define policy rules in if/then form so they are directly translatable to configuration

Step 6: Compile Open Questions

List every ambiguity that blocks or risks the build, grouped by category. Phrase each as a specific, answerable question directed at the stakeholder — not open-ended commentary. Assign a blocking severity (Blocker / Clarify before build / Nice to confirm).

Step 7: Produce the Configuration Spec

Assemble the sections in the Output Format order. Lead with a one-paragraph summary of scope and readiness.

Output Format

  • Structure: Structured document with a summary paragraph, requirement mapping table, and supporting sections
  • Length: 900–1,400 words plus the mapping table
  • Format: Prose summary + mapping table + structured lists for workflows, gaps, and questions
  • Sections: 1. Scope Summary & Readiness Assessment 2. Requirement Mapping Table (business requirement → feature → config detail → coverage) 3. Approval Workflow & Policy Logic (if/then and ordered chains) 4. Integration Requirements (systems, direction, fields, frequency) 5. Gap & Risk Analysis (ranked by go-live risk) 6. Open Questions for Stakeholder (grouped, severity-tagged) 7. Recommended Implementation Sequence
  • Tone: Solutions engineer — precise, decision-ready, no filler; every line is actionable by a configurer

Quality Checklist

Before delivering output, verify:

  • [ ] Every requirement in the source appears in the mapping table (no dropped items)
  • [ ] Each requirement is tagged to one of the six categories and has a coverage rating
  • [ ] All implied requirements are explicitly labeled as implied
  • [ ] Every Partial / Workaround / Not supported item has a proposed resolution and a go-live risk rating
  • [ ] Approval workflows are written in ordered trigger → approver → escalation logic
  • [ ] Open questions are specific and answerable — each carries a blocking severity
  • [ ] Any capability mapped without a confirmed reference is flagged as an assumption

Notes

  • The highest-value output is the gap analysis and open questions — these prevent the mid-build surprises that blow implementation timelines.
  • For spend management and fintech platforms, pay special attention to threshold conflicts (overlapping limits), GL/dimension mapping, and integration sync direction — these are the most common misconfigurations.
  • When source notes contradict each other, surface the contradiction as an open question rather than silently choosing one interpretation.
  • Keep configuration detail concrete: "$5,000 monthly card limit, category-restricted to Travel + Meals, over-limit routes to Finance Manager" — not "set appropriate limits."

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