These 12 prompts cover the work an independent or management consultant actually does: turning a discovery call into a proposal and an SOW, synthesizing research into themes, building frameworks and hypothesis trees, outlining a client deck with a real storyline, drafting executive summaries, and QA-ing a deliverable before it ships. Each one is annotated, uses [PLACEHOLDER] tokens, and is ready to paste into Claude. Anonymize the client data, run the prompt, then keep your judgment on the output. The judgment is still the part clients pay for.
You are a senior management consultant drafting a proposal from my discovery call notes. Write to win the work without overpromising. Discovery notes (paste; anonymize the client first): [PASTE NOTES: who I met, their stated problem, what they said success looks like, constraints, budget signals, timeline] Draft a proposal with these sections: 1. Situation: restate the client's problem in their own language so they feel understood. Two short paragraphs. 2. Objectives and success criteria: turn their vague goals into specific, measurable outcomes. Flag any goal that was implied but not stated and mark it as an assumption to confirm. 3. Approach: the phases of work and what happens in each, at a level a non-expert buyer can follow. 4. Deliverables: concrete artifacts they receive, tied to the objectives. 5. Why me: a short, evidence-based fit statement. Do not invent credentials or past clients. 6. Open questions: what I still need to confirm before this is firm. Keep it confident and specific, no filler. Use only what is in my notes. Where you infer, label it and tell me what to verify. Do not use em dashes or en dashes.
Act as a consultant writing a scope of work for an engagement. The goal is a document that is clear enough to prevent scope creep and fair to both sides. Inputs (paste): - Engagement summary: [WHAT WE AGREED, FROM THE PROPOSAL] - Phases and deliverables: [LIST] - Timeline and key dates: [LIST] - Commercials: [FEE STRUCTURE, e.g. fixed fee, retainer, T&M] - Client responsibilities and dependencies: [DATA ACCESS, SMEs, SIGN-OFFS] Produce an SOW with: 1. In-scope work, stated as specific deliverables and activities. 2. Explicitly out-of-scope items, so the boundary is unambiguous. 3. Assumptions the scope depends on, and what changes if they break. 4. A change-control note: how new requests get priced and approved rather than absorbed. 5. Acceptance criteria for each deliverable, so "done" is defined. 6. Client dependencies and what happens to the timeline if they slip. Be precise and balanced, not one-sided. Flag any place where the inputs are too vague to scope, and ask me for the missing detail rather than guessing.
Help me scope and price a consulting engagement. Be a thinking partner, not a calculator that invents numbers. What I know (paste): - The problem and desired outcome: [DESCRIPTION] - Likely workstreams: [LIST] - My rough effort estimate per workstream, if I have one: [HOURS OR DAYS] - My rates or target economics: [DAY RATE / TARGET FEE / FLOOR] - Client context: [SIZE, URGENCY, BUDGET SIGNALS, COMPLEXITY] Do this: 1. Break the work into a clear workstream and phase structure, and for each, list the activities that drive effort. 2. Where I gave effort estimates, sum them and show the arithmetic. Where I did not, name the estimate I need to supply and give a sensible range to react to, clearly labeled as a placeholder. 3. Compare pricing models for this engagement (fixed fee, retainer, time and materials, value-based) and say which fits the risk profile and why. 4. Flag the two or three estimating risks most likely to blow the budget, and how to structure around them (phasing, a paid discovery, a change-control clause). 5. Give me a one-paragraph pricing rationale I can use to explain the number to the client. Do not fabricate a rate or a market benchmark. If a figure is mine to decide, ask for it.
You are a consultant designing a discovery interview guide. The goal is to surface the real problem and decision drivers, not to collect surface answers. Context: - Engagement objective: [WHAT WE ARE TRYING TO LEARN OR DECIDE] - Who I am interviewing: [ROLE, e.g. Head of Operations] and what they likely care about - Time available: [e.g. 45 minutes] - Hypotheses I am holding so far: [LIST, OR "none yet"] Build the guide: 1. A short framing I can read at the top to set context and put the person at ease. 2. 8 to 12 open questions sequenced from broad to specific, written to avoid leading the witness. 3. For the key questions, a follow-up probe that digs past the first answer to the why behind it. 4. A few questions specifically designed to disconfirm my hypotheses, not just confirm them. 5. A closing question that reliably surfaces what I forgot to ask. Keep questions neutral and non-leading. Tailor the language to this role. Note any question that could be sensitive and suggest a gentler phrasing.
Act as a research lead synthesizing qualitative inputs into themes. Use only the material I provide. Do not add outside facts. Inputs (paste or attach; anonymize names first): [PASTE INTERVIEW NOTES, SURVEY RESPONSES, OR RESEARCH EXCERPTS] Synthesize: 1. Identify the 4 to 7 themes that recur across the inputs. For each, name it crisply and write a one-line description. 2. Under each theme, cite the specific evidence (which interview, which response) that supports it. If a theme rests on a single source, say so. 3. Separate strong signals (appear repeatedly, across sources) from weak signals (mentioned once) and label each. 4. Surface tensions and contradictions where sources disagree, rather than averaging them away. 5. Note what is conspicuously absent: questions the data does not answer and where I should dig next. 6. End with the 3 insights most likely to matter to the client decision, each tied back to evidence. Do not invent quotes or attribute a view to a source that did not express it. If you are inferring rather than quoting, mark it clearly.
You are an analyst building a competitive and market scan for a client. Accuracy matters more than completeness, so flag what you cannot verify. Scope: - Client and their position: [DESCRIPTION] - The market or competitive set in question: [DEFINE IT] - Source material I am giving you: [PASTE OR ATTACH REPORTS, SITES, NOTES] - The decision this scan informs: [e.g. whether to enter segment X] Produce: 1. A structured profile of each named competitor or option, using a consistent set of dimensions (positioning, target, pricing model, strengths, weaknesses) drawn from the sources. 2. A comparison table across those dimensions so differences are visible at a glance. 3. Where the market is heading, based only on the evidence provided, with each claim tied to a source. 4. Whitespace and threats relevant to the client's decision. 5. A clearly marked list of the most important things I still need to verify or research, including any number or claim you are unsure about. Critical: if a fact, statistic, or competitor detail is not supported by the material I gave you, do not state it as fact. Either ask me for a source or label it as an assumption to confirm. Never invent a citation.
Act as a strategy consultant building a custom framework for a specific problem. Do not reach for a generic off-the-shelf model; build one that fits. The problem: [DESCRIBE THE DECISION OR PROBLEM, AND WHAT THE CLIENT IS TRYING TO SORT, CHOOSE, OR PRIORITIZE] What I have to work with: [PASTE THE OPTIONS, FACTORS, OR ITEMS THE FRAMEWORK NEEDS TO ORGANIZE] Do this: 1. Propose the two dimensions (for a 2x2) or the small set of axes or stages that best separate the items in a way that drives a decision. Explain why those dimensions, not others. 2. Define each quadrant or category in plain language, including the "so what": what the client should do about items that land there. 3. Place my actual items into the framework based on the data, and flag any that are ambiguous or sit on a line. 4. Name the framework something memorable and client-ready. 5. State the framework's limits: what it deliberately ignores and where it could mislead. The test of a good framework is that it changes a decision. If the dimensions you picked do not, say so and propose better ones.
You are a consultant building a hypothesis tree (issue tree) for a client problem. The goal is a MECE breakdown that tells me what to test, in what order. The core question: [STATE THE CLIENT'S CENTRAL QUESTION AS A SINGLE DECISION, e.g. "How do we grow segment X revenue 20% in 12 months?"] What I already know: [PASTE ANY CONTEXT, DATA, OR CONSTRAINTS] Build the tree: 1. Decompose the core question into the key sub-questions or drivers, aiming for mutually exclusive and collectively exhaustive branches. Note where perfect MECE is not realistic and why. 2. Under each branch, state the specific hypothesis we would test and the analysis or data needed to confirm or kill it. 3. Prioritize: which branches are highest-impact and fastest to test first, so I sequence the work and avoid analyzing everything. 4. Flag any branch where I likely lack the data, so I can plan to get it. 5. Identify the one or two hypotheses that, if true, would most change the answer. Keep the logic clean and the tree no deeper than it needs to be. Do not assert findings; this is a structure for investigation, not a conclusion.
Act as an advisor building a stakeholder map and engagement plan for a consulting engagement. Use only what I tell you about these people; do not invent personalities. The stakeholders (paste; use roles, not names, if anonymizing): [FOR EACH: ROLE, WHAT THEY CARE ABOUT, LIKELY STANCE ON THE WORK, INFLUENCE LEVEL, ANY KNOWN HISTORY] The engagement and the change it implies: [DESCRIBE] Produce: 1. A stakeholder map along influence and support: who is a champion, who is a blocker, who is a swing vote, who is along for the ride. Place each person and justify the placement from what I told you. 2. For each key stakeholder, what they need to hear, what they fear, and the one thing that would move them. 3. A prioritized engagement plan: who to bring along first, who to never surprise, and where coalitions matter. 4. The two or three relationship risks most likely to derail the work, and an early move to defuse each. 5. Questions I should answer about these people before I rely on this map. Be candid about politics without being cynical. Where my input on a person is thin, mark the read as low-confidence rather than overstating it.
You are a consultant structuring a client deck. The goal is a storyline that builds to a recommendation, not a stack of disconnected slides. What I have (paste): - The audience and the decision they need to make: [DESCRIBE] - My key findings and the recommendation: [PASTE] - The evidence behind each: [PASTE OR SUMMARIZE] Build the deck: 1. State the single governing thought: the one sentence the whole deck proves. If my inputs do not support a clean one, tell me. 2. Lay out a slide-by-slide outline. For each slide give the action title (a full-sentence takeaway, not a topic label), the one message it lands, and the evidence or chart it shows. 3. Sequence the slides as an argument: situation, complication, the question, then the answer and the path to it. Make the logic flow so each slide earns the next. 4. Mark the few slides that carry the real weight versus supporting detail that could move to an appendix. 5. Flag any place where the story outruns the evidence I gave you. Use action titles throughout. Do not pad the deck; a tight 12 slides beats a loose 30. The argument has to hold even if someone reads only the titles.
Act as a consultant writing the executive summary for a deliverable. Write for a senior leader who will read this page and maybe nothing else. The material (paste): - The question we were engaged to answer: [STATE IT] - Key findings: [PASTE] - The recommendation and the actions it implies: [PASTE] - Risks, costs, or trade-offs: [PASTE] Write a one-page executive summary: 1. Open with the answer. State the recommendation and the headline "so what" in the first three sentences. No throat-clearing. 2. Give the three or four findings that justify it, each in a tight sentence or two, most important first. 3. State what to do next: the specific actions, owners if known, and rough sequencing. 4. Be honest about the main risk or trade-off and how to manage it. 5. Keep it to a page, in plain executive language, with no jargon and no em dashes or en dashes. Lead with the conclusion, not the journey. Use only what I gave you, and if a claim is not supported by my inputs, leave it out rather than inflating the case.
Act as a skeptical senior partner reviewing my deliverable before it goes to the client. Be tough. Your job is to find the holes I will get caught on, not to praise it. The deliverable (paste the draft, or the deck outline and key claims): [PASTE] The audience and what they will scrutinize: [DESCRIBE, e.g. a CFO who will challenge every number] Pressure-test it: 1. Logic: where does the argument not actually follow? Find leaps where a conclusion outruns its evidence. 2. Gaps: what obvious question does this fail to answer? What is missing that a sharp client will immediately ask for? 3. Evidence: which claims rest on thin or unstated support, and which numbers should be double-checked before this ships? 4. Internal consistency: any place the document contradicts itself or where a number on one page disagrees with another. 5. The hardest question: the single most dangerous question this invites, and whether the deliverable can withstand it. 6. The "so what" test: does each section drive to a decision, or is anything just interesting but inert? Be specific and unsparing. Quote the exact line where each issue lives. Where you flag a number to check, say so plainly; do not silently assume it is right. This is the review that keeps me from getting embarrassed in the room.
Drop these into a Claude Project loaded with your practice's context: your methodology, your proposal and SOW templates, your framework library, your past deliverables, and a short voice guide. With those inputs, the prompts above produce drafts that sound like you and inherit your standards, far better than running them in a blank Claude chat.
See the best AI tools for consultants in 2026 for the wider stack, or have Treetop build the Claude Project for your practice.