Weekly Pipeline Health Summary
Turn weekly deal stage changes into an evidence-based pipeline review summary.
Customise & copy
Add the context you have. The prompt updates as you work.
Enter the start and end dates for the week being reviewed.
List each change with deal name or ID, previous stage, new stage, and change date. Include unchanged or stalled status only when explicitly known.
Add only context you have, such as owner, amount, close date, segment, or documented reason for the change.
Provide the ordered stages or definitions when stage names are ambiguous or organization-specific.
Live prompt
4 fieldsCreate a concise weekly pipeline health summary from the supplied deal stage changes. Use only the information provided in these inputs: Reporting period: {{reporting_period}} Deal stage changes: {{deal_stage_changes}} Optional deal context: {{deal_context}} Stage definitions or ordering: {{stage_definitions}} Return exactly these headings, in this order: Overall Health - Give a brief qualified assessment based only on observed evidence. - Cite the stage changes or patterns supporting the assessment. - If the data is insufficient to judge overall health, say so clearly. Key Movement - Summarize meaningful forward movement and backward movement. - Identify unchanged entries only when they are explicitly supplied. - Highlight concentration by owner, segment, close date, or other dimension only when supported by the input. - Include counts or percentages only when the denominator and calculation are clear from the supplied data. Risks and Watch Items - Identify reversals, possible timing risk, concentration risk, ambiguous changes, data gaps, or other supported concerns. - Do not label a deal stalled unless the input provides evidence of stalling or unchanged status. - State when the supplied data cannot support a conclusion. Positive Signals - Identify supported signs of healthy movement, such as progression, recovered deals, or balanced movement. - Do not treat every forward movement as positive without considering the available timing, context, and stage definitions. Recommended Actions - List concise actions tied directly to the observed risks or opportunities. - Name the responsible role only when the input supports it; otherwise use a role-based recommendation such as deal owner, sales manager, or RevOps and state when ownership is not provided. - Do not invent reasons, amounts, close dates, owners, metrics, forecasts, or next steps. Use concise bullets suitable for pasting into a weekly pipeline review. Distinguish observed facts from interpretation. If stage names are ambiguous and no usable stage ordering is supplied, do not classify movement as forward or backward; state the limitation. Do not ask follow-up questions. Produce the best qualified summary possible from the supplied inputs.
Proof before you use it
A real example
Tested on gpt-5.6-luna on 2026-09-08
{
"deal_context": "Northstar Health — owner: Maya Chen; amount: $120,000 ARR; close date: 2025-03-28; segment: Enterprise\nBrightpath — owner: Sam Ortiz; amount: $48,000 ARR; close date: 2025-04-18; segment: Mid-market\nKiteWorks — owner: Maya Chen; amount: $95,000 ARR; close date: 2025-03-21; segment: Enterprise\nLumen Retail — owner: Priya Shah; amount: $22,000 ARR; close date: 2025-04-30; segment: SMB",
"reporting_period": "2025-03-03 to 2025-03-07",
"stage_definitions": "Qualified < Demo < Proposal < Negotiation < Closed Won",
"deal_stage_changes": "Northstar Health | Proposal | Negotiation | 2025-03-04\nBrightpath | Demo | Proposal | 2025-03-05\nKiteWorks | Negotiation | Proposal | 2025-03-06\nLumen Retail | Qualified | Demo | 2025-03-07"
}A small ritual that works
How to use it
- 01Enter the weekly reporting period.
- 02List each deal's previous stage, new stage, and change date in deal stage changes.
- 03Add any supported owner, amount, close date, segment, or documented reason in optional deal context.
- 04Provide stage definitions or ordering when stage names are ambiguous.
Why it works
The prompt imposes strong evidence boundaries: it requires observed facts to be separated from interpretation, limits counts and percentages to cases with clear calculations, and prohibits invented owners, reasons, dates, forecasts, and next steps. It also handles ambiguous stage names carefully by requiring a usable stage ordering before labeling movement as forward or backward. Its fixed headings produce a practical weekly summary covering health, movement, risks, positive signals, and actions. The supplied outputs show that it can identify stage reversals, supported progression, timing considerations, concentration where ownership and segment data are actually available, and important information gaps.
Where it fails
The prompt can still permit unsupported conclusions when the supplied fields are incomplete. One output claimed that each deal had a different owner even though one deal had no owner supplied. It also described dates as occurring during the reporting period when the dates were actually afterward. These issues show that the instructions do not fully prevent the model from treating partial context as complete or making imprecise date comparisons.
Customisation tips
Add explicit rules that missing dimensions must be excluded from comparisons, such as: do not state that every deal has an owner unless every listed deal includes one. Require date language to distinguish before, during, after, and outside the reporting period, using exact dates when timing matters. You can also specify the accepted date format, define how incomplete records should be described, and state whether actions should include a named role, a generic role, or no owner when ownership is absent. If the pipeline uses organization-specific stages, provide the full ordered stage list and define exceptional statuses such as clarification or hold.
Watch-outs
- Partial owner, segment, or close-date fields can lead to overgeneralized concentration or coverage claims.
- Relative timing phrases such as "during" or "shortly after" may be inaccurate unless the reporting-period boundaries and event dates are compared explicitly.
- An undefined destination stage can limit movement classification even when the previous stage is known.
- Forward movement alone does not establish forecast health, conversion likelihood, readiness, or durable progress.
Works in
Was this useful?
Submit your variation
If your version helps, it may be published with your name and a link back to you.
Related prompts
RevOps Pipeline & Forecast Audit
Audit CRM data hygiene and isolate commercial risk from administrative noise to improve forecast accuracy.
RevOpsSales Pipeline Deal Auditor
Audit sales deals against hard evidence to eliminate forecast inflation and uncover hidden risks.
SalesStalled Deal Revival Identifier
Identify the most viable stalled proposal to revive by filtering out active negotiations and noise from your pipeline.
SalesWeekly CRM Pipeline Health Summarizer
Transform raw CRM deal stage changes into a concise, analytical pipeline health report for sales leadership.
Want to make AI useful across your team? Explore Atul's training.