The prompt
Score 10 of 10, Excellent
Use it when You are hiring a freelancer, agency or contractor for part of a project and need deliverables, acceptance criteria, dates and payment written down before work starts.
- {{work_description}}
- {{contractor}}
- {{approver}}
- {{payment}}
- {{dates}}
- {{our_inputs}}
- {{notes}}
Full prompt and why it works
The work being contracted: {{work_description}} Contractor: {{contractor}} Our contact, and who approves deliverables: {{approver}} Budget and how we will pay (fixed fee, by milestone, or time and materials): {{payment}} Key dates: {{dates}} What we will provide (access, content, people, equipment): {{our_inputs}} Notes from discussions with the contractor, including any proposal they sent: """ {{notes}} """ Task: Draft a statement of work for the work above, for {{approver}} and the contractor to review, so that both sides know exactly what will be delivered, when, how it will be accepted and what it costs. Most disputes with contractors start from a vague scope, so be specific. Use these headings: 1. Background and objective: two or three sentences. 2. Scope: the work included, as a numbered list. 3. Out of scope: what is not included, especially anything the notes suggest might be assumed. 4. Deliverables: a table with the columns Deliverable, Description, Format, Due date, Acceptance criteria (checkable by someone other than the author). 5. Our responsibilities: what we provide and by when, since late inputs from the client are a common cause of delay. 6. Schedule and milestones. 7. Fees and payment: amounts and due dates, tied to accepted deliverables where possible. 8. Review and acceptance: how many days we have to review each deliverable, how many revision rounds are included, and what happens after that. 9. Changes: how a change in scope is requested, priced and approved. 10. Contacts. Requirements: - Under 800 words. - Use only the details and notes above. If something a statement of work needs is missing, such as the number of revision rounds, write [to agree: revision rounds] rather than choosing for me. - Plain, neutral language both sides can sign up to, with no legal boilerplate. Liability, insurance, ownership of the work and confidentiality belong in the main contract; if the notes raise them, list them under a final note headed "For the contract". - This is a working draft for review, not legal advice. Example of one deliverable row's form only, with invented content: "Homepage design | Desktop and mobile layouts | Figma file | May 20 | Matches the approved wireframe; includes every section in the content brief" If the contractor's proposal and our notes disagree on scope, price or dates, list each difference at the top for me to settle before sending.
Variables
- {{work_description}}
- The project and the part being contracted, for example "redesign of our website's five main pages".
- {{contractor}}
- The freelancer or company, and their contact.
- {{approver}}
- For example "Jo Park, marketing lead".
- {{payment}}
- For example "fixed fee of $18,000: 30% at start, 70% on acceptance".
- {{dates}}
- Start, key milestones and end date.
- {{our_inputs}}
- For example "brand guidelines and page copy by May 1; weekly 30-minute review call".
- {{notes}}
- Emails, call notes and the contractor's proposal or quote.
Why it works
- What good looks like. Each deliverable has acceptance criteria someone other than the author can check, and review periods and revision rounds are set out, which is where contractor disputes usually start.
- If unsure. Anything a statement of work needs but your notes do not give becomes a [to agree: ...] placeholder, and differences from the contractor's proposal are listed at the top.
- What to avoid. It keeps to plain working terms and sends liability, ownership and confidentiality to the main contract rather than drafting legal clauses.