How to Use AI to Write a Consulting Proposal

You have a proposal due Friday and your discovery notes live in four places. Here is how to use AI to write a consulting proposal from them without handing it the decisions that are yours.

A notebook from the call. An email thread where the client corrected himself. A spreadsheet export. A transcript of the ten minutes you spent with the one person who knows what is going on.

A model can read all four and hand you a proposal in about two minutes. It will be wrong in ways you won't see until the client does.

The method is short. Put every source into one thread. Make the model sort what the client said from what you are guessing. Build the proposal one section at a time, set the scope, the price and the promises yourself, then have a second reader check the draft against your notes.

Let the model do the reading. You do the deciding.

You are not early to this. A 2025 LexisNexis report on management consultants found that 80% of them already use generative AI in their day-to-day work. The risk is using it as the author. The better use is the fastest reader you have ever hired.

Ask for "a consulting proposal from these notes" and you get a clean, confident document with a price on page three. I tried it on a made up engagement. The price it chose sat just under a budget ceiling the client had shared in confidence, and we will get to that.

Every step below is a prompt you can type, the reply that came back, and what was kept or cut.

Use AI to write a consulting proposal from one thread, not four tabs

Calloway Supply does not exist. I made it up so that no real client's file ends up in a blog post. It is a regional HVAC parts distributor with three warehouses and about 140 staff, it switched ERP systems eight months ago, and orders have shipped late ever since. You are the operations consultant they called.

Your discovery left you with four files. Here is what each one holds and what is wrong with it, which is the point of the exercise:

Upload all four into one Magai thread before you type an instruction. This is the capability the rest of this post leans on. The model works from your files instead of from what it remembers about distributors, and every later step happens in the same thread, so the ledger you build in step two is still in view when you ask for a price in step six. Switch models partway through and the thread's memory does not reset.

One thread matters for a second reason. A model that can see the email and the spreadsheet together can notice that they disagree. Four separate chats cannot.

Name the files for what they are, because the model quotes the names back to you. "call_notes" is a better name than "Untitled 3", and it makes every row of the ledger you build next easier to check.

If you have turned an export into a narrative before, this is the same habit that makes client reporting hold up: the model works from the file and you check it against the data. A teacher doing the same job with a standard and a reading, as in AI for lesson planning, follows the identical shape. The material changes. The method does not.

Long inputs have a known weak spot. Researchers reported in 2023 that language models use information at the start and end of a long input better than information buried in the middle, in a paper called Lost in the Middle that later appeared in the journal TACL. Models have changed since then, and I would still not bet a proposal on the gap being closed. That is why the first prompt makes the model name the file behind every claim.

These are a client's files, so one fact belongs here: Magai never uses your prompts, files or outputs to train any model, from any provider on the platform.

Start the thread with /Claude and attach the four files. Keep a different model in reserve for the check at the end.

Build a ledger before you write a word

The first prompt writes nothing. It sorts. You type this with the files attached:

I'm a solo operations consultant. These four files are everything I have from discovery with Calloway Supply. I'm writing a proposal due Friday. Do not write it yet. First build me a ledger as a table with these columns: What the client said (with the file it came from), What I am inferring, Conflicts between sources, and What I still need to confirm before I send. Do not invent anything that is not in the files. If two sources disagree, show both and do not pick one.

The reply was a table of thirteen rows, with a file named in every one. It caught the conflicts that would have sunk a careless draft:

The staffing row shows why the file names matter. In the column for what the client said, it set Marcus's plan to hire twelve pickers beside Luis's account that Fort Wayne has 31 pickers, is overstaffed on first shift and short on second. In the inference column it wrote that the evidence raises a question about shift-level staffing and work distribution, "rather than simply total picker headcount." That is a good inference, and the ledger keeps it labeled as one.

It also got one thing wrong, and it got it wrong by being careful. One row said the spreadsheet "does not show a baseline that verifies" Priya's claim that returns doubled. It does. Fort Wayne logged 41 and 44 mis-pick returns in January and February, and Toledo logged 38 and 35. In October they logged 113 and 95.

Returns are up more than two and a half times. Priya understated her own problem.

A model that hedges on something the spreadsheet settles is costing you a stronger opening. Check every "the data does not show" against the data.

Before you write anything, give every row one of three marks: settled, ask or park. Settled means the files agree. Ask means you need an answer from a named person. Park means it is real but not for this proposal, like Lima. A conflict with no mark by the time you start drafting turns up later as a sentence the client disputes.

Here is the objection you are already forming: if the model needs this much checking, why not write the thing yourself? Because the reading is the slow part, and the model did the reading. What came back is a table you can check in one sitting, row by row, with the file named in every row.

