30 Claude Prompts for Statements of Work

You are a program manager who structures multi-phase client engagements for a professional services firm. <context> I have a project description and need to turn it into a clean, numbered deliverables list for the SOW. </context> <inputs> - Project description: [PROJECT DESCRIPTION] - Phases the client expects (discovery, build, launch, etc): [PHASES] - Format each deliverable should take (document, working software, presentation, etc): [FORMAT] - Client industry: [CLIENT INDUSTRY] </inputs> <task> Produce a numbered list of deliverables grouped by phase, with each deliverable named as a concrete artifact rather than an activity. </task> <constraints> Each deliverable name must be a noun a client could point to, not a verb like "conduct workshops". Limit to 3 to 5 deliverables per phase. No duplicate deliverables across phases. </constraints> <format> Return a heading per phase, then a numbered list of deliverables under each, formatted as "Deliverable name, one line description". </format>

You are a scheduling specialist who builds milestone timelines for client-facing SOWs. <context> I have a list of deliverables and a rough project duration, and I need a milestone schedule that shows dependencies clearly. </context> <inputs> - Deliverables list: [DELIVERABLES LIST] - Total project duration in weeks: [DURATION WEEKS] - Start date: [START DATE] - Known dependencies (e.g. client must approve wireframes before build starts): [DEPENDENCIES] </inputs> <task> Create a milestone schedule that assigns a target date to each deliverable and notes what must happen before it can start. </task> <constraints> Use calendar weeks, not vague terms like "soon". Flag any milestone that depends on a client action with the word "CLIENT ACTION REQUIRED". Keep the whole schedule to one table. </constraints> <format> Return a table with columns "Milestone", "Target date", "Depends on", "Owner". </format>

You are a finance-savvy consultant who ties invoicing directly to delivery so payment disputes don't happen. <context> I need to structure the payment schedule in the SOW so each invoice is tied to a specific, verifiable milestone instead of a flat monthly retainer. </context> <inputs> - Total contract value: [TOTAL VALUE] - Number of milestones: [NUMBER OF MILESTONES] - Milestone names: [MILESTONE NAMES] - Payment terms preference: [PAYMENT TERMS, e.g. net 15] </inputs> <task> Allocate the total contract value across the milestones and write the payment schedule section, stating what triggers each invoice. </task> <constraints> Each milestone payment must total to exactly the contract value, show your math. State the payment trigger as an event, not a date, for example "upon written approval of", not "at week 4". Include the payment terms on every line. </constraints> <format> Return a table with columns "Milestone", "Amount", "Trigger event", "Payment terms", then one line confirming the total. </format>

You are a delivery risk reviewer who checks project timelines for hidden dependency gaps before a SOW is signed. <context> I drafted a milestone timeline myself and I'm worried I missed a dependency that will bite us mid-project. </context> <inputs> - Draft timeline: [PASTE DRAFT TIMELINE] - Project type: [PROJECT TYPE] - Team members involved: [TEAM MEMBERS] - Client-side stakeholders involved: [CLIENT STAKEHOLDERS] </inputs> <task> Review the draft timeline and identify any milestone that likely depends on something not mentioned, such as a third-party approval, a data handoff, or a client decision. </task> <constraints> Only flag dependencies that are plausible given the project type, don't invent generic risk language. Rank each flagged gap as HIGH, MEDIUM, or LOW risk of causing a delay. </constraints> <format> Return a table with columns "Milestone", "Likely missing dependency", "Risk level", "Suggested fix". </format>

You are an account manager who translates technical deliverables into language a non-technical client sponsor will actually read. <context> My deliverables list is written for the engineering team and I need a plain-language version to send to the client's business sponsor. </context> <inputs> - Technical deliverables list: [PASTE TECHNICAL LIST] - Client sponsor's role (VP of Marketing, etc): [SPONSOR ROLE] - What the sponsor cares about most: [SPONSOR PRIORITY] </inputs> <task> Rewrite each technical deliverable as a plain-language outcome statement the sponsor can understand without asking a follow-up question. </task> <constraints> One sentence per deliverable. No technical jargon or acronyms. Tie each outcome back to the sponsor's stated priority where relevant. </constraints> <format> Return a numbered list, each line formatted as "Technical term, plain language outcome". </format>

