Every demo looks good. Make it pass your test.

You already know the binder isn't holding. Maybe it's a spreadsheet that only works on the days everyone remembers to fill it in. So you've started looking at software, and every demo you've sat through has looked good.

Of course it did. A vendor's demo runs the path the software handles best, on sample data built to look clean. You don't see your own lot numbers in it, and you don't see the person on your team who'll be typing at the end of a long shift.

So bring your own test. This is the one I'd run.

01. Bring your own lot

The first question on a recall call is some version of: which finished product used this lot? You want that answer without digging.

Don't let the vendor pick the example. Pick one yourself:

• Choose an ingredient that goes into a lot of your batches.
• Make sure that ingredient is actually recorded on those batches in the trial.
• Go to the purchase record for that ingredient lot and trace it forward.

If getting the answer means requesting a report or calling support, you've just previewed your next recall.

02. Ask it what your team missed

Records rarely fail because someone wrote down the wrong number. They fail because a check never got logged, and nobody noticed until the end of the shift. Or the inspection.

The need is plain: show me what's open, what's pending, and what my team missed, without me having to ask. So ask for exactly that. Have the vendor show you a check that was due today and didn't get logged, then ask where that gap shows up and who sees it.

The weak version shows you everything that was logged and leaves you to spot what's missing, or to remember to run a report. A list of what got done tells you nothing about what didn't.

With one employee you could watch everything. With two shifts, you can't, and that's when this test starts to matter.

03. Make it produce what an auditor would see

Ask for a sample export, and ask the vendor to walk you through how it gets produced.

You're checking whether you could read that export without the vendor in the room, and whether you could produce it yourself on the day, with an inspector waiting. The standard is records clean enough that an auditor could walk in today and you'd feel fine.

For what inspectors tend to look at, see When a food safety inspector walks in.

04. Hand it to the person who'll do the data entry

This test decides whether you're still using the software in six months.

Software that technically works can still fail you. The bigger risk is a team that never adopts it, leaving you paying for a system nobody trusts.

During the trial, don't run the demo yourself. Find the person who'll be required to enter the data and have them create a batch. Watch where they slow down and where they get stuck.

Count the clicks, too. If doing anything takes a long string of them, treat that as a red flag. Every extra step is another reason to jot it on scrap paper and enter it later, which is how records drift from what happened on the floor.

05. Ask how long until you're running real batches

The big MRP and ERP systems are capable. They also tend to come with onboarding measured in days and weeks, workflows that assume specialists working in the business, and pricing built for companies much bigger than yours.

If the onboarding plan assumes a person you don't have, believe it. I wrote more about that gap in You were never too small for real tools.

The test, on one card

Run all five before you sign anything. A tool that passes them on your own data has earned a closer look. One that only passes the vendor's demo hasn't.