Tom Hadley
Content Writer
Somewhere in your business, there's a person who knows the truth. Not the Helm stock count, the real one. The one in their head, or on a whiteboard by the packing bench, or in a spreadsheet nobody else has the link to. They know it because every time you build something, whether that's bottling a batch, kitting a gift set or packing a subscription box, that build happens outside Helm, and somebody has to translate it back afterward.
That translation step exists because there's no bill of materials anywhere in the system to plan or track the build against. That's not a flaw in Helm WMS specifically. It's a gap in every warehouse management system, because a WMS is built to move stock that already exists in its finished form. It assumes what you're picking is what you're selling. The moment you turn raw stock into something new, you fall through that gap, and you're left choosing between running a second system, cobbling together a spreadsheet, or trusting whoever's memory is best that week.
Depending on your setup, that gap gets patched three ways. There's a spreadsheet next to Helm WMS, updated by hand after every batch, so the finished-stock figure is always slightly out of date. There's a dedicated production tool, bought specifically for the manufacturing side. It does that job properly, but it lives entirely outside Helm, with its own login, its own sync, and its own chance to disagree with what Helm shows. Or there's a basic kitting feature bolted onto a WMS. It builds a kit at the moment you pack an order, one level deep, with no real recipe, no batch or expiry tracking, and nothing that plans ahead. All three work, up to a point. None of them make Helm WMS the place where the truth actually lives.
Assembly closes the gap properly. It’s Helm WMS’s built-in bill of materials and light manufacturing feature, opening as a tab inside Helm itself rather than a separate login: a proper recipe for each product, with builds that plan, run and complete without ever leaving Helm WMS, so your stock and your build activity finally move together instead of you reconciling them by hand afterward.
Why This Matters More Than It Sounds
What this actually solves depends on what you make:
If you're a… | The problem you're carrying | What Assembly gives you |
|---|---|---|
Food or drink producer | Expiry and FEFO tracked by hand, hard to prove at audit | Expiry inherits from component to finished good automatically |
Subscription-box packer | A shortfall discovered on pack day, after boxes are promised | A build planner showing days of cover ahead of time |
Kit or multipack assembler | No clean way to build from stock you've already finished | Finished goods can be components in another build's bill of materials |
Light manufacturer generally | Recipes and builds living in a spreadsheet or someone's head | A versioned bill of materials with automatic write-back to Helm |
If you produce food or drink, this isn’t a nice-to-have. Getting expiry or FEFO (first-expired-first-out) consumption wrong isn’t a stock discrepancy, it’s a recall risk, and "we think it’s fine" is not what you want to be telling an auditor. Assembly inherits expiry from component to finished good automatically, so the traceability already exists before anyone asks for it, rather than getting reconstructed afterward from whatever paperwork survived.
If you’re packing to a deadline, subscription boxes, kit orders, anything with a ship date attached, the moment that actually hurts isn’t "our stock count was wrong." It’s finding that out at two in the afternoon on pack day, after you’ve already promised a box to 5,000 subscribers and you’re one component short. Assembly’s build planner works from your real sale velocity, so you can see what’s about to run low and how many days of cover you have left, while it’s still next week’s purchase order rather than today’s emergency.
And if you’re assembling or kitting more generally, picture a drinks producer running two production lines, one bottling, one canning, building both single units and gift multipacks from the same base stock, where a case of finished bottles becomes, in turn, one line on a multipack’s own bill of materials. Every one of those builds needs its own recipe, its own components, its own count, and right now that’s either living in Helm badly, or living next to Helm separately. Assembly is what puts it properly in one place.
What a Bill of Materials Actually Changes
Once Assembly’s switched on, here’s what’s actually different day to day:
A bill of materials for each product, versioned. You can see what a recipe used to be, not just what it is now.
Components staged before a build can even start. Helm WMS physically moves the right components into a dedicated build location first; the build can’t begin until that’s done.
Builds that write back automatically. They consume components and produce finished goods, sending every quantity into Helm WMS inventory, usually within seconds. No export, no re-entry.
A planner working from real sale data. Not a hunch, and not a monthly stocktake.
An immutable, per-company audit trail. It records itself, and pairs with printable build reports for whoever needs proof it happened.
Bulk CSV import and export. For products, components and BOMs, so setting this up doesn’t mean rebuilding your catalog from scratch.
Why It Lives in Helm, Not Beside It
None of this is a new idea. Production planning, batch tracking and bills of materials all exist as standalone software already, and do the job properly. What they don’t do is live where your stock does. Buy one of those and you’ve solved the manufacturing problem by creating a reconciliation problem: two systems, two logins, and two versions of your stock that need to agree with each other every single day.
Assembly skips that trade entirely. Your build activity and your stock levels are the same numbers, seen from the same place, so the person who used to carry the real count in their head can finally stop doing that. And on the rare day something doesn’t quite line up, Assembly checks itself against Helm daily and flags any drift for a person to look at, rather than quietly overwriting either side. Because it’s part of Helm WMS rather than a separate purchase, there’s no second subscription to justify: install it and it’s already covered by what you pay for Helm WMS.
Make it. Track it. Sell it. All inside Helm WMS.
A Few Questions Before You Start
What Is Assembly in Helm WMS?
Assembly is Helm WMS’s built-in production planning and build execution feature. It gives you a bill of materials for each product, tells you what to build and when based on real sales demand, and writes every finished build straight back to Helm stock, usually within seconds.
Is Assembly a Paid Add-On?
No. It's free to install for any Helm WMS customer.
Can a Finished Good Be Used as a Component in Another Build?
Yes. That’s how a multipack works: the single units are finished goods in their own right, and also components in the multipack’s bill of materials.
Do I Need to Migrate Everything at Once?
No. Bulk CSV import and export is there for when you want it, but there’s nothing stopping you bringing products in gradually as you set builds up.
Getting Started
Assembly is free to install from the Helm WMS app store. If you’re already running Helm WMS and any of this sounded familiar, there’s nothing stopping you turning it on and setting up your first bill of materials today.
If you’re not on Helm yet and you’re currently patching a WMS to a separate assembly process, this is a fair problem to bring to us. Book a demo here.
