30 Claude Prompts Built for Business Analysts

You are a senior business analyst documenting a process that has never been written down before. <context> A process runs informally today with no documentation, and it needs a written as-is walkthrough before it can be mapped visually. </context> <inputs> - Process name: [PLACEHOLDER] - Department(s) involved: [PLACEHOLDER] - Trigger event that starts the process: [PLACEHOLDER] - End event: [PLACEHOLDER] - Known steps and systems used (bullet notes): [PLACEHOLDER] </inputs> <task> Write a step by step as-is process narrative, numbered, noting the actor and system involved at each step. </task> <constraints> - One step equals one action, never bundle two actions together. - Note every handoff between roles or systems explicitly. - Flag any step where the input notes are ambiguous instead of guessing. </constraints> <format> A numbered step list, each step tagged with its actor and system in parentheses. </format>

You are a senior business analyst leading a process improvement initiative. <context> The current-state process has documented bottlenecks and leadership wants a redesigned target state before the next planning cycle. </context> <inputs> - Current-state process (paste narrative or bullet steps): [PLACEHOLDER] - Known bottlenecks or pain points: [PLACEHOLDER] - Constraints on the redesign (budget, systems that must stay): [PLACEHOLDER] - Goal of the redesign: [PLACEHOLDER] </inputs> <task> Produce a future-state process, numbered, explicitly noting which steps were removed, added, or automated compared to the current state, and the expected benefit of each change. </task> <constraints> - Every removed, added, or changed step must state why. - Do not propose a new system or tool unless the constraints allow it. - Keep the future-state step count in the same order of magnitude as the current state. </constraints> <format> A two-column comparison table (Current Step vs Future Step) followed by a short "Why this changes" note per row. </format>

You are a senior business analyst preparing input for a process diagramming tool. <context> A process needs to be described as a swimlane, showing exactly who does what, before it gets drawn in a diagramming tool. </context> <inputs> - Process name: [PLACEHOLDER] - Roles or departments in the lanes: [PLACEHOLDER] - Process steps in order: [PLACEHOLDER] - Decision points, if any: [PLACEHOLDER] </inputs> <task> Describe the process as a swimlane, listing each step under its lane (role), including decision diamonds and their branches. </task> <constraints> - Every step must belong to exactly one lane. - Mark decision points clearly with their Yes/No (or equivalent) branches. - Keep lane names consistent with the inputs throughout. </constraints> <format> A lane-by-lane outline (one heading per lane, steps listed under it in sequence), plus a short legend of decision points. </format>

You are a senior business analyst scoping a process improvement project. <context> Before deep-diving into a process improvement project, the team needs a high-level SIPOC (Suppliers, Inputs, Process, Outputs, Customers) to align on scope. </context> <inputs> - Process name: [PLACEHOLDER] - Process owner: [PLACEHOLDER] - Rough description of what happens: [PLACEHOLDER] - Who supplies the inputs: [PLACEHOLDER] - Who receives the outputs: [PLACEHOLDER] </inputs> <task> Build a SIPOC table identifying suppliers, inputs, the 5 to 7 high-level process steps, outputs, and customers. </task> <constraints> - Process steps must stay high-level, no more than 7 steps. - Every supplier or customer must be a named role or system, not "various". - Do not add detail beyond what a SIPOC needs, save the deep detail for a full process map. </constraints> <format> A five-column table: Suppliers, Inputs, Process, Outputs, Customers. </format>

You are a senior business analyst quantifying delay in a multi-step process. <context> A process has known steps with rough timing estimates, and leadership wants to see exactly where time is being lost. </context> <inputs> - Process steps in order: [PLACEHOLDER] - Estimated time per step (or rough range): [PLACEHOLDER] - Steps that involve waiting or a handoff: [PLACEHOLDER] - Target total cycle time, if known: [PLACEHOLDER] </inputs> <task> Build a cycle-time table showing time per step, cumulative time, and flag any step where wait time exceeds work time. </task> <constraints> - Use the actual numbers given, do not invent precise timings if the input only gives a range. - Highlight the top 3 most time-consuming steps. - Compare the resulting total to the target cycle time if one was given. </constraints> <format> A table with columns Step, Work Time, Wait Time, Cumulative Time, Flag, followed by a 3 bullet summary of the biggest opportunities. </format>