You are a quality assurance lead who defines acceptance criteria before work starts, not after a client rejects it. <context> I need clear acceptance criteria for one deliverable so there's no argument later about whether it meets the bar. </context> <inputs> - Deliverable name: [DELIVERABLE NAME] - Deliverable description: [DELIVERABLE DESCRIPTION] - Client's success definition, in their own words: [CLIENT SUCCESS DEFINITION] </inputs> <task> Write acceptance criteria that state exactly what must be true for this deliverable to be considered accepted, in a form that can be checked yes or no. </task> <constraints> Each criterion must be checkable without interpretation, avoid words like "good" or "appropriate". Limit to 5 to 8 criteria. Write each as a complete sentence starting with "The deliverable". </constraints> <format> Return a numbered list of acceptance criteria, then one line labeled "Review window" stating how many business days the client has to accept or reject. </format>

You are a project manager who converts loose client feedback into formal acceptance criteria for the next SOW revision. <context> The client gave verbal feedback on what they expect from the next phase and I need to formalize it into criteria before we start building. </context> <inputs> - Verbal feedback notes: [PASTE FEEDBACK NOTES] - Deliverable this applies to: [DELIVERABLE NAME] - Prior version's known issues: [PRIOR ISSUES] </inputs> <task> Convert the feedback notes into a formal list of acceptance criteria that would prevent the prior version's issues from happening again. </task> <constraints> Each criterion should trace back to something the client actually said, don't invent new requirements. Mark any criterion that seems to expand scope beyond the original deliverable with "SCOPE CHECK". </constraints> <format> Return a numbered list of criteria, with "SCOPE CHECK" flags inline where relevant. </format>

You are a contracts specialist who writes the process clauses that govern what happens when a client rejects a deliverable. <context> My SOW template has acceptance criteria but no clear process for what happens if the client rejects something, and that gap has caused arguments before. </context> <inputs> - Number of revision rounds included: [NUMBER OF ROUNDS] - What happens after included rounds are used (billed hourly, etc): [EXTRA ROUND POLICY] - Deadline for client to respond: [RESPONSE DEADLINE] </inputs> <task> Write a rejection and revision process clause that states how a client rejects a deliverable, how many revision rounds are included, and what happens if the client doesn't respond by the deadline. </task> <constraints> Include a default outcome for silence, most disputes come from an undefined "what if they never respond" case. Keep it under 180 words. Plain contract language, not overly formal legalese. </constraints> <format> Return one section titled "Rejection and Revision Process" as plain paragraphs. </format>

You are an editor who specializes in catching unmeasurable language in contracts before they're signed. <context> I wrote a set of acceptance criteria myself and I want a second pass to catch anything that's actually subjective despite sounding specific. </context> <inputs> - Draft acceptance criteria: [PASTE DRAFT CRITERIA] - Deliverable type: [DELIVERABLE TYPE] - Client industry: [CLIENT INDUSTRY] </inputs> <task> Review each criterion and flag any that rely on subjective judgment rather than an objective, checkable fact, then suggest a rewrite for each flagged one. </task> <constraints> Be strict, words like "clean", "professional", or "user-friendly" without a measurable definition should be flagged. Don't flag criteria that already include a specific measurable threshold. </constraints> <format> Return a table with columns "Original criterion", "Subjective? (Yes/No)", "Suggested rewrite if Yes". </format>

You are a client success manager who sends formal sign-off requests once a deliverable meets its acceptance criteria. <context> I need a short, professional email template that requests formal sign-off, referencing the specific acceptance criteria that were met. </context> <inputs> - Deliverable name: [DELIVERABLE NAME] - Acceptance criteria list: [ACCEPTANCE CRITERIA LIST] - Client contact name: [CLIENT CONTACT NAME] - Response deadline: [RESPONSE DEADLINE] </inputs> <task> Write a sign-off request email that lists the criteria met, asks for written approval, and states the response deadline clearly. </task> <constraints> Keep it under 150 words. Professional and warm tone, not stiff legal language. Include a single clear call to action, a reply confirming acceptance. </constraints> <format> Return the email with a subject line and a body, ready to paste into an email client. </format>

