A prepared demo shows how a system can work. An acceptance scenario shows whether it can work for you. The difference is the test case you bring to the meeting.
Send a small, concrete brief
Use anonymized sample data and describe one complete journey. For a trading business, that might be a quotation, an order with a discount, two deliveries, two invoices and a final payment. State the expected remaining quantities and balances after every step.
Avoid sending an enormous feature spreadsheet as the only brief. A few connected scenarios reveal cross-module behaviour more clearly than dozens of disconnected checkboxes.
Add the uncomfortable cases
- Amend a transaction after it has entered an approval route.
- Receive fewer units than ordered.
- Try an action with a user who should not have permission.
- Find the source document behind a report total.
- Export a result and verify that the values and labels remain usable.
Use cases relevant to your business rather than trying to catch the presenter out. The aim is to discover configuration decisions and scope gaps early.
Record the answer precisely
For each case, capture the result, the configuration used and any unresolved issue. Distinguish “works now” from “can be configured” and “requires development.” Assign a responsible person and a completion condition to each gap.
Ask to repeat an important case with a second user role. A workflow that works for an administrator may behave differently for the team who will operate it daily.
Make the decision reproducible
Keep a short evidence pack with screenshots or recordings where permitted, the sample inputs and the agreed output. Use it again during implementation acceptance. This connects the sales promise to the delivered configuration.
For DNA, start with Sales & CRM, Purchase & Procurement and System Setup. Bring the same brief to every vendor so your comparison remains fair and useful.
