How to choose steel stockholding software: the questions worth asking before you sign

Most stockholders buy a system twice in a working lifetime. You do it once, live with it for fifteen years, then do it again when the person who understood it retires. That is a hard thing to get good at, and the people selling to you do it every week.

So the demo is not a fair fight. It runs on their data, with their favourite screens, on material that behaves. Below are the questions that separate a steel-native system from a general one.

I build MetlSys, so I have an obvious interest here. I have tried to write the checklist I would want from your side of the table, including the bits where the honest answer is uncomfortable.

Ask them to start from a batch, not a stock code

Nearly every gap in this trade traces back to one design decision: what the system thinks the unit of stock is.

A general inventory system thinks in part numbers and quantities. Ten of item X. A steel system has to think in batches: a physical lot with a heat number, a certificate, a theoretical weight, an actual weight, a cost and a location. Ten tonnes of 304 plate is not ten of anything. It is a set of specific pieces from specific casts, each with its own paperwork.

You can tell within ten minutes which one you are looking at. Ask them to show you a stock line and then drill into the individual physical lots behind it. If the answer involves a custom field, a lot-tracking module or a consultant, the system started somewhere else and is trying to catch up.

The five demo questions that find the gaps

Ask these in the demo, in this order, on their system. Do not accept a slide.

1. Show me an offcut and walk it back to its certificate. Take a bar, cut it, cut a piece off the remnant, then send that piece out for machining and bring it back. Now find the mill certificate for what came home. Every step in that chain is normal in a stockholder and every step is where a general system quietly drops the thread. In MetlSys, splits, cuts, remnants and subcontract returns all keep the genealogy, because a cut produces a child of the same cast rather than a new product.

2. Which weight does it invoice on, and who decides? There are two weights on every batch, the theoretical one worked out from the section and the actual one off the scales, and they never agree. A system that holds a single quantity per line has already lost. Ask whether the invoice can be raised on either basis, whether that can vary by customer and grade, and what happens when the variance is large. MetlSys carries both weights, prices per kg, per metre, per each or as a lump sum, invoices on either basis, and flags a variance over 2% for review.

3. Can it stop a despatch? Your customer requires 3.1 minimum. The batch on the forks only ever had a 2.2. Ask them to try to despatch it. A warning that a busy person can click past is not a control. In MetlSys, certificate types are ranked 2.1 to 3.2, each customer can carry a minimum acceptable type, and allocation and despatch gate on it.

4. Price me a cut length. Not length times a rate. Cut length plus the kerf plus a facing allowance at each end, with the kerf depending on which saw does the job. If that arithmetic lives in a spreadsheet next to the quoting screen, you have bought half a system. MetlSys does the saw maths where the order is priced.

5. What happens to stock we have booked in but not weighed? A delivery arrives with a theoretical weight on the note. The actual weight comes later. Everything sold in that window is guesswork. Ask what the system does in the gap. In MetlSys, goods-in supports a two-stage receipt: material books in from the delivery note and sits as awaiting-weight and unsellable until the actual weight is confirmed. At despatch the scales record gross, tare and net against the load.

Then ask the questions that have nothing to do with features

Features are the easy part of this decision. The expensive part is everything around them.

What happens to thirty years of history? This is the real reason stockholders stay on software they have outgrown, and it deserves a proper answer rather than reassurance. Ask for the stages. A serious migration is analysis first, then a field-by-field mapping you sign off, then a trial run into a test company, then parallel running, then a planned cutover with the old data preserved. Ask specifically whether certificate PDFs get re-linked to batches by heat number, or whether they arrive as a folder of files. If somebody quotes you a migration timeline before looking at your data, they are guessing. Our migration process sets out the five stages and what moves at each one.

How is it priced, and what happens when the yard logs in? Per-user pricing sounds fair until the warehouse needs accounts. Then a firm shares one login to save money and loses the audit trail it was paying for. Ask what an operator login costs, and ask what a read-only login costs. MetlSys prices on named full users only, Lite at £395 a month for one to five, Professional at £995 for six to twenty, Corporate on request above that, all excluding VAT. Warehouse, shop-floor, read-only and driver logins are unlimited and included on every tier. Implementation, migration and bespoke integrations are scoped separately, which is normal and should be said out loud rather than discovered later.

Where does the data live, and can we get it out? Ask for the region, not the brand name. Ask what happens on exit. MetlSys runs its primary database as managed Postgres in London, with certificates and document bundles in private storage reached through short-lived signed links, and structured exports provided if you leave.

Who answers when it breaks? There is a real difference between a support desk and the person who wrote the code. Both are legitimate. Just know which you are buying, and know the hours. Ours is email during UK business hours on a best-efforts basis, and the developer behind the product rather than a call centre.

What does it not do? This is the most useful question in the whole list, and the answer tells you more about the supplier than any feature. Ours: there is no standalone uptime SLA at this stage, point-in-time database recovery is not enabled yet, and the accounting link to Xero, Sage and QuickBooks is a clean auditable CSV export rather than a live two-way sync. A supplier who cannot name a single limitation is either not listening or not telling you.

Run the demo on your own worst paperwork

The most useful thing you can do costs nothing. Take your scruffiest mill certificate, a real customer purchase order and one genuinely awkward order from last month, the one with three cut lengths, a subcontract leg and a part delivery. Send them over before the demo and ask to see those.

Clean data hides everything. Your data is the test.

A short scorecard

If you want something to score two or three systems against, this is enough:

Nine out of ten of those are about whether the system was built for steel or adapted to it. That is the whole decision. Everything else is preference.

If you want to run that list against MetlSys with your own paperwork, request a demo and bring the worst PDF you own.