Software Selection

Software selection requirements written from your processes

A list of features ticked yes or no is useless for choosing: every vendor answers yes. That's why we write requirements as scenarios from your actual operations. For example: a trade customer with their own price list uploads a large multi-line order from Excel, part of it is out of stock and they ask for partial delivery; the ERP must receive it without manual intervention.

Each requirement is classed as essential or desirable, and the non-functional ones are added: mandatory integrations with the ERP, store or CRM, data and user volumes, countries and languages, and which team will maintain the tool once it is in place.

Requirements are gathered in sessions with each department and validated in writing before any vendor is contacted. That keeps the process from being shaped by the features each vendor highlights on its website. That document is also the first deliverable: even if nothing is bought in the end, the company has in writing what its sales and purchasing operation needs.

Shortlist and guided demos in software selection

Starting from the market, we first rule out candidates that fail any essential requirement. With those that remain we run guided demos: every vendor receives the same script, with your products, your customer types and your scenarios, and must solve them live instead of following their usual presentation.

Key users from each department attend the demos and score each scenario on the spot. That way solutions are compared on the same questions and the winner isn't simply whoever presents best.

Before the demos we ask each candidate for a written response to the requirements, with an indicative price proposal and information about its implementation partners. That response already makes it possible to rule out those who don't fit without spending a session on them.

The software selection evaluation matrix

The criteria and their weights are agreed before seeing any demo, so they aren't adjusted afterwards to suit the favourite. They include functional fit with the scenarios, ease of integration with the other systems, total cost over several years (licences, implementation, maintenance and infrastructure), usability for each profile and the strength of both the vendor and the implementation partner.

We complete the matrix with verified references: conversations with companies that use the tool in a context similar to yours, chosen by us and not only by the vendor.

When two candidates are very close, we arrange a second, more technical session focused on the open questions, usually ERP integration or behaviour with large catalogue and order volumes. The matrix is shared with all evaluators, so every score is justified and the final recommendation can be defended before management.

Negotiation and the move to implementation after software selection

With the finalist, the negotiation goes beyond the licence price: the exact implementation scope, the per-user or per-module licensing model, support and upgrade terms, ownership of custom developments and how you get your data back if you ever change tools.

The selection requirements and scenarios aren't thrown away once the contract is signed: they become the basis for the implementation contract and the acceptance tests. What the vendor showed in the demo is what has to work in production.

Before signing, we also review the implementation plan proposed by the vendor or its partner: phases, assigned profiles, the time expected from your team and acceptance criteria for each delivery. A good product with a poor implementation plan is still a bad purchase.

If you need it, we also join you at the closing meeting with the vendor to check together that the contract reflects what was agreed during the process.