You are a risk-aware consultant who adds exclusions clauses to prevent scope creep before a project starts. <context> I have a scope section written and I need to generate a matching exclusions list of things that are adjacent to the work but explicitly not included. </context> <inputs> - Scope section: [PASTE SCOPE SECTION] - Project type: [PROJECT TYPE] - Past projects where scope crept: [PAST SCOPE CREEP EXAMPLES] </inputs> <task> Generate an exclusions list of items that a client might reasonably expect but that are not covered by this scope, informed by the past scope creep examples. </task> <constraints> Only list plausible exclusions related to the actual scope, not generic filler. Limit to 6 to 10 items. Word each exclusion as "Does not include X". </constraints> <format> Return a bulleted list titled "Out of Scope", each bullet starting with "Does not include". </format>

You are a proposal writer who documents the assumptions a price and timeline are based on, so changes to those assumptions justify a change order. <context> My quote assumes certain things about client resources and data availability, and I need those written down explicitly in the SOW. </context> <inputs> - Assumptions about client resources: [CLIENT RESOURCE ASSUMPTIONS] - Assumptions about data or content availability: [DATA ASSUMPTIONS] - Assumptions about existing systems: [SYSTEM ASSUMPTIONS] </inputs> <task> Write an assumptions section listing each assumption the price and timeline depend on, and state plainly that if an assumption proves false, the timeline or price may change. </task> <constraints> Each assumption must be a specific, checkable statement, not a vague hope. Include the change order warning once at the end, not after every line. </constraints> <format> Return a heading "Assumptions", a numbered list, then one closing sentence about change orders. </format>

You are an experienced account lead who has seen small client requests balloon into unpaid extra work. <context> A client sent me a list of "small" additional requests and I want to know which ones are actually scope creep before I casually agree to them. </context> <inputs> - Client's additional requests: [PASTE CLIENT REQUESTS] - Original signed scope: [ORIGINAL SCOPE SUMMARY] - Remaining budget or hours: [REMAINING BUDGET] </inputs> <task> Review each request against the original scope and classify it as clearly in scope, a gray area, or clearly new scope requiring a change order. </task> <constraints> Be specific about why each request falls where it does, referencing the original scope. Don't soften the classification to be agreeable, be accurate. </constraints> <format> Return a table with columns "Request", "Classification", "Reasoning". </format>

You are a contracts administrator who writes short change orders when a client requests something outside the signed SOW. <context> A client asked for something clearly outside our signed scope and I need a formal but friendly change order document to send them. </context> <inputs> - Original SOW reference: [SOW NAME OR NUMBER] - New request description: [NEW REQUEST DESCRIPTION] - Additional cost: [ADDITIONAL COST] - Additional timeline impact: [TIMELINE IMPACT] </inputs> <task> Write a change order document that references the original SOW, describes the new work, and states the additional cost and timeline impact clearly. </task> <constraints> Keep it under 200 words. Include a signature line placeholder for both parties. State plainly that this work does not begin until the change order is signed. </constraints> <format> Return a document titled "Change Order" with sections "Reference", "Additional Work", "Cost", "Timeline Impact", "Approval". </format>

You are an agency founder who wants first-time clients to understand exclusions as normal business practice, not as a sign of bad faith. <context> I'm working with a first-time client who has never signed a professional services contract before and I'm worried the exclusions section will read as adversarial. </context> <inputs> - Exclusions list: [PASTE EXCLUSIONS LIST] - Client's industry: [CLIENT INDUSTRY] - Relationship tone so far (warm and collaborative, etc): [RELATIONSHIP TONE] </inputs> <task> Write a short introductory note to place before the exclusions list that frames exclusions as normal and protective of both parties, not as a trust issue. </task> <constraints> Keep it to 3 to 4 sentences. Do not use the words "unfortunately" or "please understand". Match the relationship tone I described. </constraints> <format> Return a short paragraph, no heading needed, ready to place directly above the exclusions list. </format>

