You signed because the deck made sense. The scope was clear, the timeline looked reasonable, the price was within range. Three weeks in, the vendor is asking questions they should have asked before quoting. The timeline is slipping. The scope is being "clarified" — which means it's being changed.
This pattern is not bad luck. It's a structural problem with how proposals get written and how buyers evaluate them. Most proposals are written to win the deal, not to execute the work. The two documents look the same. They are not.
If you've signed a few of these and watched them unravel, you already know the cost isn't just the money. It's three months of your operations team absorbing chaos that shouldn't exist.
A proposal that wins is a sales document. A proposal that can be executed is a project plan disguised as a sales document. The difference shows up in what's missing.
A winning proposal tells you what you're getting: deliverables, milestones, a price, a timeline. A proposal that can be executed tells you the same thing — plus how the work will actually get done, who is responsible for what on both sides, what assumptions the timeline depends on, and what happens when those assumptions break.
The second one is harder to write. It requires the vendor to have already thought through the work, not just the sale. Most don't, because most don't have to. The market rewards proposals that close, not proposals that hold up.
You don't need to be a project manager to evaluate this. You need to read the proposal looking for specific things — and notice what's missing.
An executable proposal references your operation by name. It mentions your current tools, your team structure, the specific systems the work will touch. A proposal that talks about "industry best practices" and "proven methodologies" without naming a single thing about your company was written before the vendor understood your situation. They will understand it later, on your dime.
If the proposal could be sent to any company in your sector with a find-and-replace on the logo, it's not a proposal. It's a template.
Ask yourself: who from the vendor's side wrote this proposal, and who is going to execute it? In most firms, those are different people, and the handoff between them is where projects start to leak.
An executable proposal names the delivery lead, describes how they get briefed, and explains what happens in the first week. A weak proposal lists "our team" and uses passive voice for everything that happens after signing.
Every timeline depends on assumptions. "Your team will provide approvals within 48 hours." "Your IT will grant access to the CRM by week one." "Source data will be in the format described in appendix B."
A proposal that lists its assumptions is telling you what the vendor needs from you to hit the timeline. A proposal that doesn't list assumptions is telling you the timeline will slip and the vendor will blame you when it does.
"Includes implementation of CRM" is not a scope. "Includes configuration of HubSpot for two pipelines, with the objects and properties described in section 3. Does not include migration of historical data from the legacy system, which can be scoped separately" is a scope.
If the vendor isn't willing to write down what's NOT included, they're keeping the option to argue about it later when it costs you time.
This is the one most buyers skip. A proposal can list deliverables clearly and still be unexecutable, because deliverables don't tell you how the work flows. For software or operations work, ask to see a flow, a wireframe, a process map — something that shows you what the working system looks like, not just what will be handed over at the end.
If the vendor can't show you what it will look like before you sign, they don't know yet. That's fine — but they shouldn't be quoting a fixed price for something they haven't designed.
Here's the test that filters most of this in five minutes.
Imagine you had to deliver this project yourself, starting Monday, using only what's written in the proposal. Could you?
Could you tell your team what to do on day one? Could you tell them who's responsible for what? Could you tell them which decisions are already made and which are still open? Could you tell them what "done" looks like, concretely enough that two people would agree on it?
If the answer is no — and it almost always is — the proposal is incomplete. Which means the gap between what's written and what's needed to execute is going to be filled during the project, by your team, in real time, while the clock is running.
Two things, in order.
First, ask the vendor to walk you through how the first 30 days will work, in detail. Not the milestones — the actual work. Who is doing what, in what order, with what input from your team. If they can't do this without hedging, the proposal isn't ready.
Second, ask to see the design before you commit to the build. For a complex implementation, this might mean paying for a discovery or mapping phase separately. That sounds like extra cost. It's actually the opposite — it's paying for the part of the project that determines whether the rest of it works, before you're locked into a fixed price for work that hasn't been designed.
A vendor who pushes back on this is telling you they want the full commitment before they've done the thinking. That's a structural risk, not a negotiation tactic.
The healthiest version of this process — for a complex implementation — looks like this: you see a complete design of how your operation will work after the project. Not a slide deck describing it. The actual structure: the pipelines, the objects, the automations, the integrations. You review it, you ask questions, you push back. The vendor adjusts. Once you've approved the design, the implementation is execution against a document you both already agreed to.
If you want to see what a proposal looks like when it's been designed this way — for companies that sell projects and need their CRM, operations, and finance connected — you can review the full model, including the structure, pricing, and timeline, before any conversation happens. See how the implementation is designed and priced here.