The proposal that closed in 48 hours and cost you the margin
Picture a B2B services shop — say a 60-person managed-IT or integration firm. A rep gets an RFP on a Thursday, opens an AI assistant, pastes in the discovery call notes, and asks for a proposal. By Friday afternoon a clean, confident, twelve-page document is in the buyer's inbox. Everyone celebrates the turnaround. Six weeks later delivery discovers the AI quietly promised a two-week migration window that the team has never hit in under five, priced a tier of support the firm doesn't profitably staff, and reused a security attestation from a deal in a different regulatory environment. The fast proposal didn't create ROI. It created a scoping problem that now has a signature on it.
This is the specific failure mode of proposal drafting, and it's why this workflow is different from automating, say, meeting notes or a status email. A proposal is the document where sales speed and commercial risk collide hardest. It bundles together the things your firm is most protective of — approved service descriptions, delivery assumptions, pricing floors, contract guardrails — and hands them to whoever is most motivated to bend them to win the deal. Bolt a generative model onto that without rails and you haven't sped up writing; you've sped up the rate at which your delivery and finance teams inherit commitments they never approved.
So the ROI question is not "how many minutes did drafting save?" It's narrower and harder: did the response go out faster and stay inside the boundaries that protect your margin? The honest answer for most early pilots is that the draft got faster while the review loop got longer, because reviewers now had to hunt for what the model invented. IBM's workflow automation framing is useful here — automation pays off when it removes a handoff, not when it just accelerates the keystrokes inside one.
Govern the inputs, or you're just generating risk faster
The single decision that separates a proposal workflow that earns its keep from one that quietly leaks margin is what the model is allowed to draw from. Generic prompting lets it write from the open internet and its own confidence. A governed workflow can only assemble from a controlled library: the service descriptions legal has cleared, the pricing rules deal desk maintains, the delivery assumptions your PM org will actually stand behind, the case evidence you're licensed to cite, and the security and contract language tied to the buyer's actual environment. The CRM provides the deal context — buyer, segment, prior touches — but it never provides a commercial term. The model proposes; your approved source material disposes.
The practical test: every draft should be traceable. For each non-boilerplate claim — a timeline, a price, a delivery commitment, a compliance statement — the workflow should show which approved source it pulled from, and flag any section it could not source as requiring a human to fill it in rather than inventing something plausible. A proposal that can't show its sourcing isn't faster; it's just harder to audit. This is the throughline across McKinsey's State of AI work, Gartner's sales research, and PwC's responsible-AI guidance: source control and provenance aren't compliance theater, they're the precondition for trusting the output enough to ship it.
Then there's the adoption trap that's specific to sellers. Reps are graded on closed revenue, not on process hygiene. If the governed workflow feels slower or more restrictive than their personal "kitchen-sink" template, they will route around it — and you'll have built an expensive system that produces shadow proposals you can't see. So track adoption as a first-class metric alongside cycle time: what fraction of proposals actually originated in the governed path versus a side document? MIT Sloan's AI coverage keeps landing on this point — the tools that stick are the ones that make the compliant path the easiest path, not the one with the most guardrails.
Run it on one deal shape and watch three numbers, not one
Don't pilot this across the whole sales org. Pick one repeatable proposal shape — the deal type your firm sells most often, with known reviewers and enough monthly volume to read a trend. For a services firm that's usually a standard engagement or a renewal-plus-expansion, not the bespoke seven-figure custom build. Before you turn anything on, write down the baseline: median response time, number of review rounds, how often delivery rewrites the scope after the fact, how often pricing lands outside the approved band, and the realized margin on those deals. You're not measuring drafting speed. You're measuring whether speed arrived without dragging margin down with it.
Then run a weekly read on three numbers held together: speed (did response time actually drop?), control (did pricing and delivery commitments stay inside approved bounds, and did review rounds fall rather than rise?), and margin (did the realized margin on piloted deals hold or improve?). The pattern tells you what to do next. Faster but margin slipped? Not ready — your sourcing rails are too loose. Cleaner and in-bounds but reps avoid it? Your constraint is adoption, not the model. Faster, in-bounds, and sellers keep choosing it on their own? That's the one combination that earns expansion to the next deal shape.
The discipline that makes this work is refusing to let any single number stand in for ROI. A proposal workflow that wins on speed and loses on margin is a worse business than the manual process it replaced — it just fails more efficiently. Model the economics for your own deal mix with the AI ROI Calculator before you commit, and if you want a governed path from one proposal shape to a production workflow without learning the margin lessons the expensive way, that's exactly the scope of the 90-Day AI Implementation Sprint.
