Engineering a system correctly is one skill. Turning that work into a proposal a customer can understand, trust, and sign is a different skill, and most engineers only ever train the first. The ones who build both are the ones who close projects. You've done the engineering across six parts. This part is the second skill.
So start here. A proposal isn't a sales document. It's an engineering communication. Its job is to give the customer enough accurate information to make a real decision. Not enough to feel good about the system. Enough to decide. That means showing the solution clearly, documenting what it does well, and being honest about what it doesn't do.
By the end of this lesson you can assemble a proposal that carries every deliverable the customer needs to decide, state the system's limitations in their own section without softening a single one, document every assumption and exception before it becomes a dispute, and run the pre-quote gate with a second set of eyes before anything leaves the building.
The standard is enough information to make a real decision, and that turns into eight deliverables. Every one, every proposal. Module 11 named seven of them. The MHA Quoting Standards Guide is the authority for this part, and it carries an eighth that the original list left off. Here's the set.
One more sheet leads the package ahead of the eight: the executive summary. Two paragraphs, outcomes only, so a business buyer who reads nothing else still leaves with the decision. It sits on top of the stack, not inside the count.
Notice you already produced every piece of this list in earlier lessons. This lesson gathers them into one document a customer can act on. It doesn't re-teach the layout, the MTBH table, the calculations, or the maintenance plan; it assembles them.
And one document runs underneath all of it: the four-layer flow diagram. It's what makes the quote honest. A quote built from a complete flow diagram can be defended line by line. A quote built before the diagram is finished is built on assumptions, and assumptions come out of margin when they're wrong. You built that flow across Lessons 8 through 10. It belongs in the package and the project folder, not in a drawer.
You're the customer. You sign a proposal, install the system, and three weeks later you find it can't handle a product you ship every day, because the limit sat in paragraph four of the system description and you never saw it. It was technically disclosed. Was it communicated? Where should that limit have been?
New engineers want to show the good side of everything. You do highlight what the solution does well. That's fair. But the system's limitations belong in the proposal too. Weight limits. Speed limits. Throughput limits. Product size boundaries. The product types the system can't handle. All of it.
The reason's simple. If a limitation isn't in the proposal, the customer assumes the system handles it. Finding that out after installation is a great deal worse than finding it out during proposal review. The limit was always there. The only thing that changes is when the customer learns about it. You get to choose whether that's now, across a table, or later, on their floor, with product backed up behind a jam nobody warned them about. Better still, the proposal shouldn't be the first time the customer hears any of it. A limitation or a cost driver belongs in the discovery conversation; the proposal confirms what you already discussed, it doesn't introduce it, and a limit that surfaces for the first time at proposal review is itself a failure upstream, a sign discovery missed it.
The Quoting Standards Guide sets three standards, and this part is where they're binding. First, limitations live in their own labeled section. Not in paragraph four of the system description. Not in a footnote. In a section every reader lands on. Second, you list every limit the system has. If the system can't do it, you say so. Third, you don't soften a limit with a qualification. A limit is a limit. Don't write "the system may have difficulty with packages over 30 pounds." Write "the system maximum product weight is 28 pounds."
Softening a limitation to make the proposal look better. You write that the system "may have some difficulty with heavier packages" instead of stating the maximum weight is 28 pounds. The soft version reads fine and protects nothing. When a 35-pound carton jams the sorter three weeks after go-live, the customer doesn't remember a gentle qualification. They remember that nobody told them the number.
Anything you feel is a limitation of the system should never be a surprise to the customer. Show them the good side, highlight what the solution does well, but put the limits right in there. Weight, speed, throughput, product size. All of it. A customer who understands the system they're buying is a customer who stays your customer. The one who finds out after install that it can't do what they assumed is the one who calls somebody else next time.
When a customer hands you a spec, they assume you followed it unless you tell them otherwise. So every exception you took has to be called out, in plain sight. An exception you didn't document isn't an exception. It's a gap, and it surfaces later as a dispute. Silence reads as agreement.
Assumptions work the same way. Document the assumption, not just the conclusion. Don't write "system sized for 20 CPM." Write "customer confirmed 20 CPM peak throughput on call dated." One is a number you hope holds. The other is a record of who told you and when. And when you take an exception, explain why, so the customer sees the trade instead of a surprise.
Margin isn't lost when the project gets priced. It leaks earlier, while information is still missing during scoping and while vendors are working from incomplete scope. Two leaks account for most of it. The first is an unsafe assumption, and the common one is an incomplete MTBH: size the system off a guess about the product, and the system comes out wrong. The second is incomplete vendor scope. Pull cords that never made the electrical RFQ. VFDs not specified per motor. The electrical, mechanical, and controls vendors all price what you tell them, so the gap between what you scoped and what they priced comes straight out of margin.
That gap is yours, not the vendor's, because you own the scope. The discipline that closes it, checking every vendor RFQ for completeness before it goes out, was Lesson 28's work. Confirming that vendor scope in a room with the trades before the job starts is the handoff, and the handoff is Part VIII. Here, you just make sure the exceptions and assumptions that protect that margin are written down where the customer and the next engineer can both find them.
Nothing leaves the building until it clears the gate. The MHA Project Checklist is that gate, and every proposal passes through it before delivery. It runs on a gated no-advance model. Items marked with an exclamation are gates, and you don't advance past a gate with open items unless you've got a documented reason and a plan to resolve it. No quiet skipping. Either the item's cleared, or the open item and its plan are written down.
The pre-quote gate confirms the things that cost you if they're wrong: the MTBH is complete, every vendor got full scope, the limitations are documented, the exceptions are called out, the flow diagram and the calculations are in the package, and the project folder is in order. That gate is one phase of the checklist. The phases that govern the job after award, execution and project close, are Part VIII work; here you run the pre-quote gate only.
Then the move that catches what you can't. Before the proposal goes out, hand the checklist to someone who had nothing to do with building it, and ask them to review it. You're too close to your own work to see the hole in it. A second set of eyes reads the checklist cold and finds the thing you've read past ten times. A gap you find at the gate costs nothing. A gap the customer finds after award costs margin, relationships, or both.
If a proposal is about to go out, then hand the pre-quote checklist to someone who had nothing to do with building it and ask them to review it. Tradeoff: you have to admit you might have missed something, and it costs another person a half hour. Verify: a second set of eyes on the checklist catches what you can't see because you're too close to the work. Every gap they find at the gate is a gap the customer doesn't find after award.
Time to assemble the Riverside proposal package for Dana, Tom, and Michael. You built every piece across the program. Now it becomes one document, in the six-part structure this lesson taught you.
Then run the pre-quote gate. Check the Phase 4 gate items, confirm the flow diagram, the MTBH, and the calculations are all in the package, and hand the whole thing to an independent reviewer before it leaves your desk. Save the package and the cleared checklist in the Riverside folder. That's the proposal package, the Part VII deliverable. Don't present it yet. Carrying it into the room with three buyers is Lesson 31.
This is the lesson the whole part points at. Part VII took a validated design and turned it into things other people can act on: a drawing the trades build from, a business case the money approves, and now a proposal a customer can decide on. The proposal is where every earlier skill arrives at once. The product analysis drove the design. The design set the layout. The layout built the BOM. The calculations set the limits. The safety review set what has to be disclosed. All of it lands in one package. Give the customer enough to make a real decision, limitations and all, run it past the gate and a second set of eyes, and you've answered the question on the gold banner. Then you carry it into the room.