Write the problem in the client's own numbers

Now the first section of the proposal. Type this in the same thread:

Now write the first section of the proposal: the problem, in two short paragraphs, in the voice of someone talking to Marcus. Use only what is in the files and the ledger. Use at least one number from the CSV. Then write three goals as measurable outcomes. Where a number is not in the files, leave a blank in square brackets instead of making one up. No consulting jargon.

The reply opened with a true sentence: "in October, 71% of Toledo orders and 66% of Fort Wayne orders shipped within 24 hours." It left the goals as blanks, such as "[ ]% of orders ship within 24 hours" by a bracketed date, and it invented no targets. That is the right behavior.

A target is a number the client's own history has already proved. Toledo shipped 91% of orders inside 24 hours in January, so "back to January" is a goal Marcus can believe. Whether 85% or 91% is the right line for his contractors is a judgment about his customers, and the model has never met them. Let it draft the sentence and write the number yourself once the baseline is checked.

Of the three goals it drafted, the third is the one worth keeping: the share of checked bin locations that match the system record. It measures the cause instead of the symptom.

The reply also buried the story. The spreadsheet has a number that does more work than October's.

Fort Wayne shipped 89% of orders within 24 hours in January. In October it was 66%.

The fall was not gradual either. Between March and April, Toledo dropped from 87% to 71% and Fort Wayne from 85% to 66%. Luis says cycle counts stopped in April.

Those two facts sitting side by side are the diagnosis. The model had both and never put them in one paragraph.

It also hedged twice, once per paragraph, with lines like "the data does not establish why." In a ledger that is honest. In the opening of a proposal it tells Marcus you do not know what you are doing. Cut both and ask again:

Rewrite the first paragraph so it opens on Fort Wayne's January and October numbers, then the March to April drop at Toledo and Fort Wayne. Keep every figure traceable to the CSV. Cut any sentence that says the data does not establish something. Those belong in the ledger, not in the proposal.

Draw the scope line yourself

Scope is where a fixed fee lives or dies, and a model will draw the line wherever your risk is lowest. Ask for three lists:

Write the scope section in three lists. In scope: every deliverable specific enough that a stranger could check it was delivered. Out of scope: the adjacent work the client will assume is included and is not. Assumptions: what must be true for the timeline and fee to hold. Rules: Lima is out of scope for the core work. The ERP integrator is not contacted until Marcus says so. Do not invent facts. If an assumption depends on something I have not confirmed, mark it [CONFIRM]. Keep each list under eight items.

The format was right. Seven items in scope, seven out, seven assumptions, each unconfirmed one tagged [CONFIRM]. The out-of-scope list was as long as the in-scope list, which is what keeps a fixed fee from turning into free work in month two.

The content was wrong in one place that matters. It put the physical relabeling of bins and the one-time inventory count out of scope. Marcus's one instruction was to find the real cause and fix the process. A proposal that delivers a report to a client who asked for a fix is a proposal for an awkward call in week seven.

The model drew the line where your risk is lowest. The client drew it somewhere else. Moving it is your call, so you make it in the next prompt.

Check each in-scope line against the test the prompt set: could a stranger verify it was delivered? One line failed. It promised "a sample-based bin check" and left the sample open, which nobody can verify. You choose the number of bins per site and write it in, and the line becomes checkable. The model cannot pick that number, because it depends on how big Fort Wayne's floor is, and you will learn that from Luis.

Leave the [CONFIRM] tags in until each one is confirmed. They turn into your call sheet for Thursday: does Priya agree February 20 is the date, can you get second shift access, who owns the work after you leave. Two lines of the scope are worth keeping exactly as they came back. Lima stays out, and the integrator stays untouched until Marcus gives the word.

Lay out the phases and check every date yourself

This prompt carries the scope change and asks for the calendar:

Scope change from me: the physical bin relabel and a one-time full count at Fort Wayne and Toledo ARE in scope, done by Calloway's staff under my direction, because the client asked me to fix it and not just report. Dayton gets the bin check only.

Now lay out the work in three phases with weeks, and for each phase list what the client can see at the end of it and what I need from them. Work back from a February 20 end date and assume kickoff on Monday, January 5. Do the week math explicitly and tell me if it does not fit.

The reply was a clean three phase plan across seven weeks, split two, three and two, with every week dated. The week math was right. The year was the trap.

The reply opened with "This is a 2026 schedule: January 5 is a Monday and February 20 is a Friday." Nobody had given it a year. The files cover January to October of this year, so the February 20 deadline lands in 2027, when January 5 is a Tuesday and February 20 is a Saturday. The typed "Monday" was wrong too, and the model went along with it.

