This pack is organised around the engagement itself, from the first discovery call to the close-out conversation. It covers the work consultants repeat on every project: scoping and SOWs, RFP responses, issue trees and root-cause analysis, stakeholder maps and interview guides, pyramid-principle storylines and action titles, workshops, options appraisals, change impact and weekly client updates. In total there are 55 prompts in eight sections, each a distinct job rather than a variation on "write a SWOT".
Each prompt sets a role, asks for your specifics as {{VARIABLES}}, states the rules and specifies the output, so it works the same in ChatGPT, Claude and Gemini. Three things set the pack apart. Many prompts work from anonymised inputs, with labels such as Client A or role codes, and the how-to below shows how to prepare them. Over half the prompts use four flags, [NEEDS SOURCE], [INFERRED], [TO CONFIRM] and NO EVIDENCE, so you can see what to check before anything reaches a client; the market prompts add a line for models that can browse. And four prompts come with worked examples on fictional inputs, so you can judge the output before you use it.
Scoping, Proposals & Statements of Work
Most engagements go wrong in the first two weeks, when the problem is vague and the scope is loose. These prompts prepare discovery calls, turn a muddy brief into a problem statement, draft a scope with explicit exclusions, structure a proposal around the client's problem, expose hidden assumptions and help you decide whether a bid is worth writing, answer an RFP against its scoring criteria and compare fixed, capped and phased fee options from your own numbers. Contract terms stay with you.
Best for: Preparing a discovery call that finds the real problem
You are an experienced engagement lead preparing for a first discovery call with a prospective client. I want questions that expose the real problem before I price anything.
Context (anonymised, no client names): {{CLIENT_CONTEXT}}
Type of engagement being discussed: {{ENGAGEMENT_TYPE}}
Symptoms the client has described so far: {{STATED_SYMPTOMS}}
Write the question bank:
1. Ten opening questions that separate the stated problem from the underlying one. Include at least two that ask what has already been tried and why it did not stick.
2. Five questions on decision-making: who signs, who can block, what budget exists, what the timeline is driven by.
3. Five questions that test whether the client is ready to act on recommendations (capacity, politics, data access).
4. Three questions that would tell me to walk away.
5. For each section, add one line on what a worrying answer sounds like.
Rules: no leading questions, no jargon, one question per line. Don't assume facts about the client's industry beyond what I gave you; where you assume something, say so in brackets.
Output: four headed lists, followed by a short "red flags to listen for" list.
Fill in: CLIENT_CONTEXT ENGAGEMENT_TYPE STATED_SYMPTOMS
Use before a first call, then keep your notes in the same four headings.
Best for: Framing a loose brief before work starts
Act as a consulting partner who has seen many badly framed briefs. Turn the raw brief below into a problem statement a team could work on.
Raw brief, pasted as received with names replaced by labels: {{RAW_BRIEF}}
What the client says success looks like: {{SUCCESS_VIEW}}
Hard constraints (time, budget, politics): {{CONSTRAINTS}}
Produce:
1. The question behind the brief, in one sentence, in the form "How should [who] decide [what] by [when]?"
2. Three alternative readings of the brief that would lead to different work, with one line on what each would cost the client if we picked wrong.
3. A problem statement with these fields: situation, complication, key question, scope in, scope out, decision-maker, deadline.
4. Open points I must confirm with the client before this is final. Mark anything you inferred rather than read in the brief as [INFERRED].
5. Two sentences I can read back to the client to confirm we agree.
Do not invent facts, numbers or context. If the brief is too thin to fill a field, write NO EVIDENCE and tell me what to ask.
Output: the five numbered parts, with part 3 as a two-column table.
Fill in: RAW_BRIEF SUCCESS_VIEW CONSTRAINTS
Use the read-back sentences on a call or in an email to lock the framing.
Best for: Writing a scope section that prevents scope creep
You are a consultant drafting the scope section of a statement of work. Your goal is to prevent misunderstandings, not to impress.
Engagement objective: {{OBJECTIVE}}
Type of engagement (so the exclusions fit it): {{ENGAGEMENT_TYPE}}
Activities I plan to carry out: {{ACTIVITIES}}
Deliverables the client expects: {{DELIVERABLES}}
Client responsibilities I need to rely on: {{CLIENT_INPUTS}}
Timeline and review points: {{TIMELINE}}
Draft the scope section with these headings:
1. Objective (two sentences).
2. In scope: activities, each tied to a deliverable.
3. Deliverables: for each, format, who reviews it, and an acceptance test written as something observable ("accepted when the client confirms the findings in writing"), not "to the client's satisfaction".
4. Out of scope: eight to twelve items clients on this type of engagement often assume are included but that my activities do not cover; mark any you are unsure of [TO CONFIRM].
5. Client responsibilities and what happens to the timeline if they slip.
6. Change handling: a plain-language process for requests outside this scope.
Rules: use plain words. Do not add legal clauses, liability limits, IP terms or fees; I will take those to my lawyer and my own contract template. Flag any place where my inputs conflict or are ambiguous.
Output: the six headings with short paragraphs and bullets.
Fill in: OBJECTIVE ENGAGEMENT_TYPE ACTIVITIES DELIVERABLES CLIENT_INPUTS TIMELINE
Treat as the scope paragraph only; contract terms stay with your solicitor or template.
Best for: Drafting a proposal that starts from the client's problem
Act as a consultant who wins work by showing they understand the problem better than the client expected. Draft the structure and first-pass copy for a proposal.
Client situation in my words, anonymised: {{CLIENT_SITUATION}}
Our proposed approach in rough steps: {{APPROACH_STEPS}}
Relevant experience I can honestly claim: {{RELEVANT_EXPERIENCE}}
Fee and payment terms I have already decided (copy exactly): {{FEES_AND_TERMS}}
Write the proposal in this order:
1. Our understanding: what we heard, the underlying issue and why it matters now. Maximum 150 words.
2. What a good outcome looks like, in terms the client's board would recognise.
3. Approach: phases with the purpose, activities, outputs and client involvement for each.
4. Team and roles. Use placeholders for names.
5. Timeline in weeks, as a simple table.
6. Investment: reproduce my fee wording exactly; do not calculate, suggest or change any number.
7. Risks and how we will manage them.
8. Next steps.
Do not invent case studies, client names, credentials or results. If my experience input is thin, say so and suggest how I could evidence it.
Output: proposal headings with draft copy under each.
Fill in: CLIENT_SITUATION APPROACH_STEPS RELEVANT_EXPERIENCE FEES_AND_TERMS
Pricing stays your call; the prompt copies your fee text and never suggests numbers.
Best for: Finding hidden risks before you sign
You are a delivery-minded consultant reviewing a draft proposal for hidden assumptions that could turn into free work or a missed deadline.
Draft approach and timeline: {{DRAFT_APPROACH}}
What I am assuming about the client: {{CLIENT_ASSUMPTIONS}}
Team and capacity I plan to use: {{TEAM_CAPACITY}}
Do this:
1. List every assumption the plan depends on, grouped as: access to people, access to data, client decisions, third parties, our own capacity, and technology.
2. For each, give: the assumption written as a testable statement, what happens to scope or timeline if it is false, how I can verify it before signing, and a rating of High, Medium or Low for impact.
3. Pick the five assumptions that, if wrong, would most damage the engagement. For each write one sentence I can put in the proposal as an explicit client dependency.
4. Identify any assumptions that contradict each other.
Do not invent facts about the client. If an assumption comes from your own inference rather than my input, mark it [INFERRED].
Output: a table for steps 1 and 2, then numbered lists for steps 3 and 4.
Fill in: DRAFT_APPROACH CLIENT_ASSUMPTIONS TEAM_CAPACITY
Run it on the proposal draft, then turn the top five into stated dependencies.
Best for: Deciding which proposals are worth writing
Act as a candid advisor to an independent consultant or small firm deciding whether to pursue an opportunity. Your job is to argue against my enthusiasm as well as for it.
The opportunity, anonymised: {{OPPORTUNITY_SUMMARY}}
My relevant strengths and gaps: {{STRENGTHS_AND_GAPS}}
My current commitments and capacity: {{CAPACITY}}
What this work would need to give me beyond the fee (reference, learning, relationships): {{STRATEGIC_VALUE}}
Assess it:
1. Score each of these from 1 to 5 with a one-line reason: fit with my expertise, clarity of the problem, access to the decision-maker, client readiness, delivery risk, strategic value, and strain on my capacity.
2. Name the three strongest reasons to bid and the three strongest reasons to decline.
3. List the conditions I should set before saying yes (access, scope boundaries, payment arrangements, a named sponsor).
4. Give a recommendation of Bid, Bid with conditions, or Decline, and the one fact that would change it.
Rules: use only my inputs; do not invent market rates, win probabilities or client information. Say where you lack information and ask me up to five questions at the end.
Output: a scoring table, then the three lists and the recommendation.
Fill in: OPPORTUNITY_SUMMARY STRENGTHS_AND_GAPS CAPACITY STRATEGIC_VALUE
Use before spending a weekend on a proposal; keep your scores to compare opportunities.
Best for: Answering a formal RFP against its scoring criteria
You are a bid manager helping a small consulting firm respond to a request for proposals. The evaluators score against criteria, so the response must map to them visibly.
RFP text or requirements, pasted with buyer names replaced by labels: {{RFP_REQUIREMENTS}}
Evaluation criteria and weights as stated: {{EVALUATION_CRITERIA}}
Our genuine capabilities and relevant experience: {{OUR_CAPABILITIES}}
Page, word or format limits: {{RESPONSE_LIMITS}}
Produce:
1. A compliance matrix listing every mandatory requirement, the section where we answer it, and our status: Full, Partial or Gap. For a Gap or Partial, say what we must confirm or disclose.
2. A response outline that follows the buyer's order and weights, with a word budget per section proportional to the criteria weights.
3. A "why us" section built only from my capabilities; each claim must point to evidence I can supply, and anything I cannot evidence is marked [NEEDS SOURCE].
4. A list of questions to submit to the buyer during the clarification window.
5. A bid-risk list: ambiguous requirements, impossible deadlines, unusual terms to take to a solicitor.
6. A final check list for submission (formatting, signatures, deadline placeholders [TO CONFIRM]).
Never invent credentials, case studies, references or team members. Output: the matrix as a table, then the outline, why-us draft, questions and risks.
Fill in: RFP_REQUIREMENTS EVALUATION_CRITERIA OUR_CAPABILITIES RESPONSE_LIMITS
Run steps 1 and 2 first; draft why-us only after you have confirmed the gaps.
Best for: Presenting fee options with transparent logic
Act as a pricing adviser to an independent consultant. I want fee structures I can explain to the client. Don't supply market rates or say what I should charge.
Scope summary: {{SCOPE_SUMMARY}}
My estimate of effort in days, by phase: {{EFFORT_BY_PHASE}}
My day rate (the figure I have decided): {{DAY_RATE}}
What the outcome is worth to the client, in their words and figures: {{CLIENT_VALUE}}
Main uncertainties that could change effort: {{UNCERTAINTIES}}
Produce:
1. Three fee structures: fixed fee, time-and-materials with a cap, and phased fee with a gate after discovery. For each, show the arithmetic from my days and day rate, step by step, and state the total.
2. For each, who carries the risk, when the client pays, and what behaviour it encourages.
3. A contingency in days tied to my uncertainties, shown separately from the rate.
4. A plain-English paragraph per option for the proposal.
5. Questions about budget and approval to ask the client before I present.
Rules: use only my numbers; show every calculation and check it twice. Mark assumptions [INFERRED]. Don't value the outcome beyond the client's own figures. Output: a comparison table, then the paragraphs and questions.
Fill in: SCOPE_SUMMARY EFFORT_BY_PHASE DAY_RATE CLIENT_VALUE UNCERTAINTIES
Show the sums to the client if asked; the structure matters more than any one total.
Issue Trees & Hypothesis-Driven Problem Solving
Structure first, data second. Build an issue tree, stress-test it for overlaps and gaps, turn branches into falsifiable hypotheses with kill criteria, trace a recurring problem to its root cause, plan the analyses that decide them, request the right data from the client and size things roughly without passing off guesses as market facts. Every prompt marks assumptions so they are checked before they reach a slide.
Best for: Structuring an open-ended client question
You are a problem-solving coach trained in structured, hypothesis-driven consulting. Build an issue tree for the question below.
Key question: {{KEY_QUESTION}}
Context in a few lines (anonymised): {{CONTEXT}}
Type of question (e.g. profit decline, market entry, cost reduction, process failure): {{QUESTION_TYPE}}
Build the tree:
1. Restate the key question so it is specific, has an owner and a measure of success. Flag if the question as given is not answerable.
2. Break it into three to five first-level branches that are mutually exclusive and collectively exhaustive. State the logic used to split it (for example, revenue versus cost, or steps in a process).
3. Break each branch down to a third level, stopping where an analysis could answer the question or a person could be asked.
4. Mark the five leaves that are most likely to matter, based only on the context I gave, and say why. Label these [INFERRED], not facts.
5. List what is deliberately left out of the tree.
Do not state any numbers or industry benchmarks. Where a branch would need data, write "DATA NEEDED:" and name the data.
Output: an indented text tree using numbering such as 1, 1.1, 1.1.1, then the short lists for steps 4 and 5.
Fill in: KEY_QUESTION CONTEXT QUESTION_TYPE
Paste the tree into a whiteboard or slide, then prune it with the client.
Best for: Making sure a problem structure holds up
Act as a sceptical partner reviewing a junior team's issue tree. Be precise, not polite.
The tree as I drafted it: {{ISSUE_TREE}}
The question it answers: {{KEY_QUESTION}}
Review it:
1. Overlaps: find any pair of branches where one item could sit under both. Quote the items and propose a cleaner split.
2. Gaps: name what is missing, so the branches do not cover the whole question. Give two concrete examples of cases that would fall through.
3. Mixed logic: spot places where a single level splits the problem in more than one way (for example, by region and by product at once).
4. Depth: identify branches that are too shallow to act on and branches that go deeper than the question needs.
5. Wording: flag any item that is a topic rather than something that can be tested true or false.
6. Give me a corrected version of the tree with changes marked as changed.
Constraints: don't add facts about the client's industry; only reorganise and challenge what I gave you. If the tree is sound, say so and list the three things you checked.
Output: numbered findings referring to branch numbers, then the corrected tree.
Fill in: ISSUE_TREE KEY_QUESTION
Run this before showing any tree to a client; it catches overlaps you stop seeing.
Best for: Starting week one with testable hypotheses
You are an engagement manager setting up hypothesis-driven work for the first week. Convert the key question and issue branches below into testable hypotheses.
Key question: {{KEY_QUESTION}}
Issue-tree branches to cover: {{BRANCHES}}
What we already know, in short bullets: {{KNOWN_FACTS}}
For each branch, write:
1. A hypothesis stated as a falsifiable claim with its reason ("Churn is driven mainly by weak onboarding because..."), not a vague area.
2. What would need to be true for it to hold, in two or three conditions.
3. The evidence that would support it and the evidence that would kill it (kill criteria). Be specific about what we would see.
4. The fastest test: an interview, a data cut, a document review or a site visit.
5. Confidence today (Low, Medium or High) based only on the known facts. Say why.
Then rank the hypotheses by (a) potential impact on the answer and (b) speed of testing, and recommend the order of work for week one.
Rules: do not cite statistics or "typical" industry figures. If a hypothesis needs a benchmark, write [NEEDS SOURCE] instead. Treat everything as provisional.
Output: one table with a row per hypothesis, then the ranked order.
Fill in: KEY_QUESTION BRANCHES KNOWN_FACTS
Update the sheet each week; a killed hypothesis is progress, not failure.
Example output · Claude (example written by The Prompt Index)
Sample inputs (fictional)
- KEY_QUESTION: Why has on-time delivery at Client A, a regional parts distributor, fallen over the past two quarters, and what should the operations director fix first?
- BRANCHES: (1) Inbound supply, (2) Warehouse picking and packing, (3) Outbound transport, (4) Order and planning process
- KNOWN_FACTS: Complaints rose after the new warehouse management system went live. Two carriers were replaced in the same period. Sales says order volume is flat. Operations says late orders cluster on Mondays and Tuesdays. No one has measured delay by cause.
Hypothesis sheet (all provisional)
| Branch | Hypothesis | Must be true | Supports it | Kills it | Fastest test | Confidence today |
|---|---|---|---|---|---|---|
| 1 Inbound supply | Late supplier deliveries are leaving the warehouse short of stock for orders that were promised on time, because supplier lead times have lengthened | Stock-outs at order release are a meaningful share of late orders; supplier lead times lengthened recently | Late orders trace back to "awaiting stock" status; supplier receipt dates slipped in the same weeks | Late orders were fully in stock on the promised date | Cut late orders by status at release (data pull) | Low. Nothing in the facts points here |
| 2 Warehouse | The new WMS changed pick sequencing, so Monday and Tuesday waves are not cleared before cut-off, because Monday carries the weekend backlog | Pick waves are generated differently since go-live; Monday backlog carries from weekend orders | Orders late on Mon/Tue were released on time but shipped after cut-off; pick times rose after go-live | Time from release to dispatch is unchanged before and after go-live | Compare release-to-dispatch times for six weeks before and after go-live (data pull); walk the Monday shift | Medium. Timing fits the go-live and the Monday pattern |
| 3 Transport | The replacement carriers miss delivery windows more often than the old ones, because they cover the routes with less capacity | Delivery performance differs by carrier; the carrier switch preceded the decline | Late delivery rate is higher for the new carriers on the same routes | Late rates are similar across carriers, or lateness occurs before handover | Late rate by carrier and route, after handover only (data pull); two carrier calls | Medium. Two changes happened together |
| 4 Planning | Promised delivery dates are set without regard to warehouse capacity, so lateness is built in, because the promising rules use standard lead times only | Promise dates ignore daily pick capacity; Monday promises exceed capacity | Orders were late against a promise the warehouse could not meet; promise logic uses standard lead times only | Promise logic already checks capacity and was unchanged | Interview the order desk lead; read the date-promising rules | Low |
Priority and order of work for week one
1. Branch 2 (high impact, fast): one data cut and a Monday shift visit can confirm or kill it within two days.
2. Branch 3 (high impact, fast): the carrier cut is a single pivot of existing data, and it separates the two changes that happened together.
3. Branch 4 (medium impact, slower): needs two interviews and a read of the rules.
4. Branch 1 (lower likelihood, easy to check): run the stock-status cut alongside the first two so it can be dropped quickly.
Notes
- Several hypotheses may be partly true. The data cuts should split late orders by cause before we decide what to fix first.
- [NEEDS SOURCE] no benchmark for acceptable on-time delivery has been used. If the client wants one, we should get it from their contracts or an industry body, not from this sheet.
- If branches 2 and 3 are both killed, the problem is probably in how lateness is measured, so check the on-time definition with the client before anything else.
Best for: Planning analysis before the data lands
Act as an analytics lead on a consulting team. I have hypotheses and need an efficient analysis plan, not a long list of everything we could do.
Hypotheses to test: {{HYPOTHESES}}
Data we have or can request: {{AVAILABLE_DATA}}
Time available for analysis: {{ANALYSIS_TIME}}
Create the plan:
1. For each hypothesis, specify the single most decisive analysis: the comparison to make, the metric, the cut (by segment, time, location), and the result that would support or refute the hypothesis.
2. Sketch the chart each analysis would produce (axes, what is compared) so the team can build a dummy page now.
3. Note data quality risks per analysis: definitions that may differ, missing periods, small sample sizes.
4. Sequence the analyses so early ones can reshape later ones, and mark any that can be dropped if time runs short.
5. List the questions to ask the client's data owner before we start.
Rules: do not produce results, example numbers or benchmarks; this is a plan, so any figure shown must be marked [INFERRED]. Do not recommend methods that need data we have not listed unless you flag it as a request.
Output: a table with columns Hypothesis, Analysis, Chart sketch, Data risk, Priority; then the sequence and the questions.
Fill in: HYPOTHESES AVAILABLE_DATA ANALYSIS_TIME
Build dummy slides from the chart sketches before any data arrives.
Best for: Getting data from client teams without chasing
You are a consultant writing a data request to a client's finance and operations contacts. Requests that are vague get ignored, so make this easy to answer and easy to prioritise.
Engagement purpose in one line: {{PURPOSE}}
Analyses we plan to run: {{PLANNED_ANALYSES}}
Systems or reports the client has mentioned: {{CLIENT_SYSTEMS}}
Confidentiality constraints (for example no personal data, no named customers): {{CONFIDENTIALITY_RULES}}
Draft:
1. A request table with columns: ID, item, why we need it (tied to an analysis), preferred format, period, priority (Must have this week, Useful, Nice to have), and who might hold it (job title, not a name).
2. Alternatives: for each Must-have item, a fallback if it does not exist in that form.
3. A short cover note in a polite, direct tone, explaining the order of priority, offering a 20-minute call to clarify, and stating the data-handling rule so nobody sends personal or restricted data by accident.
4. A tracker row layout I can paste into a spreadsheet (ID, date requested, date received, quality check, status).
Rules: keep the list under 25 items; merge anything that does not change the analysis. Do not request personal data unless I listed it.
Output: the table, fallbacks, cover note, then tracker columns.
Fill in: PURPOSE PLANNED_ANALYSES CLIENT_SYSTEMS CONFIDENTIALITY_RULES
Send the cover note with the table attached; track chasers in the same IDs.
Best for: Quick sizing without inventing market data
Act as a consulting analyst who must size something quickly for a hypothesis check, with no false precision.
What I need to estimate: {{ESTIMATE_TARGET}}
Facts I actually have, each with its source: {{KNOWN_INPUTS}}
Unit and time frame wanted (for example annual revenue, number of sites): {{UNIT_AND_PERIOD}}
Build the estimate:
1. Propose two different routes (for example top-down and bottom-up) and describe the logic of each as a chain of multiplications or additions, using words first.
2. For every input in each chain, mark it as GIVEN (from my facts) or ASSUMED. For each ASSUMED input give a low, middle and high placeholder range that I should replace, and write [NEEDS SOURCE] next to it. Don't present assumed values as real market data.
3. Show the arithmetic step by step using my GIVEN values and the placeholders, labelled "illustrative, not a market figure".
4. Compare the two routes and explain what a large gap between them would tell us.
5. Identify which three assumptions drive most of the answer and how to check each in under a day.
Output: the two chains in tables, the sensitivity note, and a one-line honest summary of what the estimate can and cannot support. Never imply the output is a market figure.
Fill in: ESTIMATE_TARGET KNOWN_INPUTS UNIT_AND_PERIOD
The result is a conversation starter; replace each assumption with a sourced figure before it reaches a client.
Best for: Finding the cause behind a recurring problem
Act as an operations consultant leading a root-cause analysis. Symptoms are tempting, so I need chains of cause that are tested against evidence, not guessed.
The problem, stated factually with when and where it occurs: {{PROBLEM_STATEMENT}}
What we have observed or measured (list each item, including its source): {{OBSERVED_FACTS}}
The process or system involved: {{PROCESS_OR_SYSTEM}}
Do the analysis:
1. Check the problem statement: is it specific, measurable and free of an implied cause? Rewrite if not.
2. Build a branching why-chain with at least three levels, using five whys as a guide and allowing more than one cause per level. Group first-level causes under people, process, systems, inputs and environment, only where relevant.
3. For each cause, mark the evidence that supports it from my list, or NO EVIDENCE.
4. Classify each cause as Root cause, Contributing factor or Symptom, and explain the test (if we fixed this, would the problem stop?).
5. For each root cause candidate, name the cheapest check (data cut, observation, record review) and what result would rule it out.
6. Separate containment actions (stop the bleeding) from corrective actions (remove the cause).
Output: the indented why-chain with evidence tags, then a table of candidates and checks, then the two action lists. Do not present any candidate as proven.
Fill in: PROBLEM_STATEMENT OBSERVED_FACTS PROCESS_OR_SYSTEM
Stop at causes the client can act on; do not chase blame. Long prompt: run it in two steps, asking for the first half of the numbered outputs, then the rest.
Stakeholder Interviews & Synthesis
Interviews often decide whether a diagnostic is honest. Map stakeholders by influence and stance, plan who to talk to and in what order, run a sponsor interview and a frontline interview differently, code messy notes into themes with counts, treat contradictions as evidence and write the readout without exposing anyone. All inputs are anonymised and the prompts forbid invented quotes.
Best for: Choosing interviewees who give a true picture
You are an engagement manager planning the interview phase of a diagnostic. I need a programme that covers the whole organisation without wasting senior time.
Engagement question: {{KEY_QUESTION}}
Roles and groups in the client organisation, by title only: {{ROLES_AVAILABLE}}
Number of interviews we can realistically run, and over how many days: {{INTERVIEW_CAPACITY}}
Plan the programme:
1. Choose the interviewees by group and explain what each group can tell us that the others cannot. Include at least one person who is likely to disagree with the sponsor and one person close to the customer or the work itself.
2. Sequence the interviews: who goes first (to calibrate), who goes last (to test emerging themes), and why.
3. Set a length for each interview type and a note on whether it should be one-to-one or a small group.
4. List the risks to candour (reporting lines, fear of consequences) and how to reduce each one, including how we describe confidentiality in the invitation.
5. Draft a three-sentence invitation that explains purpose, length and how comments will be used, without promising anything we cannot guarantee.
Use titles only; do not ask for or invent names. Output: a table of groups with rationale and sequence, then the risks and the invitation.
Fill in: KEY_QUESTION ROLES_AVAILABLE INTERVIEW_CAPACITY
Agree the list with the sponsor, but keep the right to add a dissenting voice.
Best for: Interviewing a senior sponsor with limited time
Act as a senior consultant preparing to interview the executive sponsor of an engagement. They are busy and used to hearing what they expect, so the questions need to be sharp.
What I know about the sponsor's role and priorities (anonymised): {{SPONSOR_CONTEXT}}
Engagement objective: {{OBJECTIVE}}
The thing I most need to learn or confirm: {{KEY_UNKNOWN}}
Interview length: {{LENGTH_MINUTES}} minutes
Write the guide:
1. A two-minute opening script that sets the purpose and explains how their comments will be handled.
2. Twelve questions in a sensible flow from context and ambition, to obstacles, to history of past attempts, to personal stakes, to what they would never accept.
3. For the three most important questions, add a follow-up probe and a "silence prompt" to draw out more.
4. A closing sequence that asks who else we should speak with, what we have not asked, and what they would do if this fails.
5. Time boxes for each section that add up to the length given.
6. A short list of things I must not do in the room (such as proposing solutions or agreeing with criticisms of colleagues).
Make no assumptions about the sponsor's views beyond my notes. Output: the guide with time boxes, then the do-not list.
Fill in: SPONSOR_CONTEXT OBJECTIVE KEY_UNKNOWN LENGTH_MINUTES
Take only the guide and a blank notes page into the room.
Best for: Getting the truth about how the work really happens
You are a consultant interviewing staff who do the work, not those who manage it. They may suspect that we are here to cut jobs, so the first minutes matter.
Process or team being examined: {{PROCESS_OR_TEAM}}
What leadership believes the problem is: {{LEADERSHIP_VIEW}}
What I want to understand about the real work: {{WORK_QUESTIONS}}
Interview format (one-to-one, pair, or small group) and length: {{FORMAT_AND_LENGTH}}
Create the guide:
1. An opening script that explains the purpose in plain language, says what we will and will not share, and invites them to correct us.
2. Ten questions about a recent real example ("walk me through the last time...") rather than opinion, followed by questions about workarounds, handovers, the tools they actually use and what makes a good day or bad day.
3. Four questions that let them say what leadership gets wrong, phrased so that they do not feel they are criticising anyone.
4. Prompts for a group setting that stop one voice dominating.
5. Ways to recognise guarded answers and what to ask next.
6. A closing that asks for one change they would make this month.
Do not state or suggest conclusions about what the staff will say. Output: the guide in sections, with the closing and the group-setting notes at the end.
Fill in: PROCESS_OR_TEAM LEADERSHIP_VIEW WORK_QUESTIONS FORMAT_AND_LENGTH
Anchor on specific recent examples to get past polite, generic answers.
Best for: Turning messy interview notes into evidence
Act as a research analyst coding qualitative interview notes for a consulting team.
Anonymised notes from {{INTERVIEW_COUNT}} interviews, each labelled with a role code, not a name: {{INTERVIEW_NOTES}}
The question we are trying to answer: {{KEY_QUESTION}}
Code and analyse:
1. Read all notes and propose as many themes as the notes support, up to ten, and no more. Define each in one sentence.
2. For each theme, list which role codes mentioned it, the number of interviews that did, and one short verbatim quote from the notes. Use exact wording from the notes only; if you paraphrase, label it (paraphrase).
3. Separate what interviewees said they observed from what they believe or suspect.
4. Flag themes raised by only one person but with high potential impact, and mark them as single source.
5. Note what the notes do not cover that the key question needs.
6. Suggest three follow-up questions that would test the strongest themes in the next round.
Rules: don't invent quotes, don't infer motives, and don't count an interview for a theme unless the notes support it. Counts are of mentions in these notes only, not statements about the wider organisation.
Output: a theme table (theme, definition, roles, count, quote), then the lists for steps 4 to 6.
Fill in: INTERVIEW_COUNT INTERVIEW_NOTES KEY_QUESTION
Remove names before pasting; keep role codes so you can see which groups hold each view.
Example output · Claude (example written by The Prompt Index)
Sample inputs (fictional)
- INTERVIEW_COUNT: 5
- KEY_QUESTION: Why do new customer accounts take so long to be activated at Client B, a business broadband provider?
- INTERVIEW_NOTES:
SALES-1: "Customers think they are live once they sign." "Sales is not told when installs slip."
SALES-2: "I hear about delays from angry customers first." "I think credit checks are slow."
OPS-1: "Installs are booked when the engineer calendar opens." "About half the orders arrive without site access details."
OPS-2: "Credit checks are quick; the delay is access details." "Finance sometimes holds an order for a manual check I don't understand."
FIN-1: "Manual checks apply to orders over a threshold set years ago." "I'm not sure anyone reviews it."
Themes (6)
| Theme | Definition | Roles | Interviews | Quote |
|---|---|---|---|---|
| Missing site access details | Orders reach operations without information engineers need | OPS-1, OPS-2 | 2 of 5 | "About half the orders arrive without site access details." (OPS-1) |
| Sales cannot see delays | Sales learns about install slippage late or from customers | SALES-1, SALES-2 | 2 of 5 | "I hear about delays from angry customers first." (SALES-2) |
| Manual finance holds | Some orders pause for checks whose rules are unclear | OPS-2, FIN-1 | 2 of 5 | "Manual checks apply to orders over a threshold set years ago." (FIN-1) |
| Credit check speed (disputed) | Interviewees disagree on whether credit checks are slow | SALES-2, OPS-2 | 2 of 5 | "I think credit checks are slow." (SALES-2) against "Credit checks are quick; the delay is access details." (OPS-2) |
| Customer expectation gap | Customers believe service starts at signature | SALES-1 | 1 of 5 (single source) | "Customers think they are live once they sign." (SALES-1) |
| Engineer scheduling lag | Installs wait for engineer calendar availability | OPS-1 | 1 of 5 (single source) | "Installs are booked when the engineer calendar opens." (OPS-1) |
Said from direct work versus believed
- From their own work: OPS-1 on engineer booking and access details (the "about half" figure is a recollection, not a measurement); OPS-2 on manual holds; FIN-1 on the threshold rule.
- Belief or suspicion: SALES-2 on credit checks ("I think"), contradicted by OPS-2; FIN-1's "I'm not sure anyone reviews it".
Single-source themes with possible high impact
- Customer expectation gap (SALES-1) and engineer scheduling lag (OPS-1). Either could explain long activation even if every other step were fixed.
Not covered by the notes
No customer, engineer or credit-check team member was interviewed. Nothing here measures how long any step takes.
Follow-up questions
1. For the last 20 delayed orders, which step was each waiting on and for how many days?
2. Who owns the manual-check threshold, and when was it last reviewed?
3. What do the contract and welcome email say about when service starts?
Counts are of mentions in these five interviews only, not measures of the wider organisation.
Best for: Using disagreement between stakeholders as evidence
You are a consultant who knows that contradictions between stakeholders are data, not noise. Analyse the summaries below to expose them.
Summaries of what each stakeholder group said, anonymised: {{STAKEHOLDER_SUMMARIES}}
The decision the client must make: {{DECISION}}
Analyse:
1. List each direct contradiction: the topic, group A's account, group B's account, and a neutral description of the gap.
2. For each, propose three possible explanations: different information, different incentives, and different definitions of the same word. Say which explanation looks most plausible from the text and what supports it.
3. Specify the cheapest way to find out who is right (a document, a data cut, a site visit, a follow-up question).
4. Mark which contradictions matter for the decision and which are noise.
5. Identify any topic where everyone agrees but the agreement may hide an unspoken assumption.
6. Draft two sentences for each important contradiction that I could use in a readout without blaming anyone.
Do not take sides without evidence in the summaries. If evidence is absent, say NO EVIDENCE. Output: a table of contradictions with explanation and test, then the neutral readout lines.
Fill in: STAKEHOLDER_SUMMARIES DECISION
Resolve the high-impact contradictions before building recommendations.
Best for: Reporting what you heard while protecting sources
Act as a consultant writing the interview findings page of a client report. The reader is a sponsor who will want to know who said what; our job is to protect sources and keep the evidence honest.
Coded themes with counts and role codes: {{CODED_THEMES}}
Engagement question: {{KEY_QUESTION}}
Confidentiality promise we gave interviewees: {{CONFIDENTIALITY_PROMISE}}
Group sizes (to judge whether any group is small enough to identify people): {{GROUP_SIZES}}
Produce:
1. A one-paragraph summary of what we heard, in plain words, with no unsupported claims.
2. A themes section: for each theme, the headline as a full sentence, how widely it was raised (use words such as "most", "several" or "one" matched to my counts, never percentages), a short anonymised quote, and the implication for the client.
3. A "where views differ" section that describes the split without naming groups smaller than five people.
4. A caveat paragraph that says how many interviews this rests on, who was not heard, and that interviews capture perception, not measured fact.
5. A list of anything in the input that could identify an individual, and how you changed it.
Do not add facts that are not in my themes. Output: the four sections in client-ready prose, then the anonymity audit.
Fill in: CODED_THEMES KEY_QUESTION CONFIDENTIALITY_PROMISE GROUP_SIZES
Check the anonymity audit before sending; small groups are easy to identify.
Best for: Working out who matters and what each needs
You are a consulting partner building a stakeholder map at the start of an engagement. It is for our team only and must not be shared with the client.
Engagement goal and the change at stake: {{ENGAGEMENT_GOAL}}
Stakeholders listed by role title only, with what I know about each: {{STAKEHOLDER_ROLES}}
Known history, alliances and past failed attempts: {{KNOWN_HISTORY}}
Create:
1. A table with columns: role, interest in the outcome (High, Medium, Low), influence over the outcome (High, Medium, Low), likely stance (Champion, Supporter, Neutral, Sceptic, Opponent), the reason for each rating, and the evidence for it from my notes. Mark any rating you inferred without evidence [INFERRED].
2. A grid placing each role in one of four quadrants (manage closely, keep satisfied, keep informed, monitor).
3. For each of the five most important roles: what they need from us, what they fear, and the engagement action I should take in the first two weeks.
4. Hidden stakeholders I may have missed (people affected, gatekeepers, informal influencers), expressed as role types.
5. The questions that would confirm or overturn the ratings.
Do not use names or personal judgements about individuals; stay with roles and observed behaviours. Output: the table, the grid as text, then the action list and open questions.
Fill in: ENGAGEMENT_GOAL STAKEHOLDER_ROLES KNOWN_HISTORY
Keep it in your private notes; revisit after the interviews.
Market, Competitor & Benchmark Analysis
AI is a good structurer and a poor source of market numbers, so these prompts use it that way. Map a market's structure, compare competitors only from evidence you paste, design a fair benchmark before collecting any data, map a value chain and assess industry forces from dated, cited sources, and prepare an expert call. If your model can browse, each prompt tells it to cite sources with URL and date. None of them will give you a size, share or growth rate; they tell you where to look.
Best for: Getting oriented in an unfamiliar sector
You are a strategy consultant starting work in a market the team does not know well. I want a structure for the work, not facts the AI may have wrong.
Market or sector: {{MARKET}}
The client's position and question: {{CLIENT_QUESTION}}
Geography and time frame: {{GEOGRAPHY_AND_PERIOD}}
Build the structure:
1. Describe how this market is usually segmented (by customer type, product, channel, geography) and list the segmentation choices that matter most for the client's question.
2. List the key actors in the value chain (suppliers, producers, intermediaries, customers, regulators) with one line on what each does and how each makes money.
3. List the ten questions a well-briefed analyst would answer to understand this market, grouped as size and growth, structure, economics, customers, regulation and technology.
4. For each question, name the kinds of source that would answer it (for example trade body data, regulator filings, company reports, expert interviews). Do not name specific reports, URLs or statistics.
5. Clearly mark anything in your answer that I should verify, because your knowledge may be outdated or incomplete.
Hard rule: do not give any market size, growth rate, share or price from memory. If you can browse, list sources with URL and date; otherwise write [NEEDS SOURCE]. Output: five numbered sections with the questions in a table.
Fill in: MARKET CLIENT_QUESTION GEOGRAPHY_AND_PERIOD
Use it to design the research plan, then fill each question with sourced facts. Long prompt: run it in two steps, asking for the first half of the numbered outputs, then the rest.
Best for: Competitor comparison you can defend
Act as a competitive intelligence analyst. You will compare competitors using only the material I paste, and you will say clearly where evidence is missing.
Competitors to compare: {{COMPETITOR_LIST}}
Source material I collected (website text, annual report extracts, press releases, customer reviews, with the source noted for each): {{SOURCE_MATERIAL}}
Dimensions that matter to the client's decision: {{DIMENSIONS}}
Build the grid:
1. A table with a row per competitor and a column per dimension. In each cell write a short factual summary and a source tag taken from my labels. Where my material is silent, write NO EVIDENCE instead of guessing.
2. A second table that rates each competitor High, Medium or Low on each dimension, only where my evidence supports it, with the reason in a few words.
3. Three observations about how the competitors differ in strategy, each tied to cells in the table.
4. Evidence gaps ranked by how much they matter to the client's decision, with a suggestion of where to look.
5. Contradictions between sources, if any.
Don't add facts from memory about these companies; they may be outdated. If you can browse, put sourced extras (URL, date) in a separate table. Don't estimate revenues, headcount or share. Output: tables first, then the observation and gap lists.
Fill in: COMPETITOR_LIST SOURCE_MATERIAL DIMENSIONS
Cite your own source labels in each cell so the grid can be defended in front of a client.
Best for: Setting up a fair benchmark
You are a performance consultant designing a benchmark. The risk is comparing the client with the wrong peers or with metrics defined differently, so I want the design before any numbers are collected.
Client and function being benchmarked, anonymised: {{CLIENT_AND_FUNCTION}}
Performance question the benchmark should answer: {{PERFORMANCE_QUESTION}}
Possible data sources I have access to: {{DATA_SOURCES}}
Design it:
1. Define five to eight metrics that answer the question. For each give the exact definition, numerator and denominator, and the likely differences in how organisations count it.
2. Describe three peer-group options (for example similar size, similar customers, best in class) and the trade-off of each. Recommend one and explain why.
3. Set out normalisation rules (period, currency, scale, mix) so the comparison is fair.
4. List the ways the benchmark could mislead, such as survivorship, different accounting treatment, or one-off events.
5. Describe how to present results: chart type, how to show the range, and wording that avoids false precision.
6. List the questions to ask each data source before accepting its figures.
Rules: don't give benchmark values from memory; if you can browse, cite each with URL and date, otherwise mark [NEEDS SOURCE]. Output: a design table for the metrics, then numbered sections for the rest.
Fill in: CLIENT_AND_FUNCTION PERFORMANCE_QUESTION DATA_SOURCES
Finish the design with the client before collecting any numbers.
Best for: Finding where an industry earns its money
Act as a consultant mapping where value is created and captured in an industry, so the client can see where to play.
Industry or product category: {{INDUSTRY}}
The client's current position in the chain: {{CLIENT_POSITION}}
Strategic choice under consideration: {{STRATEGIC_CHOICE}}
Do the following:
1. Draw the value chain as an ordered list of stages from raw input to end customer. For each stage, describe the activity, the typical players, and the main source of cost and of revenue.
2. For each stage, describe qualitatively whether it looks like a high or low margin stage and why, using economic reasoning (scarcity, switching costs, scale, regulation). Mark each as [INFERRED], because I have no data yet.
3. Identify where power sits and how it has shifted or could shift.
4. For the strategic choice, show which stages the client would move into or away from, and what capabilities it would need.
5. List the data I would need to build a real profit pool (revenue and margin by stage), where it could come from, and the traps in combining sources.
Do not give margin figures, sizes or shares unless you can browse and cite URL and date. Output: a stage table with columns Stage, Activity, Players, Economics, Margin hypothesis, then the remaining sections as short bullets.
Fill in: INDUSTRY CLIENT_POSITION STRATEGIC_CHOICE
Treat the margin column as hypotheses until you have sourced numbers. Long prompt: run it in two steps, asking for the first half of the numbered outputs, then the rest.
Best for: Turning scattered research into an industry view
You are a strategy analyst. Assess the forces acting on an industry using only the evidence I paste, and show which conclusions are well supported.
Industry: {{INDUSTRY}}
Evidence extracts, each with a source label and date: {{EVIDENCE_EXTRACTS}}
Time horizon: {{TIME_HORIZON}}
Work through it:
1. Group the evidence under competitive rivalry, new entrants, substitutes, supplier power, buyer power, and external trends (regulation, technology, demand shifts).
2. For each group, write a one-line judgement of its strength (High, Medium, Low) with the evidence labels that support it. If no evidence supports a judgement, write NO EVIDENCE rather than filling the gap.
3. Distinguish trends that are already visible in the data from those that are predictions. Mark predictions and note who made them.
4. Identify the two or three forces that matter most to the client's decision and explain how they interact.
5. List the evidence that would change your view, and the evidence you would look for next.
Don't use facts from memory, as they may be outdated. If you can browse, add sourced evidence with URL and date; otherwise name what is missing. Output: a table of forces with strength and evidence labels, then the interactions and next-evidence list.
Fill in: INDUSTRY EVIDENCE_EXTRACTS TIME_HORIZON
Date every source you paste so stale evidence is easy to spot.
Best for: Using expert calls to learn quickly and ethically
You are a consultant preparing for a paid expert call. The expert's statements are opinion until verified.
Topic I need to learn: {{TOPIC}}
Expert's background as described by the network or intermediary: {{EXPERT_PROFILE}}
What I already know and what I am trying to test: {{WHAT_WE_KNOW}}
Call length in minutes: {{CALL_LENGTH}}
Write:
1. A compliance opening to read aloud: no confidential information from a current or recent employer; either of us may stop the call.
2. A call plan that fits the length, with time boxes and the order of topics.
3. Twelve questions from structure and economics to behaviour and risk, each asking for specifics ("when did you last see it?").
4. Three questions testing the expert's bias or how current their knowledge is.
5. Two ways to ask about numbers that elicit ranges and reasoning.
6. A note-taking template that records what is first-hand experience, what is opinion and what must be verified.
7. A thank-you email requesting one source.
Do not suggest asking for confidential or non-public company information. Output: the opening, the plan, the questions in groups, then the template and emails.
Fill in: TOPIC EXPERT_PROFILE WHAT_WE_KNOW CALL_LENGTH
Treat everything said on the call as a lead to verify, not a source.
Storylines, Slides & Client Writing
A deck is an argument. Build the governing thought and a pyramid storyline from your findings, rewrite topic titles as action titles, plan a ghost deck, turn analysis results into insight statements, write a one-page executive summary, brief each chart, red-team the deck with the client's hardest questions and cut a long deck down to the slides that carry the answer.
Best for: Getting from findings to a clear answer-first story
You are a communications-minded consulting partner who builds client stories with the pyramid principle: answer first, then the supporting arguments, then the evidence.
The question the client asked: {{CLIENT_QUESTION}}
Our findings so far, as a plain list (anonymised): {{FINDINGS_LIST}}
Audience and what they must decide: {{AUDIENCE_AND_DECISION}}
Build the storyline:
1. Write the governing thought: the single sentence that answers the client's question and recommends action.
2. Write three or four key supporting arguments that are logically parallel, and say whether they are grouped deductively or by category.
3. Under each argument, list the supporting findings from my list. Show any finding I gave that does not support an argument, and any argument that lacks a finding.
4. State the situation, complication and question that open the story, in three sentences.
5. Test the logic by reading the arguments back as "because" statements. List any weak links.
6. Show what the audience is likely to push back on first.
Rules: use only my findings; don't add facts, numbers or sources. If the evidence cannot support a clear answer, say so instead of forcing one. Output: a nested outline with the governing thought at the top, then the weak links and pushback list.
Fill in: CLIENT_QUESTION FINDINGS_LIST AUDIENCE_AND_DECISION
Write this before any slide; if the governing thought is weak, no layout will fix it.
Example output · Claude (example written by The Prompt Index)
Sample inputs (fictional)
- CLIENT_QUESTION: Should the regional publisher open a tender to outsource print-subscription fulfilment?
- FINDINGS_LIST: (1) The current subscription system loses vendor support at the end of next year. (2) Interviews show staff spend much of their time on manual renewals and address changes. (3) Two providers quoted; the cheaper has no newspaper experience. (4) Finance says both quotes exclude transition costs. (5) Reader complaints cluster on missed deliveries, which a separate delivery contractor handles. (6) The board will not approve a change that risks a visible service drop this winter. (7) One quote includes service-level targets for processing renewals and address changes. (8) The in-house IT team has no staff with experience of subscription billing systems.
- AUDIENCE_AND_DECISION: Managing director and board; decide whether to open a tender.
1. Governing thought
The publisher must replace its subscription system, and a tender is worth opening only alongside a costed in-house option, so the board can compare the two routes before committing. Nothing in the findings yet shows that outsourcing is the better route.
2. Supporting arguments (parallel; they cover do nothing, replace in-house, buy a service)
A. Doing nothing is not stable: vendor support ends at the end of next year (finding 1), and staff already lose time to manual renewals and address changes (finding 2).
B. Replacing in-house carries a capability risk: the IT team has no subscription-billing experience (finding 8). Its cost and plan are unknown.
C. Buying a service is feasible and can be structured to protect the publisher: service levels can be required (finding 7), provider experience can be a scored criterion (finding 3), and transition costs can be forced into the price (finding 4). Its price against the in-house route is unknown.
3. Findings mapped
- A: 1, 2. B: 8. C: 7, 3, 4.
- Not arguments: finding 5 (neither route changes delivery performance, so it belongs in the risk section) and finding 6 (the board's winter condition constrains the timing of either route, so it goes in the plan).
- Missing evidence: an in-house replacement estimate, an in-house running-cost baseline, and any evidence that either provider would perform better than the current team.
4. Opening: situation, complication, question
The publisher runs print subscriptions in-house on a system whose vendor support ends at the end of next year. Staff time goes into manual work, and the board will not accept a visible service drop this winter. The question is whether to open an outsourcing tender now.
5. Logic test, read back with "because"
Replace the system because standing still is not an option (A). A tender is worth running alongside an in-house option because both routes are feasible but neither is costed (B, C). Weak links:
- B and C each lack a cost, so the two routes cannot yet be compared. The governing thought is deliberately limited to that.
- C shows a tender can protect service, not that any provider would do the work better or cheaper.
- Finding 7 comes from one quote, so we cannot say whether service-level targets are standard.
6. Likely first pushback
"Why not just decide?" Because transition costs are excluded from both quotes and there is no in-house estimate. Before the board meeting, ask IT for a rough in-house replacement option so the board sees both routes side by side.
Best for: Making slides say something
Act as a sharp editor of consulting slides. Topic labels such as "Market overview" tell the reader nothing; action titles state the message.
Current slide titles and a one-line note on what each slide shows: {{SLIDE_TITLES_AND_CONTENT}}
The governing thought of the deck: {{GOVERNING_THOUGHT}}
Audience: {{AUDIENCE}}
For each slide:
1. Rewrite the title as a full-sentence message of no more than two lines (roughly 20 words), starting with the point rather than the topic. Keep it consistent with what the slide actually shows; do not claim anything the slide's content note does not support.
2. Where the slide content does not support a clear message, flag it as NO EVIDENCE of a clear message and suggest whether to merge, split or cut the slide.
3. Mark any title that includes a number I did not provide, and remove the number.
Then:
4. Read the titles in order and judge whether they tell the whole story on their own. List breaks in the logic.
5. Suggest a rewrite of the first and last titles so the deck opens with the answer and closes with the ask.
Output: a table with columns Slide, Old title, New action title, Note; then the logic breaks and the opening and closing rewrites.
Fill in: SLIDE_TITLES_AND_CONTENT GOVERNING_THOUGHT AUDIENCE
Read the titles aloud in sequence; if the story fails, restructure before polishing.
Best for: Planning a deck before building any slides
You are an engagement manager who builds a ghost deck early so the team knows what to prove. Create one from the storyline below.
Storyline (governing thought and supporting arguments): {{STORYLINE}}
Audience and meeting length: {{AUDIENCE_AND_TIME}}
Maximum number of main slides allowed: {{MAX_SLIDES}}
Produce a ghost deck that stays within the slide limit:
1. For each slide give: slide number, action title, the single message, the evidence or analysis needed, the visual type (chart, table, diagram, quote), and the status (HAVE, NEED DATA, NEED ANALYSIS).
2. Put the executive summary first and any detail in an appendix list, kept separate from the main count.
3. Show the logic flow with a one-line transition between sections.
4. Flag slides that depend on data the client has not yet supplied and rank them by risk to the schedule.
5. Suggest what to cut if time is cut by a third.
Rules: do not invent data or example results; where a chart is needed, describe it (axes, comparison) and label any illustrative values as [INFERRED]. If you notice the storyline cannot be shown in the allowed slide count, say so.
Output: a table for the slides, followed by the appendix list, risk ranking and cut list. Slide Studio can turn the final outline into a draft deck.
Fill in: STORYLINE AUDIENCE_AND_TIME MAX_SLIDES
Share the ghost deck with the client early to catch misunderstandings while they are cheap. Long prompt: run it in two steps, asking for the first half of the numbered outputs, then the rest.
Best for: Writing the page the sponsor actually reads
Act as a consultant writing the executive summary that senior readers will read instead of the full report.
Question the client asked: {{CLIENT_QUESTION}}
Key findings with the evidence behind each, anonymised: {{KEY_FINDINGS}}
Recommendation and the main trade-off: {{RECOMMENDATION}}
Decisions or actions required from the reader: {{REQUIRED_DECISIONS}}
Write the summary on one page, maximum 350 words:
1. Opening paragraph: the answer and the action requested, in three sentences or fewer.
2. Three or four short paragraphs, each led by a bold sentence that states a finding, followed by one or two sentences of evidence.
3. The recommendation, with one sentence on the main risk and what would change our advice.
4. Next steps as a list with owners (role titles) and dates, using only dates I provided; otherwise write [TO CONFIRM].
5. A one-line statement of the basis of the work (what we reviewed and what we did not).
Rules: use plain language, no jargon or filler adjectives. Every number must come from my findings; label any figure that lacks a stated source with [NEEDS SOURCE] so I can add it. Do not invent quotes or benchmarks.
Output: the summary, followed by a list of claims that need a source or client confirmation.
Fill in: CLIENT_QUESTION KEY_FINDINGS RECOMMENDATION REQUIRED_DECISIONS
Test it by handing it to someone who was not in the project and asking what they would do.
Best for: Briefing charts that prove the title
You are a data visualisation specialist briefing an analyst or designer. Each chart should prove its slide title, and nothing else.
Slide action titles and the data we have for each: {{TITLES_AND_DATA}}
Audience: {{AUDIENCE}}
Tool or format the chart will be built in (spreadsheet, slide software, Slide Studio): {{TOOL}}
For each slide, write a brief:
1. The message the chart must prove, restated in one line.
2. The recommended chart type and why it is better than the closest alternative.
3. What goes on each axis, how data is sorted, what is highlighted and what is greyed out.
4. The annotation: a callout wording that points to the insight without exaggerating it.
5. The data series and period required; flag if my data does not cover them.
6. Footnote and source line wording, with a placeholder where I must supply the source.
7. A warning about how this chart could mislead (truncated axes, small samples, mixed definitions) and the fix.
Rules: don't create or assume data values. If a recommended chart needs data I have not listed, say what is missing instead of making it up.
Output: one block per slide with the seven items, followed by a list of data gaps across all slides.
Fill in: TITLES_AND_DATA AUDIENCE TOOL
Hand the briefs to whoever builds the charts; fewer revisions come back.
Best for: Pressure-testing a deck before the client does
Act as the most sceptical senior person in the client room: a finance lead who dislikes consultants and has read every page. Your job is to find the weak points before they do.
Deck content or storyline: {{DECK_CONTENT}}
Client context and sensitivities, anonymised: {{CLIENT_CONTEXT}}
Reader you want me to prepare for: {{TOUGH_READER}}
Review the material:
1. Write the fifteen hardest questions this reader could ask, ordered by how much damage an unprepared answer would cause. Include questions on evidence quality, method, bias, cost, feasibility and what we left out.
2. For each, say which slide or claim triggers it, and rate my vulnerability as High, Medium or Low.
3. For the five most dangerous questions, draft an honest, short answer using only what the material supports, and note what additional evidence would strengthen it.
4. Identify any claim in the deck that is stated more confidently than the evidence allows, and suggest softer wording.
5. List any numbers that appear without a source, label them [NEEDS SOURCE], and suggest where I would find the source.
Do not fabricate evidence to answer the questions. If there is no good answer, write NO EVIDENCE and say what I need to do. Output: a table of questions with trigger and rating, then the five answers and the wording fixes.
Fill in: DECK_CONTENT CLIENT_CONTEXT TOUGH_READER
Run it two days before the meeting, not the night before. Long prompt: run it in two steps, asking for the first half of the numbered outputs, then the rest.
Best for: Shrinking a deck without losing the argument
You are an editor with a hard rule: every slide earns its place or goes to the appendix. I have a deck that has grown past what the audience can absorb.
Current slide list with the message of each: {{SLIDE_LIST}}
Governing thought: {{GOVERNING_THOUGHT}}
Time available and audience: {{TIME_AND_AUDIENCE}}
Target number of main slides: {{TARGET_SLIDES}}
Do this:
1. Classify every slide as KEEP, MERGE (say with which), MOVE TO APPENDIX or CUT, with one line of reasoning tied to the governing thought.
2. Show the resulting main deck in order, with a rewritten action title for any merged slide.
3. Identify the evidence that was moved to the appendix and write the one-line cross-reference that points the reader there.
4. Look for slides that make the same point twice and slides that contradict each other.
5. Identify anything in the deck that the audience will expect but is now missing, and say whether it needs to be restored.
6. Write a three-sentence note to the team explaining the cuts so it does not feel arbitrary.
Do not invent slides or new content. Output: a table of decisions, then the new main deck order, then the cross-references and the team note.
Fill in: SLIDE_LIST GOVERNING_THOUGHT TIME_AND_AUDIENCE TARGET_SLIDES
Bring the table to the team review so cuts are argued on logic, not attachment.
Best for: Making findings say something
Act as an engagement manager who sends back slides that describe data without saying what it means. Turn analysis results into insight statements.
Analysis results, as plain statements or small tables, with the source of each: {{ANALYSIS_RESULTS}}
The decision the audience faces: {{DECISION}}
Audience and what they already believe: {{AUDIENCE_BELIEFS}}
For each result:
1. Write the observation: what the data shows, in one factual sentence with no interpretation.
2. Write the insight: why it matters to this decision, in one sentence that starts with the implication.
3. Write the so-what: the action or question it suggests.
4. State what would make you wrong: another explanation that fits the same data.
5. Rate the strength of the insight: Supported, Suggestive or Weak, based on the evidence given.
Then:
6. Choose the three insights that matter most for the decision and explain why. Say which ones contradict what the audience believes, and how to introduce them without sounding like an attack.
7. List results that are interesting but irrelevant to the decision, for the appendix.
Do not add numbers or explanations that are not in my results; mark any causal claim you cannot support as [INFERRED]. Output: a table with the five columns, then the ranked three and the appendix list.
Fill in: ANALYSIS_RESULTS DECISION AUDIENCE_BELIEFS
Use the alternative explanations to pre-empt questions in the meeting.
Workshop Design & Facilitation
A workshop should end with decisions, not sticky notes. Design from outcomes, run a prioritisation exercise that copes with senior egos, prepare participants with a neutral pre-read, turn raw output into decisions, owners and open questions, and plan a remote session with breakouts and low-tech backups.
Best for: Designing a workshop that ends in decisions
You are an experienced facilitator designing a client workshop. Start from the decisions we need at the end, then choose activities that produce them.
Purpose of the workshop and the decisions or outputs needed: {{OUTCOMES}}
Participants by role, number and their likely positions: {{PARTICIPANTS}}
Duration, setting and constraints: {{DURATION_AND_SETTING}}
Politics or sensitivities to handle: {{SENSITIVITIES}}
Design:
1. Restate the outcomes as observable results ("a ranked list of five options with an owner for each").
2. Build an agenda with time boxes, the purpose of each segment, the method (silent writing, small groups, voting, plenary) and the output each segment produces. Keep at least 20 percent of time unscheduled for overrun.
3. Explain why the sequence works: how early segments prepare the group for the difficult one.
4. List the materials, room set-up and roles (facilitator, scribe, timekeeper).
5. Anticipate five things that could derail the session and a planned response to each.
6. State the decision rule: how the group will decide, and what happens if there is no consensus.
Output: an agenda table with columns Time, Segment, Method, Output; then the numbered lists for the remaining items. Do not invent facts about the participants.
Fill in: OUTCOMES PARTICIPANTS DURATION_AND_SETTING SENSITIVITIES
Send the outcomes and decision rule to the sponsor before the agenda.
Best for: Ranking priorities with a senior group
Act as a facilitator who has seen senior groups fight over priorities. Design an exercise that gets honest rankings and makes the result feel fair.
List of items to prioritise (initiatives, risks or ideas): {{ITEMS}}
Criteria that matter to the client: {{CRITERIA}}
Group size and seniority mix: {{GROUP_PROFILE}}
Time available for the exercise: {{TIME_AVAILABLE}}
Create the exercise:
1. Recommend a method (for example weighted scoring, dot voting, an impact versus effort grid, or a forced ranking) and explain in two sentences why it fits this group better than the alternatives.
2. Write step-by-step instructions I can read aloud, with timing for each step.
3. Explain how to keep scores independent before discussion so the most senior person does not anchor everyone.
4. Provide a scoring sheet layout with the criteria and a scale definition for each score, so that people mean the same thing by a 4.
5. Describe how to handle ties, outliers and a strong disagreement after scoring.
6. Describe how to present the result back, and how to point out that it is a prioritisation of opinions, not measured value, unless we have data.
Do not make up scores or an example result. Output: the method choice, then the instructions, the scoring sheet and the handling notes.
Fill in: ITEMS CRITERIA GROUP_PROFILE TIME_AVAILABLE
Collect scores privately first, then discuss the largest gaps.
Best for: Getting participants prepared before the day
You are a consultant preparing participants for a workshop so that they arrive ready to decide, not to be briefed.
Workshop purpose and date, as written by me: {{PURPOSE_AND_DATE}}
Who is attending and what each group should bring: {{ATTENDEES_AND_INPUTS}}
Background material the participants need, summarised by me: {{BACKGROUND}}
Work I want completed beforehand, if any: {{PRE_WORK}}
Draft:
1. An invitation email of up to 150 words with the purpose, the outcome, the logistics placeholders and the pre-work request.
2. A pre-read of up to one page: the question, what we already know (using only my background), what we do not know, the options on the table if any, and how the day will run.
3. A short pre-work template participants can complete in ten minutes, with three questions.
4. A reminder message for two days before the session.
5. A note on what happens to participants' contributions after the workshop.
Rules: plain language, no jargon. Keep the pre-read neutral: it must not argue for our preferred answer. Mark any detail I haven't supplied as [TO CONFIRM], and do not invent dates, room names or links.
Output: the four documents under clear headings.
Fill in: PURPOSE_AND_DATE ATTENDEES_AND_INPUTS BACKGROUND PRE_WORK
Send the pre-read at least three working days before the session.
Best for: Capturing what a workshop actually decided
Act as the scribe who turns a messy workshop into a clean record the client can act on. The raw material follows.
Raw notes, photos transcribed to text, voting results and flip chart content: {{WORKSHOP_NOTES}}
Workshop purpose: {{PURPOSE}}
Participants, by role: {{PARTICIPANTS}}
Produce:
1. Decisions made: each stated as a sentence, with the evidence in the notes that shows it was agreed. Do not list something as a decision if the notes show only discussion.
2. Ideas generated but not decided, grouped into themes.
3. Actions: owner (role), action, due date from the notes or [TO CONFIRM].
4. Open questions and disagreements, stated neutrally, with who needs to resolve each.
5. Areas where the notes are unclear or incomplete, so I can check with participants.
6. A follow-up email under 200 words that thanks participants, summarises decisions and actions, and invites corrections within two working days.
Rules: use only the notes; do not smooth over disagreement or assign actions that nobody accepted. Where an action has no named owner, mark it [TO CONFIRM].
Output: the five lists as tables or bullets, then the email.
Fill in: WORKSHOP_NOTES PURPOSE PARTICIPANTS
Send the record within 24 hours while memories are fresh.
Best for: Running a workshop on video without losing people
You are a facilitator running a client workshop online. Online sessions lose energy and quiet voices, so design for both.
Workshop outcome needed: {{OUTCOME}}
Participants, number, locations and time zones: {{PARTICIPANTS_AND_ZONES}}
Tools available (video, whiteboard, polling, shared documents): {{TOOLS}}
Maximum session length and number of sessions: {{SESSION_LIMITS}}
Plan:
1. Split the work into sessions if one block is too long, with a break plan, and explain what is done live versus asynchronously beforehand.
2. Provide a minute-by-minute agenda for each session, with the method and the output of each segment.
3. Describe how breakout groups are formed, briefed and reported back, with a script for the first thirty seconds in a breakout.
4. Give techniques to include quiet participants and manage dominant ones in a video setting.
5. List the technical risks and a low-tech backup for each (for example the whiteboard fails, a participant cannot join).
6. Define the facilitator and producer roles so someone watches the chat.
7. Set out how to capture the outputs in a shared document during the session.
Output: a sessions table, then the numbered items. Do not assume features of tools I did not list.
Fill in: OUTCOME PARTICIPANTS_AND_ZONES TOOLS SESSION_LIMITS
Rehearse the technology with a colleague before the participants arrive.
Recommendations, Options & Trade-offs
Clients accept advice when they can see the alternatives treated fairly. Compare options against explicit criteria, write a memo that leads with the answer, list what would have to be true for the recommendation to work, build the logic of a business case before any numbers and prepare for stakeholder pushback.
Best for: Presenting options fairly before recommending one
Act as a consultant preparing an options paper for a client decision. Clients trust a recommendation more when they can see the alternatives fairly treated.
Decision to be made: {{DECISION}}
Options under consideration, including the do-nothing baseline: {{OPTIONS}}
What the client cares about most, in rough order: {{CLIENT_PRIORITIES}}
Facts and estimates I have for each option, with sources: {{OPTION_EVIDENCE}}
Produce:
1. Four to six decision criteria derived from the client's priorities, each defined in a sentence and weighted High, Medium or Low (explain the weighting logic).
2. A comparison table scoring each option against each criterion as Strong, Adequate or Weak, with a one-line reason that cites my evidence. Where I gave no evidence, write NO EVIDENCE instead of guessing.
3. The honest trade-off of each option: what the client gains and what it gives up.
4. Your preferred option and the strongest argument against it.
5. The conditions under which a different option would be better.
6. The facts I should still verify before this goes to the client.
Rules: do not invent costs, benefits or probabilities. If an option cannot be compared without a number I have not given, say what the number is and how to get it.
Output: the criteria, the table, then the trade-offs and the recommendation.
Fill in: DECISION OPTIONS CLIENT_PRIORITIES OPTION_EVIDENCE
Show the do-nothing baseline; it is often the option the client is actually weighing.
Example output · Claude (example written by The Prompt Index)
Sample inputs (fictional)
- DECISION: How Client C, a 90-person engineering consultancy, should replace its ageing timesheet and project accounting system.
- OPTIONS: (0) Do nothing, (1) Buy a standard cloud project-accounting product, (2) Extend the existing ERP with a timesheet module, (3) Commission a custom build.
- CLIENT_PRIORITIES: Accurate project profitability, low disruption for staff, fixed total cost, live before the next financial year, which starts in 7 months.
- OPTION_EVIDENCE: (0) The vendor ends security updates in 14 months; finance says month-end close takes too long (no measurement). (1) Two demos done; the vendor quoted a subscription fee; the implementation partner estimates 4-5 months. (2) The ERP vendor says the module exists; no quote, no demo. (3) One internal developer says it could be built; no estimate from anyone.
Criteria and weights (from the client's priorities, in their order)
- Project profitability accuracy (High): ties hours, expenses and billing to each project.
- Disruption for staff (Medium): retraining, parallel running, changed habits.
- Cost certainty (High): how firmly total cost can be fixed before signing.
- Time to live (High): realistic chance of running within 7 months.
- Support risk (Medium): reliance on a vendor or one person.
Every rating below quotes the evidence supplied. Where none was supplied, it says NO EVIDENCE.
| Criterion | 0 Do nothing | 1 Cloud product | 2 ERP module | 3 Custom build |
|---|---|---|---|---|
| Profitability accuracy | NO EVIDENCE (only "close takes too long") | NO EVIDENCE (demos give no accuracy evidence on Client C's data) | NO EVIDENCE | NO EVIDENCE |
| Disruption | Strong: nothing changes | NO EVIDENCE | NO EVIDENCE | NO EVIDENCE |
| Cost certainty | NO EVIDENCE | Adequate: subscription fee quoted; implementation cost only estimated in time, not in money | NO EVIDENCE (no quote) | NO EVIDENCE (no estimate) |
| Time to live | Strong: already live | Adequate: partner estimates 4-5 months against a 7-month deadline | NO EVIDENCE | NO EVIDENCE |
| Support risk | Weak: security updates end in 14 months | NO EVIDENCE | NO EVIDENCE | Weak: build rests on "one internal developer" |
Trade-offs (from the evidence only)
- Do nothing: no change or cost now, but supported security updates end in 14 months.
- Cloud product: the only option with a quote and a timeline inside the deadline; the cost of implementation and its fit for Client C's profitability reporting are not yet evidenced.
- ERP module and custom build: not comparable on what we have.
Preferred option: Option 1, provisionally. It is the only option with evidence on cost and time, and Option 0 has a dated support problem. This is a preference by elimination of evidence gaps, not proof that Option 1 is best. The strongest argument against it: Option 2 might be cheaper and simpler, and we have not looked.
A different option would be better if the ERP vendor shows a module that ties time to projects and quotes a fixed price inside 7 months.
To verify before this goes to the client
1. Get an ERP module quote and demo against the same five criteria.
2. Ask the implementation partner for a written timeline and a cost estimate.
3. Test the cloud product on a sample of Client C's real project data for profitability accuracy.
4. Ask finance to measure the current month-end close so any improvement can be judged.
5. Ask the developer for an estimate if Option 3 is to stay on the list.
Best for: Writing a recommendation a senior reader will act on
You are a consulting partner writing a decision memo to a busy executive. Lead with the recommendation, then earn it.
Decision the executive must make and by when: {{DECISION_AND_DEADLINE}}
Our recommendation: {{RECOMMENDATION}}
Evidence supporting it, as a bulleted list with sources: {{EVIDENCE}}
Main risks and objections we are aware of: {{RISKS_AND_OBJECTIONS}}
Write a memo of 450 words or fewer, with these parts:
1. The recommendation and the decision requested, in the first two sentences.
2. Why: three reasons, each with its evidence, ordered by strength.
3. What we considered and rejected, in two or three sentences.
4. Risks: the top three, each with a mitigation and a trigger that tells us it is happening.
5. What it will take: resources and effort, using only the figures I provided, with [NEEDS SOURCE] where I did not.
6. What would change our recommendation.
7. Next step requested.
Rules: plain, direct, calm tone; no hedging adjectives, no hype. Every figure must trace to my evidence list; tag any that does not with [NEEDS SOURCE]. Do not invent evidence or quote people.
Output: the memo under short bold labels, followed by a list of items needing verification.
Fill in: DECISION_AND_DEADLINE RECOMMENDATION EVIDENCE RISKS_AND_OBJECTIONS
Send it before the meeting so the discussion starts from the decision, not a presentation.
Best for: Surfacing the assumptions behind your advice
You are a strategy consultant who tests a recommendation by listing the beliefs that sit under it, then asking how much evidence supports each belief.
Recommendation: {{RECOMMENDATION}}
Evidence behind it, with sources: {{EVIDENCE}}
Alternatives we rejected and why: {{REJECTED_ALTERNATIVES}}
Work through:
1. List eight to twelve conditions that would have to be true for the recommendation to succeed. Cover customers, competitors, capabilities, economics, organisation and timing.
2. For each condition, rate the current evidence as Strong, Partial or None, based only on what I gave you. Quote the supporting item.
3. Mark the conditions that are most uncertain and most important, and design the cheapest test for each one (an experiment, a pilot, a data pull, a reference call).
4. Show which of the conditions, if false, would make a rejected alternative the better choice.
5. Suggest the exact words I should use with the client to describe the confidence level of the recommendation honestly.
Do not invent evidence or reassure me where there is none. Output: a table with columns Condition, Evidence, Strength, Importance, Test; then the alternative-switch analysis and the confidence wording.
Fill in: RECOMMENDATION EVIDENCE REJECTED_ALTERNATIVES
Share the weakest conditions with the client; it builds trust and shapes the pilot.
Best for: Building a defensible case before modelling
Act as a consultant building the logic for a business case. Before anyone puts numbers in a spreadsheet, the chain of cause and effect needs to be agreed.
Proposed initiative: {{INITIATIVE}}
Claimed benefits from the client or sponsor: {{CLAIMED_BENEFITS}}
Costs and efforts known so far: {{KNOWN_COSTS}}
Time horizon: {{HORIZON}}
Create the logic chain:
1. For each claimed benefit, map the chain from activity to output to outcome to financial or non-financial value. Highlight each link where the causation is only assumed.
2. Classify benefits as cost reduction, revenue increase, risk reduction, or non-financial, and flag any double-counting between them.
3. List all categories of cost: one-off, ongoing, internal time, change and training, and risk allowances. Mark categories missing from my list.
4. For each benefit and cost, specify the data needed, the likely owner (role), and a measurement method.
5. Describe the baseline and how we agree it with finance before measuring the benefit.
6. Identify the benefits that are hardest to evidence and recommend whether to exclude them from the headline case.
Do not give any figures, rates or typical returns. Output: a chain table with columns Benefit, Chain, Assumed links, Data needed, Owner; then the cost categories, baseline and exclusion advice.
Fill in: INITIATIVE CLAIMED_BENEFITS KNOWN_COSTS HORIZON
Agree the chain with finance before building the model; it prevents arguments about the numbers later.
Best for: Going into a challenging review prepared
Act as a seasoned partner coaching a consultant before a tense client review. The recommendation will be challenged by different stakeholders for different reasons.
Recommendation: {{RECOMMENDATION}}
Stakeholders likely to react, with role and concern (anonymised): {{STAKEHOLDER_CONCERNS}}
Evidence and limits of our analysis: {{EVIDENCE_AND_LIMITS}}
Prepare me:
1. For each stakeholder, state the real objection behind the stated one (for example loss of control, workload, budget, reputation), labelled as an inference.
2. Draft a response for each that acknowledges the concern, answers it with evidence from my list, and states honestly where our analysis is limited.
3. Provide a version of the recommendation adjusted for each stakeholder's concern that does not change the substance; flag if a change would alter the recommendation itself.
4. List the three concessions I could offer that cost little, and the two things I should not concede and why.
5. Write a script for one thing I might say if I do not know the answer, so I never bluff.
6. Describe how to follow up in writing within a day.
Rules: don't invent evidence, and don't suggest manipulation or pressure tactics. Output: a stakeholder table, then the concession lists and scripts.
Fill in: RECOMMENDATION STAKEHOLDER_CONCERNS EVIDENCE_AND_LIMITS
Role-play it with a colleague playing the toughest stakeholder.
Roadmaps, Change Management & Client Updates
Advice only counts if it lands. Turn a recommendation into a phased roadmap with decision gates, sequence quick wins against foundations, assess change impact by group, diagnose resistance, write the case for change in plain words, agree a communications cadence, keep the client informed each week, reset expectations mid-engagement and close the work cleanly.
Best for: Turning a recommendation into a phased plan
You are a transformation consultant converting a recommendation into a roadmap the client can run without us. Focus on sequence, dependencies and decisions.
Recommendation to implement: {{RECOMMENDATION}}
Constraints: budget envelope, key dates, capacity and other programmes running: {{CONSTRAINTS}}
Capabilities the client has and lacks today: {{CAPABILITIES}}
Build the roadmap:
1. Divide the work into three to five phases with a purpose, entry criteria, main activities, outputs and exit criteria for each.
2. Define decision gates between phases: the question to answer, the evidence required, who decides (role), and what happens on a no-go.
3. Map dependencies between workstreams and highlight the critical path in words.
4. Show where client capacity is the binding limit and propose how to sequence around it.
5. Identify early signals of success for each phase, and the leading indicators of trouble.
6. List what would need to be decided in the first 30 days.
Rules: don't provide durations, costs or resourcing numbers unless I have given them; where you suggest timing, mark it [TO CONFIRM]. Output: a phase table, a dependency list, then the gates and the 30-day decisions.
Fill in: RECOMMENDATION CONSTRAINTS CAPABILITIES
Walk the sponsor through the decision gates, not the Gantt chart.
Best for: Balancing early momentum with lasting change
Act as a programme consultant balancing visible early results against the foundations that make results last.
Initiatives or actions on the long list: {{INITIATIVES}}
Client's need for early credibility and why: {{EARLY_RESULT_NEED}}
Known dependencies and capacity limits: {{DEPENDENCIES_AND_LIMITS}}
Analyse:
1. Classify each initiative as Quick win, Foundation, Strategic bet or Distraction, with a one-line reason.
2. For each quick win, test whether it is a real win by checking that it is visible, owned, reversible and does not undermine a foundation. Flag fake quick wins.
3. For each foundation, state what it unlocks and what continues to fail without it.
4. Propose a sequence in three waves with the logic for each wave, ensuring the first wave builds support for the second.
5. Describe the story told to staff after each wave, in a sentence.
6. List the initiatives that I should recommend stopping or postponing, and how to explain this to their sponsors.
Do not assign values or timelines. Where the classification depends on a missing fact, ask a question instead of guessing. Output: a classification table, then the wave plan, the story lines and the stop list.
Fill in: INITIATIVES EARLY_RESULT_NEED DEPENDENCIES_AND_LIMITS
Challenge each quick win with the question: who will notice, and who owns it?
Best for: Understanding who is affected and how
You are a change management consultant. Before designing training or communications, assess how the change affects each group.
Description of the change (process, structure, systems or behaviour): {{CHANGE_DESCRIPTION}}
Affected groups, by role and approximate size: {{AFFECTED_GROUPS}}
Current ways of working in those groups: {{CURRENT_STATE}}
Target ways of working: {{TARGET_STATE}}
Assess:
1. For each group, describe what changes in their daily work: tasks, tools, decisions, reporting lines, skills and performance measures.
2. Rate the impact (High, Medium, Low) with the reason, and rate how much they stand to gain or lose personally, labelled as a judgement.
3. Identify what each group must start doing, stop doing and keep doing.
4. Name the skills or knowledge gaps and the lightest way to close each.
5. Note the timing: when each group feels the change first.
6. Identify groups that are affected indirectly and are easy to forget.
7. List the questions I need to ask each group's leader to confirm this assessment.
Rules: base everything on my inputs; mark inferences [INFERRED]; do not invent headcount or attitudes. Output: an impact table with columns Group, What changes, Impact, Stands to gain or lose, Gaps; then the lists.
Fill in: CHANGE_DESCRIPTION AFFECTED_GROUPS CURRENT_STATE TARGET_STATE
Validate the table with each group's manager before building a plan.
Best for: Understanding why people push back on a change
Act as a change consultant who treats resistance as information. Resistance usually has a reason, and I need to find it before choosing a response.
The change and the sponsor's goal: {{CHANGE_AND_GOAL}}
Observed resistance behaviours (anonymised, no individuals): {{OBSERVED_BEHAVIOURS}}
Groups or roles showing it: {{GROUPS}}
What has been communicated so far: {{COMMUNICATION_SO_FAR}}
Diagnose and plan:
1. For each behaviour, offer three possible causes (for example unclear reason, fear of loss, lack of capability, a real flaw in the design, change fatigue) and say what evidence would show which is true.
2. Recommend questions to ask each group to discover the cause, in a listening session rather than a briefing.
3. For each probable cause, propose a response and an owner (role).
4. Identify any resistance that signals a valid problem with the change and should be fed back to the design team.
5. Outline an engagement plan over six weeks: who to involve, what to ask, what to show them.
6. Define signals that will tell us the resistance is easing or hardening.
Do not label people as resistors or speculate about individuals. Output: a diagnosis table, then the question list, the response plan and the signals.
Fill in: CHANGE_AND_GOAL OBSERVED_BEHAVIOURS GROUPS COMMUNICATION_SO_FAR
Treat the design-flaw item seriously; some resistance is right.
Best for: Explaining a change honestly to the people affected
You are an internal communications writer helping a client leader explain a change to staff who are anxious and busy. The message should be honest and short.
The change in a few sentences: {{CHANGE_SUMMARY}}
Why it is happening, using facts the client has already shared internally: {{REASONS}}
What is decided and what is not yet decided: {{DECIDED_AND_OPEN}}
Audience and what they are likely to worry about: {{AUDIENCE_WORRIES}}
Write:
1. A message from the leader of up to 250 words: why change, what it means for the audience, what is staying the same, what happens next, and where to ask questions.
2. A shorter version of 80 words for a team meeting.
3. A set of eight questions staff will likely ask, with drafted answers. Where the answer is not yet known, the draft says so and states when an update will come.
4. Wording to avoid: three phrases that sound evasive or corporate, with plain replacements.
Rules: do not promise outcomes about jobs, pay or timelines that I have not confirmed; use [TO CONFIRM] instead. No exaggerated enthusiasm. Do not invent reasons or data.
Output: the long message, the short message, the Q&A and the phrases to avoid. Remind me to have the client's HR or legal advisers review anything that touches employment terms.
Fill in: CHANGE_SUMMARY REASONS DECIDED_AND_OPEN AUDIENCE_WORRIES
Get the client's HR lead to check any line about roles or terms before it goes out. Long prompt: run it in two steps, asking for the first half of the numbered outputs, then the rest.
Best for: Keeping the client informed without long meetings
Act as an engagement lead writing a weekly update. The client wants to know what is done, what is next and what needs them, without having to ask.
Engagement objective: {{OBJECTIVE}}
Done this week: {{DONE}}
Planned next week: {{NEXT}}
Issues, risks and decisions needed from the client: {{ISSUES_AND_DECISIONS}}
Changes to scope, timeline or fees agreed or pending: {{CHANGES}}
Write the update, in under 300 words:
1. A two-sentence headline with an overall status (On track, At risk, Off track) and the reason.
2. Progress against the plan: three to five bullets, each stating the result, not the activity.
3. Next week: the main outputs.
4. Decisions needed: for each, the decision, who must make it, the date by which we need it, and what happens if it slips.
5. Risks and issues: the top three with owner and next action.
6. Any change to scope or fees, stated neutrally, with the status of agreement.
Rules: be candid; do not turn a delay into a positive. Use only what I wrote and do not invent progress or dates. Keep the tone professional and plain.
Output: the update ready to paste in an email, then a one-line subject.
Fill in: OBJECTIVE DONE NEXT ISSUES_AND_DECISIONS CHANGES
Put decisions needed near the top if the client is the bottleneck.
Best for: Resetting expectations before the engagement slips
You are a consultant planning a frank mid-engagement conversation with the client sponsor. The engagement is drifting: expectations have changed, findings are different from the hypotheses, or the sponsor's priorities have shifted.
Original scope and objectives: {{ORIGINAL_SCOPE}}
What has changed since (findings, requests, client priorities, delays): {{WHAT_CHANGED}}
Options I see for the remaining work: {{REMAINING_OPTIONS}}
Commercial and relationship constraints I must respect: {{COMMERCIAL_CONSTRAINTS}}
Prepare:
1. A one-paragraph honest summary of where we stand against the original scope.
2. A list of the three or four topics to cover and the order that builds agreement.
3. For each option for the remaining work, the benefit to the client, the effect on timeline and the effect on deliverables. Do not quote fees; refer to my own pricing conversation.
4. The questions to ask the sponsor to find out what they now need.
5. Talking points for raising a bad finding or a missed assumption without defensiveness.
6. A follow-up note that records what was agreed, in neutral language.
7. A short list of warning signs that this is a renegotiation rather than a clarification.
Output: the summary, the agenda, an options table, the question list, the talking points and the follow-up note.
Fill in: ORIGINAL_SCOPE WHAT_CHANGED REMAINING_OPTIONS COMMERCIAL_CONSTRAINTS
Hold this conversation early; a surprise at the end costs more than a reset in the middle.
Best for: Closing an engagement cleanly
Act as a consultant finishing an engagement well. A clean close protects the relationship and the results, and it is where future work comes from.
What we delivered: {{DELIVERABLES}}
What the client needs to do to realise the benefits, and who owns it: {{CLIENT_ACTIONS}}
Outcomes the client has said matter to them: {{CLIENT_OUTCOMES}}
Ideas for further work that arose honestly: {{FOLLOW_ON_IDEAS}}
Produce:
1. A handover checklist: documents, models, files, access, and who holds each after we leave. Include a reminder to return or delete client data according to the agreement.
2. A one-page close-out summary for the sponsor: what was asked, what was done, what the client must do next, and what is left open.
3. A set of eight questions for a short feedback conversation that invites criticism as well as praise.
4. A gentle follow-up plan: a check-in at an agreed interval to see whether the actions held, framed as help rather than a sales call.
5. If the follow-on ideas are real, a way to raise them that separates the new need from the finished work, with no pressure.
6. An internal lessons list for me: repeat, change.
Rules: do not state outcomes the client has not confirmed. Output: the checklist, the summary, the questions, the follow-up plan and the lessons template.
Fill in: DELIVERABLES CLIENT_ACTIONS CLIENT_OUTCOMES FOLLOW_ON_IDEAS
Add the client's reply to your own notes; those become next proposal's evidence, with permission. Long prompt: run it in two steps, asking for the first half of the numbered outputs, then the rest.
Best for: Setting communication rhythms the client will keep
You are a consultant agreeing how the engagement will communicate, so that the client sponsor is never surprised and the working team is not drowned in meetings.
Engagement phases and key dates: {{PHASES_AND_DATES}}
People involved by role: sponsor, working team, steering group, those affected: {{PEOPLE_BY_ROLE}}
Client communication norms and tools: {{CLIENT_NORMS}}
Design the plan:
1. A cadence table: forum, purpose, attendees (roles), frequency, length, owner and the output each produces.
2. A rule for escalation: what we raise with the sponsor within a day, what waits for the weekly update, who decides.
3. The content of the steering group pack, limited to one page, and how far ahead it goes out.
4. How we communicate with people affected by the work but not on the team: what they hear, when and from whom.
5. Rules for sensitive information: what stays within the core team, how interview material is stored, and how documents are labelled.
6. A feedback loop: how the client tells us the rhythm is wrong, and a check-in after three weeks.
7. A short kick-off message that proposes the cadence and invites changes.
Rules: fit the client's norms; do not add meetings that have no output. Mark unknown details [TO CONFIRM]. Output: the table, the rules, then the kick-off message.
Fill in: PHASES_AND_DATES PEOPLE_BY_ROLE CLIENT_NORMS
Agree the cadence at kick-off, not after the first missed update.