project_scope_reduction_email
Write a proactive email to propose a project scope reduction when over budget or time. Offer concrete options: trim to core, phase remaining work, or close cleanly.
Instructions
Write the email proposing a scope reduction when a project is running over budget or time — you're catching it proactively and offering a clean path rather than letting it overrun or blow up. This is a distinct moment: you're the one raising the issue before it becomes a crisis, and you're offering a concrete proposal (not a vague warning). Three routes: reduce_to_core (trim the scope to the minimum viable deliverable, explicitly stating what stays and what's cut — use when the cut is straightforward and the core is still valuable on its own), phase_it (deliver the agreed core now and scope the remainder as a future phase with a separate budget — use when the client will still want the rest and you want to preserve the relationship and future work), stop_here (deliver what exists now and close the project cleanly — use when continuing clearly doesn't serve the client, when the project has run its course, or when it's better to end well than drag on). Distinct from scope_creep_email (client adding uncosted work), budget_negotiation_email (negotiating budget before work starts), and mid_project_cancellation_response_email (client-initiated stop). Does not count against your monthly draft limit. Required: client_name, reason (what's driving the reduction — e.g. 'we're tracking 30% over budget due to unexpected API complexity', 'the timeline has compressed and the full scope no longer fits'), proposed_reduction (what you're proposing to cut or defer — be concrete). Optional: project_name, current_completion_percentage, phase_2_scope (for phase_it route — what goes into the next phase), route ('reduce_to_core' | 'phase_it' | 'stop_here' — default reduce_to_core), your_name.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| client_name | Yes | First name or full name of the client | |
| reason | Yes | What's driving the scope reduction — be honest and specific. E.g. 'we're tracking 30% over the original budget due to unexpected complexity in the payment integration', 'the timeline has compressed from 8 weeks to 5 and the full scope no longer fits'. Used directly in the email so the client gets a clear picture. | |
| proposed_reduction | Yes | What you're proposing to cut or defer — be concrete. E.g. 'remove the admin reporting dashboard (items 4–6 in the brief) and deliver the core user flow only', 'defer the mobile-responsive build to a second phase and ship the desktop version now', 'deliver the three core sections and treat the integrations as a follow-on project'. | |
| project_name | No | Optional: the project name or short description — adds context to the email. | |
| current_completion_percentage | No | Optional: how far through the project you are, as a percentage (0–100). Used to give the client a sense of where things stand. | |
| phase_2_scope | No | Optional (recommended for phase_it route): what would go into the next phase. E.g. 'the admin dashboard, reporting exports, and mobile-responsive build — scoped as a separate engagement once phase 1 is live'. | |
| route | No | reduce_to_core (default): trim to the minimum viable deliverable, stating explicitly what stays and what's cut. phase_it: deliver core now, scope the remainder as a future phase. stop_here: deliver what exists and close cleanly. | |
| your_name | No | Optional: your name for the sign-off |