TLDR: Establish four things before anything else: which step the software actually performs, whether a qualified person is required to approve the output, which file formats it takes and returns, and what a trial on your own cases would have to show for you to proceed. Everything else follows from those.

Before the demo: work out what you are comparing

Vendors in this category describe different steps with the same vocabulary. One product proposes a design, another segments a scan, another arranges teeth. Get each vendor to state, in one sentence, which step of your existing workflow they replace and which they leave alone.

Write your own workflow down first, step by step, and hold the demo against it. Without that, every demo looks impressive, because a demo is constructed to look impressive on a case the vendor chose.

You should also know your own cost per design and where your cases actually wait before any of this. A lab that has measured both can evaluate a claim in a minute. A lab that has not is negotiating against the vendor's chosen baseline.

The twelve questions

What it does

1. Which step of the workflow does the software perform, and which steps remain manual?
2. What case types does it handle today, and which does it not? Complete dentures, partials, immediates, implant-supported full arch are genuinely different problems.
3. How long does the software step take on a typical case, measured on the case rather than on a slide?

Where the human sits

1. Does a qualified technician have to approve the output before it can go to production, or is approval optional?
2. How many stages require approval, and what exactly is being approved at each?
3. Can the technician adjust the proposal, or only accept and reject it? Accept-or-reject is a much weaker tool in real cases.

How it fits

1. Which file formats does it accept and return? STL, PLY and OBJ carry different information and your scanners determine what you have.
2. Does the clinic have to change anything about how it scans or submits?
3. What happens to a case the software cannot handle? A clear path to manual is a feature; silence here is a problem.

What it costs and what it proves

1. How is it priced: per case, per seat, per month, or a volume commitment? Match the shape to how your volume actually behaves.
2. What would a trial look like, on our cases, with our technicians judging the output?
3. Who else like us is using it, and may we speak to them without you on the call?

Question 4 is the one that sorts the category

Whether a qualified person must approve the output before production is not a preference. It determines the regulatory posture of the product, where liability sits, and what you can tell your referring offices. Get a direct answer and get it in writing.

A product where human approval is mandatory is a design aid operated by your technician. A product that can finalise output without anyone approving it is a different kind of thing, with different obligations attached, and buying the second while believing you bought the first is a meaningful mistake.

For context on one answer: in SmileShape, three of the five workflow stages require a trained technician to review and approve before a case advances. The technician approves the trim line, confirms the occlusal plane, and reviews, adjusts and approves the final design. SmartCAD does not design a denture independently of the technician, and it is not a diagnostic or treatment-planning tool.

How to run a trial that tells you something

Use your own cases, including the awkward ones, and have your own technicians judge the proposals without the vendor in the room. Decide the pass criteria before you start, in writing, or you will rationalise whatever happens.

1. Pick 20 to 30 real cases spanning your actual mix, not your cleanest scans. Include two or three you would describe as difficult.
2. Write down the pass criteria first. What share of proposals should be acceptable with minor adjustment? How much technician time per case is acceptable? Agree these before you see results.
3. Time it honestly. Measure total technician minutes per case including review and adjustment, not only the software step.
4. Have the technicians score the proposals blind where you can, and record what they changed and why.
5. Run the awkward cases last and look at them separately. How a tool handles the hard 10 percent predicts your experience better than the easy 90.

Red flags

• Accuracy or precision claims without a published study behind them. In this category those are performance claims, and a vendor making them casually has either done the work and can show you, or has not.
• Vagueness about whether a human must approve output. See above.
• A demo only on the vendor's cases. Reasonable for a first look, not for a decision.
• No clear path for cases the software cannot handle. Every tool has them.
• Reluctance to name reference customers, or insisting on being present for the call.
• Pricing that only works at a volume you do not have. Model it at your real volume, including a bad quarter.

Related reading

• what human review looks like in an AI-assisted denture workflow
• a vendor security checklist for dental labs buying software
• how to calculate your lab's real cost per denture design