A Perfect Demo Is a Warning Sign
What vendor demonstrations don't show — and the questions that expose what they are hiding.
There is a particular feeling in a vendor demo room. The screens are clean. The data is curated. The presenter knows exactly which buttons to press and in which order. Every transition is smooth, every result appears instantly, and every capability the client mentioned in discovery happens to be demonstrated with apparent ease. It feels reassuring. It is meant to. What is being shown is not the system. It is the system's best possible day — configured specifically for this audience, populated with data that has never been migrated, integrated with nothing, and operated by someone who has run this exact demonstration dozens of times. The distance between what you see in that room and what you will experience eighteen months after go-live is, in most cases, considerable. A perfect demo is not proof of capability. It is proof that the vendor knows how to run a demo.
The right question after a demo is not "Can it do this?" — it is "What does it take to keep this working?"
What demos are designed to show
Vendor demonstrations are sales instruments. That is not a criticism — it is a structural fact that should inform how you watch them. Every choice about what to include, in which order, at what pace, and with which data, has been made to maximise favourable impression and minimise uncomfortable questions.
Demos show happy paths. The user enters valid data, the system responds correctly, the output appears as expected. This is the scenario that works. It is not the scenario your finance team will encounter on the Tuesday after go-live when someone enters a purchase order with a cost centre that does not exist in the new chart of accounts. Demos show best-case performance. In a demo environment with a handful of demo records and no concurrent users, the system responds quickly. In a production environment processing thousands of transactions simultaneously, pulling from a data set that was migrated under time pressure, the experience is different. Response times matter. They are never demonstrated honestly.
Demos show isolated functionality. The accounts payable module works beautifully in isolation. What demos rarely show is how it behaves when the procurement module sends it an unexpected transaction type, when the integration with the legacy treasury system produces a duplicate posting, or when a batch job runs overnight and leaves the reconciliation in an inconsistent state.
