1–2. Process fit and exception handling
Map the few end-to-end processes that control revenue, cost, service or risk. Demonstrations should use the organization's own scenarios, terminology and roles. A polished standard flow says little about the difficult day when stock is short, an approval is missing or a customer exception must be resolved.
Ask the supplier to show how the system records, routes and closes exceptions. If the answer relies on messages, spreadsheets or undocumented manual intervention, that work remains part of the future operating cost.
3–4. Roles, permissions and data ownership
Permissions should express responsibility, not only hide menus. Test who may create, approve, reverse, export and view sensitive records; include temporary roles, branches and external partners where relevant.
For every critical field, decide which system is the source of truth, who can change it and how history is retained. Confirm export formats, migration rights and what happens to data at the end of the commercial relationship.
- Role and approval matrix
- Audit history and reversible actions
- Data export and portability
- Retention and deletion responsibilities
5–6. Integration and security responsibility
Do not accept 'it has an API' as an integration plan. Confirm the actual operations, authentication method, limits, event behavior, error recovery, environments and licenses. Define which party monitors failures and who reconciles incomplete transactions.
Security evaluation should assign responsibility for identity, authorization, encryption, logging, backups, vulnerability response and access reviews. Certifications can support evidence, but they do not replace architecture and operating controls specific to your use case.
7–8. Usability and implementation method
Usability is whether each role can complete real work with understandable feedback and reasonable effort. Test common and high-risk journeys with representative users before broad rollout.
The implementation plan should name discovery outputs, migration rehearsals, acceptance criteria, training responsibilities, support process and decision owners. Prefer phased releases that create complete usable workflows over a long sequence of unfinished modules.
9–10. Vendor continuity and total ownership
Understand who owns product decisions, configuration, custom code, documentation and production support. Ask how knowledge survives staff change and how releases, incidents and dependencies are managed after launch.
Calculate at least a five-year view: license or subscription, implementation, adaptation, integration, migration, infrastructure, support, internal effort and exit cost. Add the cost of the operational gap that the product does not solve.
- Named delivery and support ownership
- Documentation and knowledge continuity
- Recurring, variable and third-party costs
- Exit, migration and replacement conditions
Run a decision workshop, not a beauty contest
Create a weighted scorecard before vendor demonstrations. Use the same scenarios, questions and evidence standard for every option. Record unresolved risks and the assumption behind each score.
If no option meets a critical requirement, decide deliberately whether to change the process, extend a standard product, integrate another system or commission custom software. That gap is a design decision, not a footnote in procurement.