The demo is the easy part

A good vendor demo proves that a prepared person can move prepared data through a prepared path.

Cool. Now show me the ugly order.

The split shipment. The customer with two identities. The promotion finance hates. The return that crosses tax periods. The integration that goes down exactly when volume spikes.

Enterprise selection gets into trouble when the demo becomes the evidence instead of the beginning of the questions.

Start with the exceptions

The standard workflow will probably work. That is why it is in the demo.

The useful questions live in the exceptions:

• What happens when inventory disagrees across locations?
• Can a service agent change an order after allocation?
• How are partial returns and exchanges handled?
• Can one brand use a different tax, payment, or fulfillment rule?
• What happens when the downstream system accepts a request but times out?
• Which promotions require custom logic?

These scenarios are not an attempt to make the vendor fail. They identify where the product ends and the implementation begins.

That boundary is where most of the cost will live.

Ask what made the demo possible

When a capability looks good, break down how it was delivered.

Was it standard behavior? Configuration? A partner extension? Custom code? A prototype? Something on the roadmap? Did the vendor team prepare data manually before the session? Does the workflow require another licensed product?

All of those answers can be acceptable. They are not economically equivalent.

“Yes” is not a complete architecture answer.

I also want to know who owns the capability after launch. If changing it requires a vendor ticket, a specialized developer, and a synchronized release across three systems, the demo should not describe it as business-user flexibility.

Use your data early

Sample data removes the exact conditions most likely to cause trouble: inconsistent identifiers, missing attributes, legacy values, duplicate customers, odd product relationships, and years of operational exceptions.

A focused proof using representative data is more useful than a broad demo using perfect data.

Do not import the entire enterprise to run a selection. Pick the data that exercises the hard parts. One complicated product family, one ugly customer scenario, one multi-step fulfillment path, and one real integration contract can reveal a lot.

The purpose is to learn where normalization, migration, or custom behavior will be required.

Evaluate the operating system around the product

Enterprise software is operated by an organization, not a feature matrix.

Look at deployment, environments, observability, incident support, access control, testing, upgrades, data repair, and the skills required to make routine changes. Ask how the platform behaves when several teams and vendors are working in it at once.

A product can have the right capabilities and still be a poor fit for the company’s ability to operate it.

That does not always mean choosing a simpler product. It may mean funding the operating model honestly.

Price the exit

Selection models tend to compare licensing and implementation. Add the likely exit cost.

Where will business logic live? Who owns the data model? Can content, customer, order, and product data be exported in useful forms? Are integrations based on portable contracts or proprietary implementation? How much of the experience layer survives a platform change?

No platform is permanent. Some just make that discovery more expensive.

Exit cost should not dominate the decision, but ignoring it gives lock-in a value of zero. That is rarely accurate.

Make the decision falsifiable

Write down why the platform is being selected and which assumptions matter most. Then test those assumptions during implementation.

If the expected configuration turns into custom code, the integration model cannot meet the latency requirement, or business ownership never materializes, leadership should see the decision change, not just the project status.

The demo should start the evaluation. When it ends the evaluation, everybody learns the same lesson later with a larger invoice.