A bill of materials tells your contract manufacturer what parts to buy. It says nothing about how those parts go together, what has to be printed on the enclosure before it ships, or how anyone on the line confirms a finished unit actually works.
That gap is where most first-production-run problems live, and a better BOM doesn't close it. It takes a different set of documents entirely, most of which nobody hands you a template for until your CM asks where they are.
Assembly Instructions Come in Two Flavors
The obvious answer is a stack of engineering drawings: break the product into subassemblies, break each subassembly down to its own components, and stop once you've decomposed everything down from the top-level assembly. That's a legitimate way to do it, and it's the default if your documentation lives entirely in CAD.
The better version, and the one worth the extra afternoon, is a walkthrough document that goes past what a drawing shows. Which tools are needed. How each part should be oriented. How the wiring should be routed. Written the way you'd actually do the build yourself if you were standing at the bench, not the way a drafting standard says a drawing should read.
Neither version is final the day you send it. Your CM will build to it, hit something you didn't anticipate, and hand you back a question or a correction. That feedback loop is the normal shape of the process, not a sign you got it wrong the first time.
The Label Is Where Certifications Actually Live
Labeling gets treated as an afterthought, and it shouldn't be. What has to physically appear on the product: model number, serial number, manufacturing date or lot code, and if the product needs a certification mark (FCC, CE, UL, whatever applies to where it ships), that mark goes on the label too. It isn't a compliance document that lives in a folder somewhere separate from manufacturing; it's part of what the CM prints and applies during the build. If the product ships direct to a customer, packaging carries its own labeling too: what's printed on the box, any warning marks, and how the unit is protected inside it, whether that's foam, an anti-static bag, or a desiccant pack for anything moisture-sensitive.
How Do You Know They Built It Right?
Testing procedure is the question a BOM never answers. Once a unit comes off the line, how does anyone confirm it works? For anything with a PCB, that usually means a bed-of-nails fixture to test the board electrically against known-good values, plus a way to actually load your firmware onto it during assembly. Building or specifying that tooling is mostly on you. A larger CM might already have some of the infrastructure; a smaller one won't. Either way, you're the one who has to define what "passes" means, because nobody downstream is going to guess it correctly on your behalf.
None of This Starts Without a Quantity and a Date
None of the documents above starts a build on their own. What actually starts one is a cover sheet: quantities (a 10-unit prototype run reads very differently to a CM than 5,000 units a quarter), a target ship date, and a single point of contact who can answer a question without a three-day round trip. This is the RFQ information a CM needs before they'll even price the job, and it's easy to treat as a one-off email instead of a document, right up until the quantity changes mid-quote and nobody remembers which number the price was actually based on.
You Don't Need All of This by Your First Order
Whether you need the full package before your first order depends on the shop. A large contract manufacturer will expect a complete handoff before they'll even quote it. A smaller one, especially one used to working with early-stage teams, will often flag what's missing and help you build it as you go, closer to consulting than a vendor relationship. You build this documentation the way you build most things at this stage: iteratively, informed by whatever the last build taught you that the drawings didn't cover.
The Handoff Isn't the Hard Part. Tracking It Is.
Once this material exists, it needs somewhere to live, and that somewhere should be the same system that holds your BOM and revision history, not a folder named "CM stuff" on someone's laptop. Every assembly walkthrough, every test procedure, every label spec you generate with a manufacturer belongs next to the parts it applies to. Give your CM access to that system directly instead of emailing them a file: in oroForge, adding a CM as a Viewer on the project means every download gets logged, so you know exactly which version they pulled and when, without a Slack thread to confirm it.
The harder problem shows up after the first build ships. Your CM substitutes a connector because the original went end-of-life, a scenario worth pricing into your BOM before it happens. They switch a fastener because their line already stocks a compatible one. If you're running turnkey, where the CM sources parts on your behalf, they can make these calls without looping you in first. What actually gets built is your mBOM, not your eBOM, and if you're not tracking substitutions against it, the file you think is current quietly stops matching the product shipping out the door.
You want to know who your vendors actually are, not just who you originally specified. And you want every substitution logged as a tracked change, not overwritten in place, so that six months from now you can answer why a unit built in March uses a different regulator than one built in June.
The Real Relationship
A contract manufacturer relationship is not a single handoff. It's a lot of material generated over time (drawings, walkthroughs, labels, test procedures, vendor records) and every revision that comes after the first one. The BOM starts the conversation. Everything after it, including the documentation your CM's feedback generates along the way, is what actually gets the product built, and built the same way twice. See pricing before your next handoff makes the gap expensive.
