Think back to the first part of this program. How important was the flow chart. A quote without one behind it is not a quote. It is an estimate with a BOM attached. Be sure to include the flow diagram in the project folder and the proposal package.
The Standard Behind the Checklist. Michael Collins, Sr. Solutions Engineer.
This guide defines the professional standards behind every item in the MHA Project Checklist. The checklist tells you what to do. This guide tells you why it matters and what happens when it is not done. Use this as a reference document. Come back to it when a checklist item raises a question. Read it in full before you deliver your first proposal. Read it again after your first difficult project conversation.
Companion to: MHA Project Checklist. Lesson 30: The Proposal.A quote is only as good as the engineering behind it. The engineering is only as good as the flow diagram. This is not a principle unique to this program. It is how every well-engineered conveyor system gets built.
The four-layer flow diagram is the document that makes the quote honest. Layer 1 tells you what the system needs to do. Layer 2 tells you what rate it needs to do it at. Layer 3 tells you where every smart decision is made and what it requires. Layer 4 tells you where people are, where the constraints are, and what the maintenance team will be living with for the next ten years.
A quote built from a complete four-layer flow diagram can be defended line by line. A quote built before the flow diagram is complete is a quote built on assumptions. Assumptions are not wrong until they are wrong. When they are wrong the cost comes out of margin.
Think back to the first part of this program. How important was the flow chart. A quote without one behind it is not a quote. It is an estimate with a BOM attached. Be sure to include the flow diagram in the project folder and the proposal package.
| Standard | Why It Matters |
|---|---|
| Layer 1 must be complete before any equipment is specified. | You cannot select a sorter before you know where the sort decision point is. You cannot specify a merge before you know how many flows are combining. The flow must precede the equipment. |
| Layer 1 must be complete before Layer 2 begins. | You cannot put rate numbers on a flow you have not drawn. Layer 2 is where belt speeds are calculated, not a prerequisite to calculating them. Rate follows flow. |
| Layer 2 must be complete before the controls scope is written. | Scan-to-divert distance, WCS response latency limits, and anti-gridlock thresholds all depend on confirmed belt speeds. If rates and speeds are not locked, the controls contractor is pricing against assumptions. |
| Layer 4 must be complete before the safety scope is priced. | Pull cord path, underside covers, forklift crossings, and LOTO access points are all Layer 4 items. Every one of them is a real cost. Price them from the diagram, not from memory. |
A proposal is an engineering communication. Its job is to give the customer enough accurate information to make a real decision. Not to make them feel confident. To make them informed. Every proposal produced in this program contains the following.
| Deliverable | What It Must Show | If Missing |
|---|---|---|
| System Layout | Conveyor flow, equipment placement, dimensions, operator access points, overall footprint. | Customer cannot evaluate fit, cost, or feasibility. Every conversation becomes abstract. |
| MTBH Table | Product analysis that drove the design. Dimensions, weights, types, outliers called out explicitly. | Customer cannot see what drove the design. Cost drivers are invisible. |
| Conveyor BOM | Equipment list with quantities, models, and descriptions the customer can understand. | Customer cannot verify what they are buying or compare to alternatives. |
| System Limitations | Speed, weight, throughput, and product size limits. Everything the system cannot do. | Customer assumes the system handles everything. Surprises after install. |
| Assumptions and Exceptions | Every design assumption and every exception taken to the customer spec, documented explicitly. | Undocumented assumptions become disputes. Undocumented exceptions are agreements you did not know you made. |
| Cost Drivers | Every parameter from the customer that is driving size, speed, or cost above the base case. | Customer does not know they are paying for something that may not be worth it to them. |
| Calculations | Supporting calculator outputs used to size the system, saved and labeled. | Work cannot be verified. Project folder is incomplete. Handoff is impossible. |
| Maintenance Requirements | What the system requires to maintain. What the team needs to know. Recommended intervals. | Maintenance team is unprepared. System underperforms in year two. |
These three items are where most proposals fail. Not because engineers do not know about them. Because engineers do not want to bring up problems. That instinct is understandable. It is also expensive.
A system limitation is anything the system cannot do. Maximum weight. Minimum carton size. Maximum throughput. Products the system cannot sort. Every system has them. Every proposal discloses them.
The reason is simple and it is not about legal protection. A customer who does not know about a limitation will assume the system handles it. When they find out it does not, the relationship suffers. Finding out during the proposal review is uncomfortable. Finding out after installation is significantly worse.
Anything that you feel is a limitation of the system should not be a surprise to the customer. Show them the good side, highlight the strengths of the solution, but include the limits. Weight, speed, throughput, product size. All of it. A customer who understands the system they are buying is a customer who stays your customer.
| Standard | Why It Matters |
|---|---|
| Limitations belong in their own section. | Not in paragraph four of the system description. Not in a footnote. In a labeled section where every reader sees them. |
| List every limit the system has. | Weight. Speed. Throughput. Product size boundaries. Product types the system cannot handle. If the system cannot handle it, say so. |
| Do not soften limitations with qualifications. | A limit is a limit. Do not write the system may have difficulty with packages over 30 pounds. Write the system maximum product weight is 28 pounds. |
An outlier is a product in the customer's mix that is significantly different from the rest of the mix in a way that forces the design to accommodate it. A very small product at low volume. A very tall product at moderate volume. An unusually heavy product. Any one of these can drive the entire system to be designed to handle it.
The standard is to show the customer what that product is doing to the design and what the system would look like without it. Give them the number. Let them decide.
Put a number on it. Show the customer what the system costs with and without that outlier. You can use a per foot price difference between conveyor widths as an early estimate if the design is not yet drawn both ways. The benefit of an early estimate is that it can prevent drawing the system twice. Give the information. Let them make the call.
| Include the Outlier | Exclude the Outlier |
|---|---|
| System is designed to handle all products the customer ships today. | System is optimized for the 96 percent or more that represents the core volume. |
| Customer does not have to manage exceptions manually. | System may be smaller, faster, or less expensive. |
| Future product changes within the outlier range are handled automatically. | Outlier products require a manual exception path. That path must be designed and documented. |
| Cost reflects the full product range. | Customer makes an informed business decision about the outlier. |
Every assumption made during design is documented. Every exception taken to the customer spec is documented. These are not bureaucratic requirements. They are how disputes are prevented.
A customer reads a proposal and assumes you followed their specification in full unless you tell them otherwise. An exception you did not document is an agreement you made without knowing it. When the system does not match what they expected, that undocumented exception is the root of the problem.
| Standard | Why It Matters |
|---|---|
| Document the assumption, not just the conclusion. | Do not write system sized for 20 CPM. Write customer confirmed 20 CPM peak throughput on call dated. That is a documented assumption. |
| Document every exception to the customer spec. | Read the customer spec line by line. For every line you did not follow exactly, note it explicitly. Silence means you agreed. |
| Explain why you took the exception. | Not to justify yourself. So the customer understands the trade. An unexplained exception creates distrust. An explained one creates a conversation. |
Margin is not lost when a project is priced. It is lost earlier, when information is missing during scoping and when vendors are given incomplete scope.
Margin gets lost with unsafe assumptions. Not knowing the product MTBH. Not giving vendors enough information, causing them to make bad assumptions. Your electrical installer, mechanical installer, and controls company are all pricing based on what you tell them. If you did not tell them about pull cord E-stops everywhere, or that every motor needs a VFD, they did not price it. That gap is your problem, not theirs.
| Where Margin Goes | Root Cause | Prevention |
|---|---|---|
| Incomplete MTBH at scoping | System is sized from assumptions about product. When real product data arrives, the system is wrong. | Complete the MTBH table and fill out the Product Spec Calc before any equipment is specified. |
| Pull cords not in vendor RFQ | Electrical contractor does not price them. Gap is discovered at final engineering or installation. | Pull cord runs are on the installation drawing. They are in the electrical RFQ explicitly. |
| VFDs not specified per motor | Controls contractor does not price them. Each motor without a VFD is a change order waiting. | Every motor requiring a VFD is specified on the BOM and in the controls RFQ. |
| Safety scope based on an unread or missing risk assessment | Guarding priced off the robot's type label instead of the application's risk assessment. Cost difference is significant. | The application's documented risk assessment (full guarding or a recognized collaborative technique) is confirmed before guarding scope is written, per ISO 10218. |
| Bearing covers left for field installation | Factory option missed. Field fabrication costs 5 to 10 times more. Schedule impact. | Bearing covers are on the conveyor purchase order as factory options. |
| Compressed vendor review schedule | Vendors make assumptions under time pressure. Assumptions cost money. | Vendor review time is protected in the project schedule. |
The person who evaluates your engineering and the person who approves the budget are often not the same person. A solutions engineer needs to communicate effectively with both from the same set of documents.
We typically go into more technical detail with a technical buyer, but proposals and drawings need to contain both technical detail and high-level summary. You need the backup knowledge to support either type 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.
| Technical Buyer | Business Buyer |
|---|---|
| Evaluating whether the engineering is sound. | Evaluating whether the investment is justified. |
| Wants to see the layout, equipment selection, and calculations. | Wants throughput improvement, labor impact, error reduction, payback. |
| Will challenge technology selection and controls logic. | Will challenge ROI assumptions and timeline. |
| Lead with the system design. Back it up with the math. | Lead with outcomes. Have the engineering depth ready when challenged. |
| The MTBH table and sorter matrix are credibility documents. | The executive summary and limitations section are decision documents. |
Structure every proposal so the executive summary and business outcomes come first. Technical detail follows. A business buyer who stops reading after page two still gets the business case. A technical buyer who wants the detail finds it where they expect it.
| Standard | Why It Matters |
|---|---|
| Executive summary is first. Always. | Two paragraphs. What the system does, what problem it solves, what the customer gets. No model numbers. No jargon. |
| 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 volume. |
| Limitations and assumptions are their own section. | Not buried. Not softened. Their own labeled section where both buyer types can find them. |
| Technical calculations are in the package but not in the narrative. | Include them. Do not make the business buyer read through belt speed calculations to find the ROI summary. |
The project folder is the engineering record of the project. It contains every document, calculation, communication, and decision that shaped the system. It is organized so another engineer can open it and understand the full history of the work without asking the engineer of record a single question.
That standard is not aspirational. It is the minimum. If the project folder cannot be handed off, it is not a project folder. It is a personal archive.
All notes, calculators, and items used to get this far on a project belong in a project folder for reference. It is hard to remember everything. If another engineer needs to take over, they should be able to reference your notes and calculations and understand where the design came from. Start the folder at the beginning of discovery. Not after the proposal. Not after award. At the beginning.
| Document | When It Goes In | Why It Is There |
|---|---|---|
| MHA layered flow diagram, all four layers | When each layer is completed | The flow diagram is the foundation. It is the primary document that explains the design intent. |
| Product Spec Calc | When product analysis is complete | Every input to the design is traceable. If a product changes, the impact is calculable. |
| All Calculator Outputs | As each tool is run | Work cannot be reconstructed from memory. Save as you go. |
| Customer Spec and RFQ | At discovery | Exceptions are flagged here. This is the record of what the customer originally asked for. |
| MHA Project Notes | Running log throughout the project | Decisions, assumptions, open items, and customer communications. The memory of the project. |
| All Vendor Quotes | When received | Scope gaps are flagged here. Vendor accountability starts with documented scope. |
| Change Orders | When approved | Every approved change with customer sign-off. This is the legal record of scope changes. |
| Final Proposal as Delivered | At proposal delivery | What the customer was shown. This is the baseline against which the as-built is compared. |
| As-Built Drawing | At project close | The legal record of what was built. It protects both the customer and the engineer on every future conversation. |
| Completed MHA Project Checklist | At project close | Evidence that the professional standard was followed from discovery through close. |
Everything in this guide comes down to one standard. A customer who understands the system they are buying is a customer who stays your customer. A customer who is surprised by limitations, gaps, or cost overruns after installation is a customer who calls someone else next time.
The engineers who build long careers in this industry are not necessarily the ones who design the most sophisticated systems. They are the ones who are honest about what a system does and does not do, who document their work so it can be handed off and built on, and who treat the proposal as an engineering communication rather than a sales pitch.
That standard is what the MHA Project Checklist enforces and what this guide explains. Follow it on every project. Without exception.
The quoting checklist exists because there are things that experienced engineers forget under time pressure. Use it every time without exception. The margin you protect by catching a missed scope item before the proposal goes out is worth far more than the five minutes the checklist takes.