You've built the proposal package. Now you have to present it, and the room you present it to isn't one buyer. The person who evaluates your engineering and the person who approves the budget are often not the same person, and sometimes they're sitting at the same table. You get one meeting to serve both.
At Riverside the room has three people. Dana wants to know the engineering is sound. Tom wants to know the investment is justified. Michael wants to know his one maintenance guy can keep it running. Same proposal, three different questions. The professional standard is to walk into that room and go as deep on the engineering or as high on the business case as it asks, without missing a beat.
By the end of this lesson you can read who's in the room and what each person is really evaluating, lead with outcomes and structure so the executive summary lands first, and go as deep on the engineering or as high on the business case as the room asks without missing a beat.
Start by naming the seats. Most rooms hold at least two kinds of buyer, and the good ones hold a third that most proposals forget.
With a technical buyer you go deeper. They want to see the layout, understand the equipment selection, review the calculations, and discuss the controls architecture, because they're evaluating one thing: whether the engineering is sound. They'll challenge the technology selection and the controls logic, and for them the MTBH table and the sorter matrix are credibility documents. You lead with the system design and you back it up with the math.
With a business buyer you lead with outcomes. Throughput improvement, labor reduction, error rate reduction, payback period. They're evaluating whether the investment is justified, and they'll challenge the ROI assumptions and the timeline. For them the executive summary and the limitations section are the decision documents, not the belt-speed math.
Then there's the third seat. The operations-and-maintenance buyer is the person who has to live with the system after the install crew drives away, and most proposals never speak to them. At Riverside that seat is Michael. He isn't weighing the elegance of the design or the payback math. He's evaluating whether the system can be maintained by the team he actually has, which is one technician.
The business case behind Tom's payback comes from Lesson 29, and the reliability and maintenance requirements Michael cares about come from Part VI. This lesson doesn't re-derive either one. It reads the buyers and matches the proposal to them.
Leading a business buyer with engineering. You open the meeting with the sorter model, the belt speeds, and the controls topology, because that's the work you're proudest of. The finance chair came to hear what it returns and when it pays back, and by the time you reach the payback you've already lost the room. Lead with outcomes. Earn the right to go deep.
Michael has watched two systems fail and come back out. When he asks how this one gets maintained, he isn't making conversation. He's deciding whether to trust you. Answer him the way you'd want to be answered if you were the one keeping it running at two in the morning with one technician: honestly, specifically, and without a sales word in it.
The VP of Operations asks what the system does for labor and throughput. In the same meeting, the Director of Engineering asks about the equipment selection and the controls architecture. You get to answer one first. Where do you start, and how do you make sure the other person knows their question is coming?
Structure every proposal the same way, no matter who's in the room: executive summary and business outcomes first, technical detail after. The executive summary is two paragraphs. What the system does, what problem it solves, what the customer gets. No model numbers, no jargon.
Then the system description follows for the technical buyer. Plain language, equipment by function, how the scan and sort logic works, how accumulation protects the system during peak. The limitations and the assumptions get their own labeled section where both buyer types can find them, not buried in paragraph four and not softened. The technical calculations live in the package, but they stay out of the narrative, so the business buyer doesn't have to read through belt-speed math to find the ROI.
The order isn't a formatting preference. A business buyer who stops reading after page two still walks away with the whole business case, and a technical buyer who wants the detail finds it exactly where they expect it. One document, structured once, serves both.
If you're structuring a proposal for a room you don't fully know yet, then put the executive summary and the business outcomes first, always, and push the technical calculations into the package behind the narrative. Tradeoff: the technical buyer has to turn a few pages to reach the depth they want. Verify: a business buyer who stops reading after page two still walks away with the whole business case, and a technical buyer finds the detail exactly where they expect it. One document, both buyers served.
The presentation is where the room challenges the work. Leading with outcomes gets you in the door; the backup knowledge is what keeps you there. When Dana challenges the sorter selection, you defend it from the product handling matrix. When Tom challenges the payback, you defend it from the confirmed inputs behind the business case. When Michael asks how his team maintains it, you give him an honest answer, not a reassurance.
That's the difference between presenting and defending. You know why the sorter is that model and not another, why the accumulation zones are sized the way they are, and what margin is built in. That backup knowledge is what lets you move up to the business case and back down to the calculations without losing the room. Presenting and defending isn't persuasion. It's communicating the engineering clearly and standing behind every decision in it.
Two things sit outside this room. Sales negotiation, the tactics beyond defending the engineering, isn't part of this program; the lesson defends the engineering, it doesn't teach how to close a deal. And what happens after the customer says yes, the Monday-morning handoff, belongs to Part VIII.
We usually go into more technical detail with a technical buyer, but the proposal and the drawings need to carry both the technical detail and the high-level summary. You need the backup knowledge to support either kind of buyer. You should be able to walk into any meeting and go as deep or as high as the room requires without missing a beat. The day you can do that, the room stops feeling like a test and starts feeling like a conversation.
You're presenting the Riverside proposal to Dana, Tom, and Michael, from the package you built in Lesson 30. Open the executive summary at Dana and Tom together, in outcomes: the misdirects stop, the staging bottleneck clears at peak, the manual sorting labor redeploys, and the case pencils against Tom's three-year threshold. Then go where each of them lives.
For Dana, go deep. Walk the system description, defend the sorter selection from the product handling matrix, explain the scan-to-divert logic at the confirmed one-second WMS latency, and show the controls architecture. For Tom, lead with the labor and chargeback savings and the payback, and be ready to defend every input behind them. For Michael, answer directly on maintenance, tied back to the two failures he described and the section of the proposal that addresses him by name.
Now prep the defense. Name the single hardest question each of the three will ask: Dana on the sorter model, Tom on the labor assumption, Michael on whether his one technician can service it. Write how you answer each, from the document, not from memory. Then prep the outlier decisions, the Small Case and the Tall Case, because Tom will ask why the system carries or excludes them. Keep it in your Riverside note as the presentation and defense plan. Don't run the Monday-morning handoff yet; that's Part VIII.
This is the last lesson in Part VII, and it's where the document you spent four lessons building finally meets the people it was built for. The drawing, the business case, the proposal package, all of it converges here: one set of documents that has to answer three different questions at three different depths. Get the structure right and you serve every seat from one package. Miss it and a sound design still loses to whoever explained theirs. Part VII communicates the design. Part VIII delivers it.