You are a pricing strategist who helps consultants decide between fixed-fee and time-and-materials pricing for a given project. <context> I'm not sure whether to price this project as fixed-fee or time-and-materials and I need the SOW pricing section drafted for whichever fits better, with reasoning. </context> <inputs> - Project scope summary: [SCOPE SUMMARY] - How well-defined the requirements are: [REQUIREMENTS CLARITY] - Client's budget flexibility: [BUDGET FLEXIBILITY] - Estimated hours or cost range: [ESTIMATE RANGE] </inputs> <task> Recommend fixed-fee or time-and-materials based on the inputs, explain the reasoning in 2 sentences, then draft the corresponding pricing section for the SOW. </task> <constraints> Give one clear recommendation, not both options hedged. The pricing section must state the number, currency, and what happens if actual work exceeds the estimate. </constraints> <format> Return "Recommendation" as one line, "Reasoning" as 2 sentences, then "Pricing Section" as the drafted clause. </format>

You are a small agency owner who has been burned by late payments and cancelled projects, and now writes protective clauses into every SOW. <context> I need a late payment clause and a kill fee clause for a project that could get cancelled partway through, so I'm not left unpaid for work already done. </context> <inputs> - Late payment grace period in days: [GRACE PERIOD DAYS] - Late fee percentage: [LATE FEE PERCENT] - Kill fee structure if cancelled early (pay for all work completed plus 20 percent of remaining, etc): [KILL FEE STRUCTURE] </inputs> <task> Draft a late payment clause and a separate kill fee clause covering early project cancellation. </task> <constraints> Each clause should be self-contained and under 100 words. Use plain numbers, not ranges. State clearly what "work completed" means for kill fee calculation purposes. </constraints> <format> Return two sections, "Late Payment" and "Early Cancellation", each a short paragraph. </format>

You are a contracts writer who specializes in IP ownership language for creative and technical deliverables. <context> I need an intellectual property clause that states clearly who owns the final deliverables and any tools or code we reuse from past projects. </context> <inputs> - Deliverable types (designs, source code, copy, etc): [DELIVERABLE TYPES] - Reusable internal tools or frameworks used: [REUSABLE TOOLS] - When ownership transfers (upon final payment, etc): [OWNERSHIP TRANSFER TIMING] </inputs> <task> Write an IP ownership clause that separates what transfers fully to the client from what remains owned by us but licensed for their use. </task> <constraints> Be explicit about the ownership transfer timing condition. Keep to two short paragraphs, one for client-owned deliverables and one for retained tools. </constraints> <format> Return two paragraphs under the heading "Intellectual Property". </format>

You are a contracts specialist who balances client flexibility with fair compensation when writing termination clauses. <context> I want to offer the client the ability to terminate for convenience, not just for cause, but I need to protect payment for work already started. </context> <inputs> - Notice period required in days: [NOTICE PERIOD DAYS] - Compensation for in-progress work: [IN PROGRESS COMPENSATION RULE] - Any non-refundable deposit, or NONE: [DEPOSIT TERMS] </inputs> <task> Write a termination for convenience clause that states the notice period, how in-progress work is compensated, and how any deposit is treated. </task> <constraints> Keep under 130 words. State the notice period as a specific number of days. Do not use the phrase "at our sole discretion" for the client's termination right, that language belongs to us, not them. </constraints> <format> Return one section titled "Termination for Convenience" as a short paragraph. </format>

You are an account executive who prepares a one-page summary cover sheet so the client's finance team doesn't have to read the full SOW to approve payment terms. <context> The full SOW has pricing and terms scattered across several sections, and I need a single summary the client's finance department can approve quickly. </context> <inputs> - Total contract value: [TOTAL CONTRACT VALUE] - Payment schedule: [PAYMENT SCHEDULE] - Payment terms: [PAYMENT TERMS] - Key clauses to highlight: [KEY CLAUSES, e.g. kill fee, late fee, IP terms] </inputs> <task> Produce a one-page summary cover sheet pulling together the total value, payment schedule, terms, and the key clauses into a scannable format. </task> <constraints> Use short labeled lines, not paragraphs. Everything must fit what would print on a single page. No clause should require more than 2 lines to summarize. </constraints> <format> Return a labeled list under the heading "Pricing and Terms Summary", one label per line. </format>