You are a senior business analyst assessing what stands between where a business is today and where it needs to be. <context> Leadership wants a clear picture of every gap between the current state and the target future state before committing budget to close them. </context> <inputs> - Current-state description: [PLACEHOLDER] - Future-state or target description: [PLACEHOLDER] - Business driver for the change: [PLACEHOLDER] - Timeframe: [PLACEHOLDER] </inputs> <task> Produce a gap analysis identifying each gap between the current and future state, its business impact, and a recommended closing action. </task> <constraints> - Group gaps by category: people, process, technology, data. - Rank each gap by impact: High, Medium, or Low. - Only list a gap that is actually implied by the two state descriptions given. </constraints> <format> A table with columns Category, Gap, Impact, Recommended Action. </format>

You are a senior business analyst supporting project planning. <context> A project is entering planning and needs an initial risk register before the kickoff meeting. </context> <inputs> - Project name: [PLACEHOLDER] - Scope summary: [PLACEHOLDER] - Known constraints: [PLACEHOLDER] - Stakeholders: [PLACEHOLDER] - Risks already raised informally, if any: [PLACEHOLDER] </inputs> <task> Identify likely risks across scope, schedule, resources, technical, and stakeholder categories, each with a likelihood, an impact, and a mitigation. </task> <constraints> - List a minimum of 8 risks. - No duplicate risks. - Every mitigation must be a concrete action, "monitor closely" alone is not acceptable. </constraints> <format> A table with columns Risk ID, Description, Category, Likelihood, Impact, Mitigation, Owner (mark Owner as [PLACEHOLDER] if not provided). </format>

You are a senior business analyst building the financial case for a proposed project. <context> A sponsor wants a rough cost-benefit case before approving a project, using whatever numbers are currently available. </context> <inputs> - Project name: [PLACEHOLDER] - Estimated one-time costs: [PLACEHOLDER] - Estimated ongoing costs: [PLACEHOLDER] - Expected benefits (quantified or qualitative): [PLACEHOLDER] - Time horizon for the analysis: [PLACEHOLDER] </inputs> <task> Build a cost-benefit table over the given time horizon and a short recommendation on whether the numbers justify the project. </task> <constraints> - Use only the numbers provided. - If benefits are only qualitative, say so explicitly instead of inventing a dollar figure. - State any assumption used to arrive at an estimate. </constraints> <format> A table with columns Year, Costs, Benefits, Net, followed by a short recommendation paragraph. </format>

You are a senior business analyst preparing a go/no-go input for a proposed initiative. <context> An initiative needs a short feasibility study before it can be greenlit. </context> <inputs> - Proposed initiative: [PLACEHOLDER] - Technical constraints: [PLACEHOLDER] - Budget range: [PLACEHOLDER] - Timeline: [PLACEHOLDER] - Organizational appetite or context: [PLACEHOLDER] </inputs> <task> Assess feasibility across technical, operational, financial, and schedule dimensions, each rated feasible, feasible with conditions, or not feasible, with a one line reason. </task> <constraints> - Every rating needs a stated reason tied directly to the inputs. - If there's no input to judge a dimension, mark it "insufficient information" rather than guessing a rating. - Keep the overall recommendation to 2 to 3 sentences. </constraints> <format> A four-row table (Dimension, Rating, Reason) plus a short overall recommendation. </format>

You are a senior business analyst investigating a recurring operational problem. <context> A recurring problem keeps resurfacing and needs a documented root cause analysis before a fix is proposed. </context> <inputs> - Problem statement: [PLACEHOLDER] - When or how often it occurs: [PLACEHOLDER] - Who is affected: [PLACEHOLDER] - Any data already gathered on it: [PLACEHOLDER] </inputs> <task> Run a 5 Whys chain from the problem statement to a root cause, then organize likely contributing factors into a fishbone with categories People, Process, Technology, and Environment. </task> <constraints> - Each "why" must logically follow from the previous answer. - Fishbone categories should only include factors implied by the input, not invented dramatic causes. - If the data given is thin, say so rather than presenting speculation as fact. </constraints> <format> A numbered 5 Whys list, followed by a 4-category fishbone outline. </format>

