Ask anyone who has put together a statement of qualifications, an SF 330, or a proposal at an engineering or architecture firm where the time goes. You rarely hear "writing." You hear "finding." Which past project best fits this client? Where is the current version of that résumé? Who rewrote the stormwater project description last spring, and which folder did it end up in?
Most of what a good SOQ or proposal needs already exists in the firm's files. The work is pulling it together, adapting it, and checking it, under deadline, usually by the same few senior people who are also needed on billable work.
That makes proposals one of the most sensible places to start with AI. It is also where firms are rightly cautious, because what goes out carries the firm's name. Here is how we approach it.
Start from your best past work, not a blank prompt
The common first attempt is to paste an RFQ into ChatGPT or Copilot and ask for a proposal. What comes back sounds fluent and generic, and it is not grounded in anything your firm has actually done. That is exactly the kind of output that erodes trust.
The better starting point is a small, curated set of your own material:
- Three to five past submissions your team considers strong
- Current project sheets and team résumés
- Your firm's standard boilerplate and the sections you never change
- The request you are responding to
The assistant is set up to draft from that material and to name the file behind each project or person it suggests. How neatly it can cite depends on the tool, so part of testing is confirming a reviewer can trace every claim back to a source document.
Break the task down before you automate it
Before building anything, we write the task out in five plain questions:
- Start: What kicks it off, and who decides to pursue?
- Know: What does it need to know: which files, which past work?
- Do: What does it produce: a full draft, a project matrix, tailored résumés?
- Check: Who reviews it, and against what?
- Deliver: Where does the draft go, and who is told?
Writing these answers down usually shows that "write the proposal" is really three or four smaller tasks. Some suit AI well, like assembling relevant projects and adapting descriptions. Others should stay with people, like the win strategy and the fee.
What this looks like on one pursuit
Here is an illustration, not a client story. A 40-person civil firm sees an RFQ for a municipal stormwater study. Today a marketing coordinator and a senior engineer spend days pulling relevant projects, resizing résumés, and rewriting project descriptions to match the evaluation criteria.
With a first version in place, the coordinator gives the assistant the RFQ and asks for a draft qualifications section. It proposes five past projects from the firm's project sheets, with the source file named for each, drafts tailored descriptions against the stated criteria, and flags where it found nothing relevant. The senior engineer's time moves from assembling to judging: swapping one project, correcting a figure, sharpening the approach. The format still follows the client's template or SF 330 Part I as usual.
The point is not that the draft is perfect. It is that people start from something grounded in the firm's own record instead of an empty page.
Keep the review step where it already is
AI changes who writes the first draft. It should not change who signs off. In a sound setup:
- The project manager checks project facts, dates, and figures against the source files.
- The principal reviews positioning and anything that reads as a commitment.
- Nothing the assistant drafts goes out without that review. AI never signs, seals, or stamps anything.
If the review step takes as long as writing from scratch, the setup is not working yet, and that is worth knowing early.
Keep the files where they are
None of this requires moving project files to a new platform. Microsoft 365, Google Workspace, and the business tiers of Claude and ChatGPT can all work from material in your own accounts, under your existing permissions, on plans whose terms exclude your files from model training. If a pursuit involves restricted client information, leave it out of scope until your tools are cleared for it.
Measure it with what you already have
You do not need new timesheets to know whether it helped. Pick one or two measures you can already see, such as hours per submission, days from RFQ to first draft, or rounds of review, and note them for a handful of recent pursuits. Then compare the same measures on the next few submissions.
If the numbers don't move, that is a useful answer too.
Where to begin
Choose one submission type your team prepares often, gather a few strong past examples, and try a first version on a real upcoming pursuit, with your normal review in place. That is the shape of the half-day working session we run with firms: one task, your own files, a working first version, and an honest read on whether it is worth taking further.
If proposals are where your senior people's time disappears, tell us what's piling up.