How to Use ChatGPT or Claude to Write Client Proposals That Don't Sound Generic
Your team is already using ChatGPT or Claude to draft proposals. The output comes back fast, it is grammatically clean, and it covers all the obvious sections. It also reads like every other proposal your prospective client received this month. The fix is not a better prompt. It is giving the model something it does not have by default: the specific context that makes your firm sound like your firm.
This article walks through the exact workflow, including the parts that break in practice, so you can put it to use this week rather than spending another afternoon fighting vague outputs.
Why does the AI proposal sound like everyone else's?
The model is drawing on patterns from millions of documents. Without firm-specific input, it defaults to the center of gravity for "professional services proposal," which is a very crowded place. The problem is not that the AI is bad at writing. It is that you handed it a blank slate and asked it to sound distinctive.
The single most effective change is to paste in two or three of your best past proposals before you write the new one. Not as instructions, but as examples. Tell the model: "Here are three proposals our firm has sent in the past. Note the tone, the way we frame scope, and how we handle pricing language. I will give you the brief for a new proposal. Match the voice and structure you see in these examples." This alone produces a measurably different result because the model now has a reference population of one instead of millions.
If past proposals contain client names or sensitive commercial terms, redact those before pasting. The point is the voice and structure, not the specifics.
What is the actual workflow, step by step?
Start a new conversation and do not reuse an old thread. Context from unrelated chats bleeds into tone in ways that are hard to diagnose. Fresh thread, every time.
First, paste your two or three reference proposals with a brief framing sentence: "These are examples of how our firm writes proposals. Study the structure and tone only." Give the model a moment to confirm it has processed them before moving on.
Second, paste your brief for the new engagement. Be specific: the client's industry, the problem they described in their own words if you have a call transcript, the deliverables you have mentally committed to, any hard constraints on budget or timeline. The model cannot invent specifics it was not given, and when it tries, you get the filler sentences that undermine the whole document.
Third, ask for a draft in sections, not the full proposal in one shot. Request the executive summary first, review it, then move to scope, then to pricing rationale. Reviewing in sections catches tone drift early and gives you natural edit checkpoints. Asking for everything at once produces a document that is hard to course-correct because each section was generated in the context of the previous one's mistakes.
Fourth, after the first draft of any section, ask one follow-up question: "Is there anything in this section that sounds generic or that any firm could have written?" The model will often identify the weak sentences itself and suggest sharper alternatives. This self-review prompt consistently improves output quality because it redirects the model's attention to differentiation rather than completeness.
Where this workflow breaks down is when the brief is thin. If all you give the model is "we are proposing a six-week website redesign for a law firm," it will fill the gaps with generic assumptions. The quality of the output is a direct function of the quality of what you put in. Garbage in is still garbage in, regardless of which model you use.
What should you never let the model write on its own?
Three things reliably go wrong without a human review pass. First, the risk and exclusion language. Models write plausible-sounding scope exclusions that may not match your actual contract terms. Always verify these against your standard agreement before the proposal goes out. Second, the pricing narrative. The model will write a rationale that sounds reasonable but reflects no knowledge of your actual cost structure or margin targets. Treat pricing sections as a starting structure to be rewritten, not as a draft to be approved. Third, any specific claims about your firm's track record, such as client names, timelines, or outcomes. The model does not know your history and will invent plausible-sounding details if you leave a gap. Fill those gaps yourself or leave them as placeholders: "[insert case example here]" is safer than an AI-generated one that does not exist.
The deeper issue with proposals is that they require firm-specific voice, client-specific framing, and accurate commercial details, all three of which the model lacks unless you supply them. This is exactly the problem that a structured prompt and context system solves when it is built once and shared across a team. DSE Group's AI enablement program engineers those context layers and workflows so every person on a team is working from the same foundation, rather than each person improvising their own prompt from scratch and getting inconsistent results.
One principle worth holding onto: the model's job in this workflow is to handle the structural assembly and first-pass prose. Your job is to supply the inputs it cannot infer and to review the parts that require commercial or legal judgment. That division of labor, kept clear, is where the time savings actually materialize. When the division blurs and you start trusting the model on things it cannot reliably know, the proposal starts working against you.
If you want help building a proposal workflow your whole team can use without everyone reinventing it daily, reach out to the team at DSE Group. We work with service businesses on exactly this kind of context and workflow design, and we are happy to talk through what would apply to your firm.