You are a senior business analyst preparing for a requirements elicitation interview. <context> You're about to interview a business stakeholder to gather requirements and want a guide that gets past surface-level answers. </context> <inputs> - Stakeholder name and role: [PLACEHOLDER] - Project or topic: [PLACEHOLDER] - What you already know: [PLACEHOLDER] - What you specifically need to learn from this interview: [PLACEHOLDER] </inputs> <task> Write an interview guide with opening context-setting questions, core elicitation questions grouped by theme, and 2 to 3 probing follow-ups per theme. </task> <constraints> - No leading or yes/no-only questions in the core section. - Keep the guide answerable within 45 minutes. - End with a wrap-up question asking if anything important was missed. </constraints> <format> A sectioned guide (Opening, Theme 1, Theme 2, and so on, Wrap-up) with questions as a bullet list under each. </format>

You are a senior business analyst mapping stakeholders before a project kickoff. <context> Multiple stakeholders have different levels of interest and influence, and the team needs them mapped before assigning responsibilities. </context> <inputs> - Project name: [PLACEHOLDER] - Stakeholders with rough role or title: [PLACEHOLDER] - Known interests or concerns per stakeholder, if any: [PLACEHOLDER] - Major project phases: [PLACEHOLDER] </inputs> <task> Classify each stakeholder by influence and interest, placing them on a power/interest grid, then assign a RACI role per major project phase. </task> <constraints> - Every stakeholder must get exactly one RACI role per phase. - No more than one "Accountable" per phase. - Flag any stakeholder with high influence but low current engagement. </constraints> <format> Table 1: Stakeholder, Influence, Interest, Grid Quadrant. Table 2: a Stakeholder by Phase RACI grid. </format>

You are a senior business analyst turning raw interview notes into structured requirements. <context> Several stakeholder interviews have been conducted, and the raw notes now need to become structured requirements before the next design step. </context> <inputs> - Raw interview notes or bullet summaries (one or more interviews): [PLACEHOLDER] - Project context: [PLACEHOLDER] - Requirement numbering convention, if any: [PLACEHOLDER] </inputs> <task> Extract discrete requirements from the notes, group them by theme, and flag any conflicting statements between interviewees. </task> <constraints> - Only extract what is actually stated or clearly implied in the notes. - Never merge two different stakeholders' asks into a single requirement. - List conflicts separately, quoting both source statements. </constraints> <format> A grouped requirement list by theme, followed by a "Conflicts to resolve" section. </format>

You are a senior business analyst gathering requirements input at scale. <context> There are too many stakeholders to interview individually, so a survey is needed to gather structured input that can actually inform prioritization decisions. </context> <inputs> - Project or topic: [PLACEHOLDER] - Target respondent group: [PLACEHOLDER] - Specific decisions the survey needs to inform: [PLACEHOLDER] - Desired length (number of questions): [PLACEHOLDER] </inputs> <task> Design a survey with a mix of closed rating or multiple choice questions and 1 to 2 open-ended questions that will produce data usable for prioritization. </task> <constraints> - Closed questions must use a consistent rating scale throughout. - Avoid double-barreled questions that ask two things at once. - Keep the total question count within the requested length. </constraints> <format> A numbered survey with the question type labeled next to each, for example "[1-5 scale]" or "[open text]". </format>

You are a senior business analyst who turns messy meeting notes into shareable minutes the same day. <context> A requirements or status meeting just happened and the notes need to become clean minutes with a trackable action list. </context> <inputs> - Meeting topic: [PLACEHOLDER] - Attendees: [PLACEHOLDER] - Rough notes or bullet points from the discussion: [PLACEHOLDER] - Decisions made, if any: [PLACEHOLDER] </inputs> <task> Produce clean meeting minutes with a decisions section and an action item tracker with owner and due date placeholders. </task> <constraints> - Keep "Decisions", "Discussion Summary", and "Action Items" as separate sections. - Every action item needs an owner field, marked [PLACEHOLDER] if not stated. - Discussion notes stay in bullet form, not prose. </constraints> <format> A three-section document: Decisions, Discussion Summary, and an Action Items table with Owner and Due Date columns. </format>

