What to demand in a demonstration before buying an autonomous procurement platform

Bring your own workflow

A vendor demonstration built on a vendor scenario shows what the software does well. Bringing one of your own workflows — ideally the one that frustrates the team most — changes what you learn.

It does not need to be complicated. A plant request that currently takes three weeks tells you more than a carefully chosen showcase.

Six requests worth making

Each of these is specific enough that it either happens or it does not.

• Show the workflow end to end, from trigger to the record system update and the audit history.
• Show an action being blocked at a threshold, and the rule that blocked it.
• Show an escalation reaching a named approver, with the reason attached.
• Show an authorised person overriding an automated action, and the record it leaves.
• Retrieve the complete action history for one transaction.
• Show the same workflow behaving differently in two entities with different thresholds.

Watch what the software does after it produces an answer

This single observation separates execution from assistance. If a person then has to open a system and take the action, the platform is helping rather than executing.

It is worth asking explicitly: which of these steps did the software perform, and which did a person perform off-screen?

Ask what is not yet possible

A vendor willing to state clearly what a product does not do, and where a claim requires customer validation, is generally more reliable about the rest.

Be sceptical of quantified outcome claims presented without a stated measurement basis, and of integration lists offered without confirmation of which objects are actually supported.

Involve security and audit early

If the platform will execute work, security and internal audit will eventually assess it. Involving them in the demonstration rather than at contract stage tends to shorten the process considerably.

The six requests above are also the ones those functions would have asked, which makes the conversation easier for everybody.

Why vendor demonstrations mislead

A standard vendor demonstration is a rehearsed sequence on prepared data, designed to show the software succeeding. That is not dishonest — it is the natural product of preparation — but it systematically hides the thing you need to know, which is what happens when reality varies.

The correction is simple and it changes everything: run the session on your own workflow, including the part that usually goes wrong. Any vendor unwilling to do this has told you something useful.

The seven things to insist on seeing

Each of these takes minutes and each is difficult to stage.

• An ambiguous request the system cannot classify confidently, and what it does about it.
• A required field missing, and confirmation the request cannot progress.
• The stored reference for the rule that selected the buying route.
• An action blocked at a threshold, and what the approver then receives.
• An attempt to bypass a checkpoint, and the refusal.
• What the system did overnight, unattended, with the record.
• A deliberate write-back failure, and who is told.

Questions that reveal more than the demonstration

Three questions consistently produce more information than an hour of screens, largely because they are difficult to answer well without genuine experience.

Ask what they would advise you not to do in the first phase. A vendor with no answer has not implemented enough to have learned anything. Ask which of your categories they would advise against running as an auction. Ask what the product does not yet do — the answer, and the willingness to give one, both matter.

Who should be in the room

The composition of the session predicts the outcome of the evaluation more reliably than the software does.

• A buyer who runs the workflow daily and will notice what a slide hides.
• The process owner who can settle a policy question without convening a committee.
• Someone from security, early enough that the permission model is reviewed rather than objected to later.
• A plant representative who will say plainly what will not work at site level.