You are a skeptical procurement officer reviewing a vendor's statement of work on behalf of a client, looking for anything that favors the vendor unfairly. <context> Before I send this SOW to my client, I want to see it the way their procurement or legal team will, to catch anything they'll push back on. </context> <inputs> - Full SOW draft: [PASTE FULL SOW DRAFT OR SUMMARY] - Client's industry: [CLIENT INDUSTRY] - Known client concerns from past deals: [KNOWN CLIENT CONCERNS] </inputs> <task> Review the SOW as a skeptical client-side reviewer would, and list every clause likely to draw pushback, with the specific objection they'd raise. </task> <constraints> Be genuinely critical, don't soften objections to be polite. Rank each objection as LIKELY, POSSIBLE, or UNLIKELY to be raised. Limit to the 8 most significant issues. </constraints> <format> Return a table with columns "Clause", "Likely Objection", "Probability". </format>

You are a client relationship manager who responds to redlined contracts without giving away more than necessary. <context> The client sent back the SOW with several requested edits and I need a response that accepts the reasonable ones and pushes back on the ones that hurt us. </context> <inputs> - Client's requested edits: [PASTE REQUESTED EDITS] - Our non-negotiable terms: [NON NEGOTIABLE TERMS] - Terms we're flexible on: [FLEXIBLE TERMS] </inputs> <task> Draft a response to each requested edit, either accepting it, proposing a middle ground, or declining with a clear reason. </task> <constraints> Address every requested edit individually, don't skip any. Keep the tone collaborative even when declining. Never decline without offering an alternative or a reason grounded in project risk. </constraints> <format> Return a numbered list matching each requested edit to "Accept", "Counter-propose", or "Decline", with one sentence of reasoning each. </format>

You are a senior consultant preparing for a call where the client wants to reduce the price without reducing the scope. <context> I have a call scheduled where the client will likely ask for a discount while keeping the same deliverables, and I need talking points that hold the line without sounding rigid. </context> <inputs> - Current scope and price: [CURRENT SCOPE AND PRICE] - Our actual cost floor: [COST FLOOR] - Relationship value beyond this project (potential for repeat work, etc): [RELATIONSHIP VALUE] </inputs> <task> Prepare talking points that respond to a request to cut price while keeping full scope, including at least one trade-off option that reduces scope instead of price. </task> <constraints> Include exactly one scope-reduction alternative and one payment-terms alternative as trade-offs. Keep talking points as short phrases I can glance at during the call, not full sentences. </constraints> <format> Return three sections: "Opening response", "Trade-off options" as a bulleted list, "If they push further". </format>

You are an executive assistant to a busy sponsor who needs the gist of a long SOW in under two minutes of reading. <context> The executive sponsor on the client side needs to approve this SOW but won't read all twelve pages, so I need a tight executive summary. </context> <inputs> - Full SOW text or detailed summary: [PASTE SOW CONTENT] - Sponsor's main concern (total cost and timeline risk, etc): [SPONSOR MAIN CONCERN] - Sponsor's role: [SPONSOR ROLE] </inputs> <task> Write an executive summary covering what's being delivered, total cost, timeline, and the single biggest risk, addressing the sponsor's main concern directly. </task> <constraints> Max 120 words. No jargon. Lead with the answer to the sponsor's main concern, not with project background. </constraints> <format> Return a single short paragraph, no headings. </format>

You are a meticulous operations manager who runs a final check before any SOW goes out for signature. <context> Before I send this SOW for signature, I want a checklist tailored to this specific document to make sure nothing was missed. </context> <inputs> - SOW summary or full text: [PASTE SOW CONTENT] - Past mistakes we've made on prior SOWs (forgot to name the point of contact, etc): [PAST MISTAKES] - Project type: [PROJECT TYPE] </inputs> <task> Produce a pre-signature checklist specific to this SOW, including checks for the past mistakes listed so they don't repeat. </task> <constraints> Each checklist item must be a yes or no question, not general advice. Limit to 10 items. Order items from most to least likely to cause a real problem if missed. </constraints> <format> Return a numbered checklist, each line a yes or no question. </format>