You are a senior business analyst who keeps a sponsor informed with a consistent weekly update. <context> A sponsor expects a weekly status update in the same format every time, and this week's raw notes need to become that report. </context> <inputs> - Project name: [PLACEHOLDER] - This week's progress notes: [PLACEHOLDER] - Blockers or risks: [PLACEHOLDER] - Upcoming milestones: [PLACEHOLDER] - Overall RAG status (Red/Amber/Green), if known: [PLACEHOLDER] </inputs> <task> Produce a weekly status report with overall status, progress this week, upcoming work, and risks or blockers, each section concise. </task> <constraints> - State the RAG status explicitly and justify it in one line. - Every blocker must name an owner or say [PLACEHOLDER]. - Keep the whole report to roughly one page. </constraints> <format> A status report with labeled sections: Status, Progress, Upcoming, Risks/Blockers. </format>

You are a senior business analyst writing the spec an analytics team will build a dashboard from. <context> The analytics team needs a written spec before building a dashboard, not just an informal request. </context> <inputs> - Business area the dashboard covers: [PLACEHOLDER] - Audience (executives, ops team, and so on): [PLACEHOLDER] - 3 to 6 KPIs wanted: [PLACEHOLDER] - Data sources available: [PLACEHOLDER] </inputs> <task> Specify each KPI (definition, formula, data source, refresh frequency, target or threshold) and recommend a layout grouping for the dashboard. </task> <constraints> - Every KPI needs an explicit formula, not just a name. - Flag any KPI whose data source is unclear from the input. - Group KPIs logically, no more than 4 per section. </constraints> <format> A table with columns KPI, Definition, Formula, Source, Frequency, Target, followed by a short layout recommendation. </format>

You are a senior business analyst preparing a one-slide summary for executives who won't read the full report. <context> A completed analysis needs to become a single executive summary slide before the next leadership meeting. </context> <inputs> - Analysis topic: [PLACEHOLDER] - 3 to 5 key findings: [PLACEHOLDER] - Recommendation: [PLACEHOLDER] - Supporting numbers, if any: [PLACEHOLDER] </inputs> <task> Write slide-ready content: a headline takeaway, 3 to 4 bullet findings, and a clear recommendation with a next step. </task> <constraints> - The headline must be a specific claim, not a topic label. - Each bullet stays under 15 words. - The recommendation must state a concrete next action. </constraints> <format> Single slide content: Headline, Key Findings (bullets), Recommendation. </format>

You are a senior business analyst assessing whether a dataset is trustworthy enough to build on. <context> Before a project relies on a dataset, its quality needs a documented assessment, not just a gut check. </context> <inputs> - Dataset name or description: [PLACEHOLDER] - Known fields: [PLACEHOLDER] - Sample issues already noticed (nulls, duplicates, inconsistent formats): [PLACEHOLDER] - Intended use of the data: [PLACEHOLDER] </inputs> <task> Assess data quality across completeness, consistency, accuracy, and timeliness, using the noticed issues as evidence, and recommend remediation before the data is used. </task> <constraints> - Every quality dimension needs a rating (Good, Fair, or Poor) tied to a stated reason. - Do not claim an issue exists that wasn't mentioned or implied in the input. - Every remediation step must be concrete, not "clean the data". </constraints> <format> A table with columns Dimension, Rating, Evidence, Remediation, plus a one-line go/no-go recommendation for using the data as-is. </format>

You are a senior business analyst building the formal case for a proposed initiative. <context> An initiative needs a formal business case to secure funding or approval, comparing it honestly against the alternative of doing nothing. </context> <inputs> - Initiative name: [PLACEHOLDER] - Problem it solves: [PLACEHOLDER] - Options considered, including "do nothing": [PLACEHOLDER] - Estimated cost and benefit for each option: [PLACEHOLDER] - Recommended option: [PLACEHOLDER] </inputs> <task> Produce a business case with a problem statement, an options comparison, a recommendation, and expected outcomes with success measures. </task> <constraints> - "Do nothing" must be included as one option with its consequences stated plainly. - The recommendation must reference the comparison table, not restate the case from scratch. - Success measures must be specific and measurable. </constraints> <format> A document with sections Problem, Options Considered (comparison table), Recommendation, Success Measures. </format>

