The client emails on a Tuesday: "Great, can you also just tweak the checkout flow? Should be quick." It's the third "quick" addition this month, none of it in the original agreement, and you're not sure what the agreement actually said, because the proposal was a friendly two-pager with the word "ongoing" in it.
Most freelance pain isn't a lack of skill. It's fuzzy scope, awkward emails and proposals written in a rush. AI is good at the writing and the poking-at-holes parts of that, and bad at the judgment parts. The prompts below are for proposals, scoping, scope-of-work (SOW) checks and tough client replies, with the limits spelled out.
All of these are untested templates. I haven't run them on a live engagement. The worked example is labelled illustrative. And none of this is legal advice.
How do I use AI to write a freelance proposal?
Separate thinking from typing. A proposal wins when it shows the client you understood their problem in their words. The model can't do that from a title. You have to give it the raw material: the client's brief or email thread, your discovery notes and a few real facts about your past work.
You are helping me, a [YOUR ROLE, e.g. freelance UX researcher], write a
proposal for [CLIENT/COMPANY].
Client's own words about the problem (paste verbatim):
[BRIEF OR EMAIL]
My notes from the call:
[NOTES, including goals, constraints, budget hints, who decides]
My relevant experience (real, no embellishment):
[2-3 FACTS]
Write a proposal with these sections:
1. Understanding of the problem (use the client's own phrases; 100 words max)
2. Proposed approach (steps, in plain language)
3. Deliverables (numbered, countable; no vague nouns like "support")
4. Timeline (assume start date [DATE]; mark dependencies on the client)
5. What is not included
6. Investment: [FIXED PRICE / DAY RATE / RANGE] and payment schedule [TERMS]
7. Next step
Rules: do not invent past clients, results or credentials. Where my notes lack
something, put [CONFIRM: ...]. Avoid superlatives. Plain, direct tone.
The [CONFIRM] flags are the same trick that works in other drafting tasks: you'd rather see a hole than a confident guess. If you need the model to match your voice, paste a paragraph you wrote and say so. For more on voice, see how to prompt AI to sound human.
Scoping questions: find the holes before you quote
Quotes go wrong at the scoping call. You didn't ask who approves, what "done" means, or what already exists. Before the call, ask the model to generate questions tailored to the project type.
I'm about to scope a [PROJECT TYPE] for a [CLIENT TYPE]. What I know:
[BRIEF]
Give me the questions I should ask on the call, grouped by:
- Outcome (what success looks like and how they'll measure it)
- Inputs (what they provide, by when)
- Stakeholders (who approves, who can veto)
- Constraints (budget, deadline, tools, compliance)
- Risks (what has gone wrong in past projects like this)
- Out of scope (things they may assume I'm doing)
Flag the five questions that most often change the price. Keep each question
short enough to say aloud.
After the call, paste your notes back in and ask: "What is still ambiguous or contradictory in these notes? List what I must confirm in writing before quoting."
SOW checker: ask the model to attack your scope
This is where AI earns its keep. Paste your draft proposal or SOW and have the model read it like a hostile, literal-minded client. Common sources of dispute are well documented in freelancer guidance: vague deliverables, no stated exclusions, unlimited or undefined revisions, no price for extra work, and no defined approval step.
Act as a client's lawyer-minded project manager who wants to get as much as
possible for the agreed price. Read the SOW below literally.
1. List every sentence where a reasonable client could expect more than I intend
to deliver. Quote the sentence and say what they might expect.
2. List every term that isn't measurable (e.g. "ongoing", "as needed", "support",
"minor changes", "quickly").
3. Check for: number of revision rounds and what counts as a revision; what
happens after the last round; who supplies content and by when; what
triggers each payment; how approval is given and what happens if the client
goes silent; how additional work is requested and priced.
4. Rewrite the three weakest clauses so they are specific and countable.
I'm not asking for legal advice. Just find ambiguity.
SOW:
[PASTE]
Freelancer guidance tends to agree on the fixes: numbered deliverables with counts, an explicit exclusions list, a defined revision (a change to agreed work, not any new request), a stated rate for extras and an approval step with a deadline. Treat those as practical conventions, not legal standards. Have a lawyer review your template once for payment terms, liability and IP.
A worked example (illustrative)
This is an invented scenario to show what the checker surfaces, not a real model transcript.
Original clause in a proposal: "Designer will provide website design and ongoing support, including minor changes as needed."
What the checker should flag:
- "website design": no page count, no device sizes, no named pages.
- "ongoing support": no end date, no hours cap, no response time.
- "minor changes": undefined; a client could call a new section minor.
- "as needed": the client decides the need.
A tighter rewrite:
Designer will deliver high-fidelity designs for up to 5 pages (Home, About,
Services, Pricing, Contact) at desktop and mobile widths. Two rounds of
consolidated revisions are included, each returned within 5 working days of
receiving feedback. A revision is a change to an agreed design, not a new page
or feature. Additional rounds or pages are quoted at [RATE] and begin only
after written approval. Support ends 14 days after final handover.
Now the Tuesday email about the checkout flow has an answer: "That's outside the five pages. Here's a quote for a change order."
Client emails: first draft by AI, last edit by you
Routine emails (status, scheduling, invoice reminders) are good AI work. Give it the facts and your tone, and it saves ten minutes.
Draft an email to [CLIENT NAME].
Purpose: [e.g. confirm scope change / chase late feedback / deliver milestone 2]
Facts: [DATES, AMOUNTS, WHAT WAS AGREED, WHERE IT WAS AGREED]
Tone: warm but businesslike. I'm [a solo consultant]. Keep under 150 words.
Include one clear next step with a date. Don't apologise unless I say to.
For invoices, add: "Reference the invoice number, due date and payment terms from the agreement. State the facts without sounding accusatory." Use the model to soften the phrasing, never to alter the amounts or dates.
How do I reply to a difficult client?
Draft with AI, but not in the heat. A good sequence is: write the angry version for yourself, paste it in, then ask for a professional version that keeps the facts and drops the heat.
Below is a message from a client, and below that my rough, unfiltered reply.
Rewrite my reply so it:
- keeps every factual point and my position
- removes sarcasm, blame and anything I'd regret in a screenshot
- refers to what the agreement says (quote the clause I paste)
- offers one concrete way forward
- is under 150 words
Client message: [PASTE]
Relevant agreement text: [PASTE]
My rough reply: [PASTE]
Also tell me what the client is probably feeling and whether I should reply in
writing or suggest a call.
Common scenarios, with the angle to give the model:
| Situation | Give the model | Ask for |
|---|---|---|
| Scope creep | The clause and the new request | Polite decline plus change-order offer |
| Late feedback delaying the timeline | Dates feedback was due | A message resetting the schedule and naming the delay's effect |
| "Can you do it cheaper?" | Your real cost floor and what could be cut | Options that reduce scope, not just price |
| Late payment | Invoice date, terms, previous reminders | A firm, escalating-but-civil reminder |
| Dissatisfied with work | Their specific complaints, the brief | A reply that separates fact from feeling, with a fix proposal |
The model can't read the relationship. It doesn't know this client is a friend of your best referrer. Check tone against what you know before you send.
Reusing it: a project context block
If you use the same chat tool for every client, set up a reusable block at the top of each project chat so the model has the facts without you retyping them. This is what a Claude or ChatGPT project is for; see Claude projects and ChatGPT projects and custom instructions.
CLIENT: [name, company, main contact, decision maker]
PROJECT: [one-line description]
AGREEMENT: [key terms: scope, price, payment dates, revision rounds]
STATUS: [current milestone, open items]
TONE WITH THIS CLIENT: [formal / casual / brief]
DO NOT: invent facts, promise dates or prices not listed here.
Keep client confidential material out unless your contract allows the tool. Many clients have rules about AI use, so check before you paste their documents.
What not to hand to AI
- Price. The model doesn't know your costs, your pipeline or how much you want this client. Use it to compare structures (fixed, retainer, tiered), never to pick your number.
- Legal terms. Liability, IP ownership, termination and jurisdiction need a lawyer's review of your template.
- Claims about your experience. It will happily polish things that never happened. Every claim in a proposal must be true and checkable.
- The decision to take the project. A model will help you write for any client. It won't tell you the client is a red flag unless you describe the red flags.
- The final send on anything with money or deadlines in it. Check each figure and date against the agreement, every time.
If you work with Indian small businesses or startups, prompts for small business owners and prompts for Indian startup founders show the other side of the table. Giving context is the lesson behind why the proposal prompt asks for so much input, and the prompt library has more templates to copy.
