Most procurement processes we are asked to review have a common flaw: the requirement was written as a feature list. Suppliers respond to the list, everyone agrees the list is met, and the business ends up with software that satisfies the document and not the operation.
Write the requirement as outcomes and constraints instead. What must be true for this to be worth doing? What are the volumes, the integrations, the compliance boundaries, the moments in the working day that must get faster?
Then test the supplier on the awkward parts. Ask how they would handle your worst data, your busiest week, your least technical user. Ask what they would remove from your scope. The answer to that last question tells you whether you are talking to an operator or a salesperson.
Watch the total cost of ownership: implementation, data migration, integration, training, and the internal time nobody budgets. A cheaper licence with a heavier implementation is often the more expensive choice.
Finally, protect the exit. Data export, contractual notice, documented integrations. You are not planning to leave, but the terms you agree while you have leverage are the only ones you will get.