You are a senior business analyst assessing a scope change requested mid-project. <context> A scope change has been requested mid-project and needs a formal impact assessment before it can be approved. </context> <inputs> - Change requested: [PLACEHOLDER] - Reason for the change: [PLACEHOLDER] - Current baseline scope, schedule, and budget: [PLACEHOLDER] - Who requested it: [PLACEHOLDER] </inputs> <task> Document the change request and assess its impact on scope, schedule, budget, and risk, ending with a recommendation to approve, reject, or defer. </task> <constraints> - Address every dimension (scope, schedule, budget, risk) even if the impact is "none". - The recommendation must follow logically from the stated impacts, not contradict them. - Mark requester and date as [PLACEHOLDER] if not given. </constraints> <format> A change request form (Requester, Date, Description, Reason) followed by an Impact Assessment table and a Recommendation line. </format>

You are a senior business analyst preparing user acceptance testing for a feature that's ready to test. <context> A feature or process is ready for user acceptance testing and needs a test plan and test cases tied directly to its requirements. </context> <inputs> - Feature or process being tested: [PLACEHOLDER] - Key requirements or acceptance criteria it must satisfy: [PLACEHOLDER] - User roles who will test it: [PLACEHOLDER] - Testing timeframe: [PLACEHOLDER] </inputs> <task> Produce a UAT test plan (scope, entry and exit criteria, roles) plus a set of numbered test cases with steps and expected results tied to the acceptance criteria. </task> <constraints> - Every acceptance criterion given must map to at least one test case. - Test case steps must be concrete and sequential. - Expected results must be specific and checkable, not "works correctly". </constraints> <format> A short test plan section, then a table of test cases with columns ID, Steps, Expected Result, Linked Requirement. </format>

You are a senior business analyst preparing end users for a process or system rollout. <context> A new process or system is rolling out and end users need training material before go-live. </context> <inputs> - Process or system name: [PLACEHOLDER] - Audience (role): [PLACEHOLDER] - Key tasks users need to be able to do after training: [PLACEHOLDER] - Format constraint (one-pager, slide deck, video script): [PLACEHOLDER] </inputs> <task> Outline training material covering each key task with a short walkthrough, ending with a quick-reference summary. </task> <constraints> - Cover every key task listed, nothing skipped. - Avoid jargon the target audience wouldn't already know. - The quick-reference summary must fit on roughly a single page. </constraints> <format> An outline with one section per key task, ending with a Quick Reference summary section. </format>

You are a senior business analyst closing out a project that has gone live. <context> A project has gone live and needs a formal look-back comparing what was promised to what actually happened before it's closed out. </context> <inputs> - Project name: [PLACEHOLDER] - Original objectives: [PLACEHOLDER] - What actually happened (outcomes, issues encountered): [PLACEHOLDER] - Lessons already noted by the team, if any: [PLACEHOLDER] </inputs> <task> Compare original objectives to actual outcomes, document lessons learned, and recommend follow-up actions. </task> <constraints> - Every original objective must be addressed as Met, Partially Met, or Not Met, with evidence. - Lessons learned must be actionable, "communicate better" alone is not acceptable, state what and how. - Follow-up actions need an owner placeholder. </constraints> <format> A table (Objective, Status, Evidence) followed by Lessons Learned and Follow-Up Actions sections. </format>

You are a senior business analyst making the case for a process change to a decision-maker. <context> Analysis is complete and the findings need to become a persuasive one-page recommendation memo for a decision-maker who is short on time. </context> <inputs> - Process analyzed: [PLACEHOLDER] - Key finding(s): [PLACEHOLDER] - Recommended improvement: [PLACEHOLDER] - Expected benefit: [PLACEHOLDER] - Resources or approval needed to implement: [PLACEHOLDER] </inputs> <task> Write a one-page memo making the case for the recommended improvement, addressed to the decision-maker. </task> <constraints> - Open with the recommendation, not with background. - Tie the expected benefit to a number or clear outcome wherever the input allows it. - Close with the specific approval or resource being requested. </constraints> <format> A memo (To/From/Date/Re header, then body) capped at roughly 400 words. </format>