A platform demo is usually competent, and it is built to move your requirements towards what the product does well. That is its purpose, and a legitimate one.
Why the order matters
Criteria written after the vendor calls are shaped by those calls. By then the requirement list contains at least one item that exists because a product demonstrated it well, and lacks at least one because no product raised it.
Writing them first is straightforward. It is mainly a matter of deciding, before anyone is in the room, which failures you could not tolerate and which capabilities you would use in the first year.
What belongs in the criteria
- The workflows the platform has to support today, named specifically
- The integrations that must exist, separated from the ones that would be useful
- The data that has to leave the platform, and in what form, if you replace it
- The operational burden you are willing to carry, measured in people as well as licences
- The conditions under which you would consider the selection a mistake
Plan the exit before the selection.
The exit question is the one most often skipped and the one that costs most later. Before selecting, establish what leaving looks like: which data comes out, in what format, how long it takes and what stops working during the move. If a vendor cannot answer those questions clearly, treat that as a risk in the selection.
Handing the criteria over
The criteria are a deliverable in their own right. Handed over at the end of the engagement, they let the organization make the next platform decision without outside help.