Type the fix:

Correction on dates: the files cover January to October of this year, which is 2026, so the deadline is February 20, 2027. Redo only the week math. Use weekdays with the year. Kickoff is Tuesday, January 5, 2027. Tell me if February 20, 2027 lands on a working day and what the last working day is.

Now the reply was right. February 20, 2027 is a Saturday, the last working day is Friday, February 19, and it flagged January 18 and February 15 as U.S. federal holidays. The federal holiday schedule from OPM confirms both for 2027. Whether Calloway observes them is a question for Priya.

Put the weekday and the year in every date you type. A model fills a missing year with a guess, and a guess that is off by one year moves every weekday. The phases, as they stood after the correction:

The reply also called the schedule "tight rather than assured," because only three weeks go to floor work and nothing in the files says how many bins need relabeling. That is the most honest line in the reply, and it belongs in your head, not in the proposal. Before you commit to February 19, ask Luis how many bins Fort Wayne has and how many people he can spare per shift. Phase 2 stands on that answer.

Each phase also came back with a list of what you need from Calloway: order detail with timestamps, location lists, shift schedules, named site leads. Keep that column. Clients skim past it and then blame you later for waiting on their data.

Set the price yourself and keep the client's number out of it

Run one experiment before you give the model any numbers. Type the lazy version:

What should I charge for this engagement?

The reply said "I'd propose a fixed fee of $78,000," split into $18,000 to diagnose, $45,000 to implement and $15,000 to validate, and noted that this "sits below Marcus's stated $85,000 ceiling."

Marcus wrote "between us I can stretch to 85" in a confidential email, and the model priced to it. A fee built from the client's ceiling is a guess at how much he can bear, with your name on it. The split is invented too. Nothing in the files supports $45,000 for implementation.

Price is the decision the model has the least basis for. Make it yourself, then hand it the number:

Now the fee section. The numbers are mine, so do not use any budget figure from the files and do not suggest a different price. My three options:
Option A, Diagnose and plan: weeks 1 and 2 only, $16,500.
Option B, Diagnose, fix and verify: all three phases, $64,000. This is the one I recommend.
Option C, Option B plus 60 days of follow-up and a routing review for the Lima site: $79,500.
Do the arithmetic. Show what each option costs per week. Write the fee section in plain language for Marcus, with one sentence on what changes between tiers. Then write a short payback block for Dennis with blanks in square brackets for every number that is not in the files. Do not guess any of the blanks.

The arithmetic was right: $8,250 a week for Option A and $9,142.86 for Option B. Three things needed fixing.

1. The per week column showed Option C at about $5,105.50, which made the biggest option look like the cheapest. Cut the column.
2. One table cell still contained the model's own mid-thought correction, starting with the word "Wait". Read the table cells, because a model can leave its scratch work in them.
3. Option C included a Lima routing review while the scope said Lima is out. The fix is a line in the scope that makes the Lima review an add-on that exists only in Option C.

The payback block was the best part of the reply. It left every cost figure in square brackets and said the files do not establish them. Keep it that way. Fill the blanks from Calloway's own numbers: what a mis-pick return costs them and what a late order costs. Priya has them. A model's guess at a cost per return is worth nothing to a CFO.

Option B at $64,000 is over Dennis's $50,000 line, so the payback block is the page he reads. The fee section as it ships:

Name the risks, including the one with a name

A risk section builds confidence when it is specific. Ask for it in three lists:

Write the risk section. Three short lists. Risks: each with likelihood (low, medium, high), what it would do to the timeline or result, and what I do about it. Dependencies: each with who owns it and the date it is needed by, working from kickoff on Tuesday, January 5, 2027. Assumptions that would make my read of the problem wrong. Rules: surfacing a risk should build confidence, not undermine it. Use only facts in the files. Name people where the files name them.

The reply gave four risks, six dependencies with an owner and a date each (most due January 8 or January 15), and five assumptions that could make the read wrong. It rated the deadline risk high, correctly, because the date lands on a Saturday. The dependency list is the useful part, because a data export that lands in week three is how a seven week plan slips.

A line like "Priya, by Friday, January 8" can be done. "Calloway will provide data" cannot. Each dependency needs one owner and one date. Then add the consequence in your own words, because a dependency list with no consequence is a wish list:

Add one sentence under the dependencies stating what happens to the February 19 end date if any dependency arrives late: the end date moves by the same number of working days unless we agree a change in writing.

The model will word it nicely. The rule is yours, and it is the sentence you will point to in week four if Priya's export arrives in week three.

