What a Production Scheduling Demo Should Actually Show You

You sit through a 45-minute demo. The sales engineer loads a dataset with 3 machines, 10 orders, and zero surprises. Everything sequences perfectly. The Gantt chart is beautiful. Colors line up. No conflicts. The phrase "as you can see" gets used eleven times.

Then you go back to your floor where 15 machines are running 200 jobs, the lathe operator called in sick, a material shipment is three days late, and the planner is on the phone trying to figure out which customer to disappoint first.

The demo showed you a toy. You needed to see a tool.

Here is what to actually demand.

Why Most Demos Are Useless

Every scheduling vendor builds their demo around the same playbook: clean data, simple constraints, no disruptions. The schedule generates in two seconds. The audience is impressed.

This tells you nothing about whether the software will survive your floor.

Your floor has machines with different capabilities that overlap in weird ways. Operators who can run some machines but not others. Changeovers that depend on the previous job, not just the next one. Materials that arrive late. Customers who call at 3pm and need their order moved up.

If the demo does not include your kind of mess, it is a slideshow.

The vendors who understand this will offer to load your data. The ones who do not will talk about "Phase 2 customization." Pay attention to which category yours falls into.

Seven Things to Demand in Every Demo

These are not nice-to-haves. If the software cannot do these live, it cannot do them on your floor.

1. Show me a reschedule when a machine goes down mid-shift

Kill a machine during the demo. Not at a convenient break point. Mid-run, with jobs queued behind it. Watch what happens. Does the schedule update automatically? Do jobs move to alternative machines based on actual capability? Or does someone need to manually drag things around for twenty minutes?

This is the single most important test. Disruptions are the norm, not the exception, and your planner already spends their week reacting to them. If the software cannot handle this in real time, it is just a prettier spreadsheet.

2. Show me how labor constraints affect the schedule

Most scheduling software treats machines as the only constraint. Your floor does not work that way. You have operators with certifications, shift preferences, cross-training gaps, and the one guy who is the only person who can run the 5-axis.

Ask the vendor to add a labor constraint: this machine can only run when Operator A is on shift. Now reschedule. If the software ignores labor entirely or treats it as a manual override, you will be doing the same workarounds you do today.

3. Show me changeover optimization on real sequences

Not the vendor's curated demo sequences. Your sequences. Bring a week of actual job data: materials, tooling, color changes, whatever drives your changeovers. Ask them to sequence it and compare the changeover time to what your planner produced.

If the software cannot import your data format or needs "a few weeks to configure," that is useful information. It tells you what the first three months look like.

4. Show me what happens when a material is three days late

This is the second most common disruption after machine downtime, and most scheduling tools handle it badly. The material is late. Jobs that depend on it need to shift. Jobs that do not depend on it should backfill the gap.

Watch whether the software does this automatically or requires the planner to manually identify every affected job and reschedule them one by one.

5. Show me the schedule on a phone

Floor supervisors do not carry laptops. If the schedule is only accessible from a desktop browser, it is only accessible to the planner. The floor will keep using the whiteboard.

Open the schedule on a phone during the demo. Can the supervisor see their work center? Can they mark a job complete? Can they flag a delay? If the mobile experience is "we have a responsive website," it is not a mobile experience.

6. Show me how long setup takes with my data

Not the demo dataset. Your data. How long does it take to import your machines, your jobs, your constraints, your operator certifications? Is it hours or weeks?

The answer tells you whether this is a tool you will be using in 30 days or a consulting engagement you will be managing for 6 months.

7. Show me what the planner does on day two

Day one is always impressive. The schedule generates, the board looks clean, everyone sees value. Day two is when the planner has to update the schedule based on what actually happened yesterday.

What does that workflow look like? How long does it take? Is it five minutes of confirming actuals, or is it an hour of manual data entry to keep the system current?

The daily workflow matters more than the initial generation. Ask to see it.

Red Flags That Mean Walk Away

Not every bad fit is obvious during a demo. These are the patterns that predict problems at month three:

• "We will customize that for you" — said in response to a basic constraint type your industry uses daily. If color-to-color changeovers or multi-resource constraints require custom development, the product is not ready for your shop.
• No live rescheduling — the demo only shows initial schedule generation, never a disruption response. This means rescheduling is either slow, manual, or broken.
• Cannot handle your constraint types — if you tell them your machines share tooling and they look confused, move on.
• Pricing requires a call — this usually means the price is high enough that they need to qualify you first, or it varies based on how much they think you will pay. Either way, it is a red flag for a small shop.
• 12-month contract, no pilot option — any vendor confident in their product will offer a 30 to 90 day pilot. If they need a year-long commitment before you see results, they know the first 90 days are rough.
• The demo never shows bad data — your ERP data has gaps. Your job records have inconsistencies. If the demo only works with perfect inputs, it will not survive your inputs.

Questions the Vendor Will Not Volunteer Answers To

Ask these directly. The responses tell you more than the demo does.

What is your median implementation time for shops our size? Not the best case. The median. If they say "it depends," push for a number. Shops under 50 people should be live in under 30 days for a focused pilot.

What is your failure rate? Every vendor has customers who churned. If they claim 100 percent success, they are either lying or too new to have data. Ask what went wrong in the cases that did not work out.

Can we talk to a customer who churned? This is the nuclear question. A vendor who can connect you with a churned customer and explain what happened has nothing to hide. A vendor who refuses has something to hide.

What happens to my data if I cancel? Can you export everything? In what format? Is there a data retention period? You need to know you can leave without losing your scheduling history.

What does your product actually do versus what an ERP or spreadsheet does? This is not a trick question. It is a clarity test. The best vendors can explain their value in two sentences without using the word "solution."

How to Structure a Pilot

Do not roll out to the whole floor. Pick your messiest work center: the one with the most changeovers, the most disruptions, the most overtime.

Run the pilot for 30 days. Keep the spreadsheet running in parallel so you have a baseline.

Measure three things:

1. Planner time — hours per week spent on scheduling mechanics for that work center, before and after
2. Changeover time — total changeover hours per week, before and after
3. On-time delivery — OTD percentage for jobs through that work center, before and after

If the software shows measurable improvement on all three within 30 days, expand. If it does not, you learned that for the cost of a one-month pilot instead of a 12-month contract.

The goal is not to find the perfect software. It is to find a tool that handles your real constraints, not the ones in the demo.