MATERIAL HANDLING ACADEMY

Part VII. Lesson 30. The Proposal.

DRIVING QUESTION Does this proposal give the customer enough to make a real decision?
PART VII | LESSON 30: THE PROPOSAL

Two Skills, Most Engineers Only Have One

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.

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.

PART VII | LESSON 30: THE PROPOSAL
DESIGN PRINCIPLE A proposal is an engineering communication, not a sales pitch.

Show the solution clearly. Document what it does well. Be honest about what it doesn't do. The executive summary leads the package, two paragraphs, outcomes only, so a business buyer who reads nothing else still leaves with the decision.

PART VII | LESSON 30: THE PROPOSAL

The Eight Deliverables

  1. System Layout. Flow, placement, dimensions, footprint.
  2. MTBH Table. The product analysis, outliers called out.
  3. Conveyor BOM. Equipment, quantities, models.
  4. System Limitations. Everything the system can't do.
  5. Assumptions and Exceptions. Every one, documented.
  6. Cost Drivers. Every parameter pushing cost above base.
  7. Calculations. The sizing outputs, saved and labeled.
  8. Maintenance Requirements. The eighth, and the one new engineers skip.
PART VII | LESSON 30: THE PROPOSAL
A vertical stack of nine labeled sheets forms the proposal package, executive summary on top, then the eight deliverables, with the System Limitations sheet pulled out and tabbed, noted own section, unsoftened. The package funnels down through a gold pre-quote gate drawn as a checklist with three exclamation-mark gate items, an independent reviewer at the gate, and an arrow past the gate to a customer figure.
Nothing reaches the customer until it clears the gate and a second set of eyes.
PART VII | LESSON 30: THE PROPOSAL

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."

Limitations live in their own labeled section, every limit listed, none softened. If a limitation isn't in the proposal, the customer assumes the system handles it.

PART VII | LESSON 30: THE PROPOSAL
COMMON MISTAKE

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.

PART VII | LESSON 30: THE PROPOSAL
FIELD INSIGHT | MICHAEL COLLINS

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.

Michael Collins
PART VII | LESSON 30: THE PROPOSAL

The Gate and the Second Set of Eyes

WHYExperienced engineers forget things under time pressure. The gate is the checklist that catches the missed scope item while it still costs nothing, and the independent reviewer catches what the author can't see.
WHENBefore any proposal leaves the building. Every proposal, no exceptions. On the gated no-advance model, open gate items get resolved or documented with a plan first.
WHEREThe last step before delivery. The completed checklist files in the project folder as evidence the standard was followed.
NOT WHENNot a self-review the day it's due. You're too close to your own proposal to see the gap. Hand the checklist to someone who wasn't in the build and let them find what you can't.
FAILURE IF IGNOREDThe proposal goes out with a missed scope item, the customer finds it after award, and now it's a change order or a dispute. The five minutes the checklist takes was worth more than the margin you just handed back.
PART VII | LESSON 30: THE PROPOSAL

Riverside

RIVERSIDE PROJECT

Assemble the proposal package for Dana, Tom, and Michael. Executive summary in outcomes for Dana and Tom. Plain-language system description for Dana. Every limitation stated as a number. Every assumption and exception documented with its reason. The with and without options for the Small Case and the Tall Case.

And the maintenance conversation addresses Michael by name. He has watched two systems fail. He deserves an honest answer. Then run the pre-quote gate and hand the checklist to an independent reviewer before it leaves your desk.

Next: Who is in the room, and how deep do they need me to go?