The reply missed the likeliest way this engagement goes sideways. Marcus has decided the problem is headcount and wants to hire twelve pickers. The findings may say he is wrong. Add that by hand: the findings may not support the hiring plan, likelihood medium, and the response is to walk Marcus through the evidence before the report is written, with Priya in the room.

The second problem is a leak. The risk list says Luis reports a second shift backlog at Fort Wayne. Marcus reads this document, and Luis told Marcus about his concerns in May and was told to wait for the integrator. Naming him puts a warehouse manager in the crosshairs for being right. Fix it with one more prompt:

Rewrite the risks and dependencies for a document Marcus will read. Remove the name of anyone who spoke to me in confidence and describe what I will observe or measure, not who said it.

Have a second reader check the draft against your notes

Stitch the sections together in order and send the whole draft to a reader that did not write it. Give it only the files and the draft, and give it three jobs:

You are checking this proposal draft before it goes to the client. You were not involved in writing it. Do three things.
1. List every sentence in the draft that states something as fact that is NOT in the source files. Quote the sentence and say what is missing.
2. List every number in the draft and trace each one to a file, or mark it as the consultant's own number.
3. List anything in the draft that the client's COO, Marcus, should not read because a staff member said it in confidence or because it contradicts what Marcus believes, and say why.
Be strict. Do not rewrite the proposal.

It earned its place. The check caught four things I would have shipped:

1. A leftover paragraph. When I stitched the sections together, the first week math sat above the corrected one, including the line that said "This is a 2026 schedule." Stitching errors are yours, and the check found it.
2. Option C still included a Lima review while the scope excluded Lima.
3. Luis's staffing comments and his account of telling Marcus in May, both flagged as things Marcus should not read in that form.
4. The sentence "That suggests hiring more people may not solve the problem by itself," flagged as a conclusion the evidence has not earned yet, aimed straight at Marcus's plan.

It was too strict in places. It flagged my own prices, the holiday dates and the calendar as "not in the source files." Of course they are not. They are yours or they are calendar facts. The reply sorted those into their own list, so skipping them took seconds.

You have two ways to run the check in Magai. Start a new thread with just the files and the draft, or switch the model inside the same thread and keep the ledger in view. I prefer the new thread, since a model reading its own draft has no reason to doubt it. Put /Gemini or /GPT at the front of the message so a different model does the reading. Claude and Gemini are built for different jobs, and the check is a good reason to use both.

The last job before Friday turns your open [CONFIRM] tags into a call sheet:

From the ledger and the [CONFIRM] tags in the scope, write the list of questions I need answered before I send this on Friday, grouped by who I ask: Marcus, Priya, Luis. One line each. Do not ask anything the files already answer.

The reply was eleven questions, four for Marcus, five for Priya and two for Luis. Two of them were answers the files already held. It asked whether you can proceed without contacting the integrator, and Marcus's email says not to talk to the integrator yet. It asked Priya what baseline supports "returns doubled," and the spreadsheet is that baseline. Cut both.

The rest were the right questions. The best was the one for Luis about whether cycle counts have resumed since April, because the answer tells you whether the problem is still growing.

Save the method so Friday starts at step two

Everything above is a sequence you will repeat for every engagement, so stop retyping it. Put the rules in an agent. An agent in Magai is a set of reusable custom instructions that runs on any model, which means the rules follow you when you switch from drafting to checking. Paste this into a new agent:

You help me turn discovery material into a consulting proposal.
1. Work only from the files in the thread. Name the file behind every claim.
2. Keep what the client said separate from what I infer.
3. Never choose a price, a start date or a promise. If I have not given one, ask me.
4. Leave a [blank] for any number the files do not contain.
5. Write every date with its weekday and year.
6. Never name a person who spoke to me in confidence in anything the client will read.
7. When two sources disagree, show both and do not pick one.

Rules 3 and 6 came straight out of the two things that went wrong: a price chosen from the client's ceiling, and a warehouse manager named in a document his boss would read. If you want the longer walk through building one, how to build an AI agent goes step by step without code.

Keep a folder for each client and drop the four files in it. Folders in Magai organize your chats, so the thread, the ledger and the draft all sit beside the source material the next time Marcus calls back with a change. Three engagements at once is where this pays, and the consultants page shows how the rest of a practice fits in the same workspace.

The next time a discovery call ends, the whole routine is short. Open a thread with the agent, attach the four files and type one line:

Build the ledger.

The agent already knows the rest. You are at step two before the call notes finish saving.

Open a thread at app.magai.co, attach your four files, and let it read. You decide.