Senthil Info

automating business processes, honestly

Against the Demo

The demo is the centre of most automation purchases. It is also, structurally, the least informative thing in the process, and the reason is not that anybody is being deceptive.

What a demo necessarily is

Curated input. The clean invoice, the standard supplier, the well-formed record. Showing a malformed input would demonstrate nothing about the product. For a product-side reference related to workforce operations, Monitask also covers how employees can tell if they are being monitored.

No exceptions. The single figure that determines the outcome is absent by construction, because a demo of exception routing is a demo of manual work. For broader background and an independent point of comparison, see Salesforce Flow.

No month three. No system update, no new format, no staff change, no maintenance.

And no integration friction. The connection to the source system either exists in the demo environment or is waved past as configuration.

Each of those is the right choice for a demonstration. Together they produce a picture of the process at its most automatable, which is precisely the presentation that makes a poor candidate indistinguishable from a good one.

What the demo does to expectations

This is the part that costs money.

Gartner's account of failed projects names misaligned expectations as the dominant cause — leadership assuming the technology would immediately handle complex tasks. Those expectations came from somewhere, and the demo is where.

A sponsor who has watched a clean run believes the clean run is the job. The exception rate, the residual work, the maintenance and the ramp are all absent from what they saw, so when they appear later they read as underperformance rather than as the normal shape of the thing.

The technology is rarely the problem, and the demo is one of the mechanisms by which that becomes hard to see.

What to ask for instead

Run it on our data. Not a sample we selected — a hundred consecutive real instances including whatever arrives. A vendor who agrees to this is showing you something; one who declines has answered a different question.

Show me the exception path. What happens when the input is wrong, the system is down, the field is missing. This is the part you will live with.

Show me a change. Add a rule, in front of us, and tell us who does that in production and how long it takes. It is the difference between an asset and a purchase order per change.

And show me the monitoring. How do we know it stopped?

None of that is hostile, and a good supplier will have most of it ready because they have been asked before.

The comparison worth making

A hundred real instances beats any demonstration.

If you have mapped the process and tallied the exceptions, you can hand a vendor a genuine sample and a genuine exception list and ask what happens to each. That conversation is technical, specific, and it discriminates between suppliers in a way a scripted demo cannot.

It also reveals something about how they respond to a difficult case, which is the property you will actually rely on.

The internal version of the problem

Worth naming, because it is not only vendors.

An internal pilot has the same structure as a demo when it is run on the cleanest process with the best people and quiet manual handling of exceptions. It succeeds and proves nothing, and it carries more authority than a vendor demo because it happened in your building.

The defence is the same: representative process, logged exceptions, long enough to hit a change, and a written failure condition.

The short version