Service 06 · Technology Assessment & Selection

Software Selection& Vendor Advisory

Buying business software well is a discipline. Requirements written down before anyone sees a demonstration, options compared on the same basis, and a recommendation you can still defend in two years.

Indicative price
From £1,700
Capability area
A3 — Technology Assessment & Selection
Activity
62020 IT consultancy
A team comparing software vendor options in a meeting

A demonstration shows you what a product does well. It is designed to. The work is finding out what it does badly.

Positioning

We are not a reseller. That is the entire point.

Most software advice in the market comes from organisations that implement, resell or receive referral fees from a particular product. That does not make them dishonest, but it does mean their conclusion is knowable in advance.

Alvoris holds no reseller agreements, no partner status and no referral arrangements with software vendors. We are paid for the selection work, not for the outcome, and we do not implement the product we recommend unless you separately ask us to.

That leaves us free to reach the conclusions the evidence supports — including “none of these are worth the disruption” and “the product you already own would do this if it were configured properly”.

Business problems

How software purchases go wrong.

  • 01Requirements written after the shortlistIf the specification is assembled from what the products offer, the evaluation has already been decided. Requirements have to come first.
  • 02Demonstrations driven by the vendorA vendor-led demonstration shows a curated path through the product. Scripting the demonstration around your own scenarios changes what you learn from it.
  • 03Comparison on licence price aloneImplementation, migration, training, integration, support and the internal effort of change frequently exceed the licence cost in year one.
  • 04Nobody asked about getting the data outExport capability is rarely examined at purchase and becomes decisive later. It should be a scored criterion, not an afterthought.
  • 05The awkward requirement is deferredThe one process that does not fit is often the one that matters commercially. It should be tested hardest, not set aside for later.
  • 06The decision cannot be explained afterwardsWhen the rationale exists only in a conversation, it does not survive staff changes or scrutiny. A scored evaluation leaves a defensible record.
Service diagram

Requirements first. Options second. Never the other way round.

The funnel narrows deliberately, and at every narrowing the reason for exclusion is recorded — which is what makes the final choice defensible.

Software selection funnel Requirements are defined, the market is surveyed, a shortlist is drawn, options are evaluated against weighted criteria and a recommendation is issued. Step 01 Requirements Written before any demo Must-have vs preference Step 02 Market options Typically 8–15 candidates Step 03 Shortlist 3–4, with exclusions recorded Step 04 Evaluation Scripted demonstrations Weighted scoring · three-year cost Reference conversations Step 05 Recommendation One stated preference Reasoning attached Residual risks named Two conclusions that remain available at every stage Keep and reconfigure what you already own Build instead — no product fits the process Neither conclusion costs us anything to reach
Your criteria Narrowing stage Written recommendation
What Alvoris can deliver

What the engagement includes.

Scope is agreed in advance and stated in the quotation.

01Requirements definitionStructured capture from the people who will use the system, separated into mandatory requirements, valuable additions and preferences.
02Weighted evaluation criteriaCriteria and weightings agreed with you before any product is examined, so the scoring cannot be shaped retrospectively.
03Market surveyIdentification of candidate products, including options outside the obvious ones and any sector-specific systems worth considering.
04Shortlisting with recorded exclusionsA shortlist of three or four, with a written reason for every product excluded — so the question “why didn't we look at X?” already has an answer.
05Scripted demonstrationsDemonstration scripts based on your real scenarios, including the awkward ones, so every vendor is asked to show the same things.
06Total cost analysisThree-year cost including licences, implementation, migration, training, integration, support and internal effort.
07Reference and viability checksConversations with existing customers where available, and a practical view of each supplier's stability and support arrangements.
08Written recommendationA stated preference with the reasoning, the residual risks, the implementation considerations and the conditions under which we would change our view.
Common use cases

Typical selection engagements.

Customer systemsCRM selectionChoosing a customer relationship system that matches how your sales and delivery actually operate rather than a generic pipeline model.
Business systemsERP and financeLarger operational or finance platforms where the cost of a poor choice is measured in years rather than months.
Sector softwareIndustry-specific productsComparing specialist products for your sector, where the market is narrow and the differences are not obvious from marketing material.
Build or buyDirect comparisonA bespoke build assessed against the closest available products on the same criteria, including three-year cost and the cost of compromise.
RenewalStay or moveEvaluation ahead of a contract renewal, with switching cost and migration risk properly quantified rather than assumed.
ConsolidationChoosing between incumbentsWhere two merged organisations run competing systems, an objective comparison of which to retain.
How the engagement works

Five stages over three to six weeks.

Vendor availability is usually the limiting factor. We manage that correspondence so your team is not chasing sales representatives.

  1. Stage 01Requirements and criteriaInterviews, process review, and a written requirements document with weighted evaluation criteria. Signed off before we look at any product.
  2. Stage 02Market survey and longlistCandidates identified and assessed against the mandatory requirements, with exclusions recorded and explained.
  3. Stage 03Shortlist and demonstrationsThree or four products taken forward. We write the demonstration scripts, attend the sessions and score against the agreed criteria.
  4. Stage 04Cost, references and riskFull three-year cost assembled, reference conversations held where possible, and implementation risk assessed for each option.
  5. Stage 05Recommendation and presentationWritten report with the scored comparison and a stated recommendation, presented to your team or board with time for challenge.
Outputs and deliverables

What you hold at the end.

  • A written requirements document you own and can reuse
  • Weighted evaluation criteria agreed in advance
  • A longlist with recorded reasons for exclusion
  • A scored comparison matrix across the shortlist
  • Three-year total cost analysis per option
  • A written recommendation with reasoning and residual risks
  • Negotiation and implementation considerations
Indicative pricing and timing
Indicative starting price From £1,700 Final pricing depends on scope, complexity, requirements, existing systems and delivery timeframe. The starting figure reflects a single system category with a manageable requirement set. Multiple categories, several stakeholder groups or a formal procurement process will increase it.
Typical engagement range 3–6 weeks From kick-off to recommendation. Timing depends on scope and, in practice, on how quickly vendors make demonstration slots available. We tell you at the outset where the schedule risk sits.
Who it is suitable for

And who it is not for.

A good fit

  • Organisations facing a purchase significant enough to justify getting it right
  • Anyone who has been shown three demonstrations and become less certain
  • Boards or trustees needing a defensible, documented decision
  • Businesses weighing a bespoke build against available products
  • Organisations approaching a renewal without having tested the market

Probably not a fit

  • Low-value purchases where the evaluation would cost more than the software
  • Decisions already made, where a report is wanted as justification
  • Formal public procurement requiring specialist procurement expertise
  • Situations needing implementation resource rather than a selection decision
Questions about this service

Frequently asked.

No. Alvoris Software Ltd holds no reseller agreements, partner status or referral arrangements with software vendors, and receives no payment of any kind from a supplier in connection with a recommendation. Our fee comes from you and nowhere else.

If that ever changed for a particular product category, we would declare it before the engagement began rather than in a footnote.

It happens, and it is a genuine conflict of interest, so we handle it explicitly. The build option is costed on the same basis as the products, using realistic figures rather than optimistic ones, and the recommendation states plainly that we are capable of doing that work.

You are under no obligation to engage us for it. Several clients have taken our requirements document and build estimate to another developer, which is a perfectly reasonable use of the work.

Yes, if you want us to. We can approach suppliers, issue the requirements, arrange and script demonstrations and manage the correspondence — which keeps your team out of a sales process. Some clients prefer to hold the relationship themselves and have us in the room for the evaluation only. Either arrangement works.

We can advise on the commercial and technical points worth pressing — term length, price protection, data export obligations, support response commitments, exit provisions. We are not solicitors and do not provide legal advice; for the contract itself you should take proper legal review.

Typically eight to fifteen candidates at longlist, narrowed to three or four for detailed evaluation. Evaluating more than four properly is rarely worthwhile — the effort per option is significant and the ranking seldom changes below fourth place.

Every excluded product has a recorded reason, so the longlist itself is a useful document.

Implementation of a third-party product is normally carried out by the vendor or their implementation partner, and that is usually the right arrangement. We can remain involved in a client-side role — reviewing the implementation plan, testing against the original requirements and holding the supplier to what was demonstrated — if that would be useful. It is quoted separately.

Start a conversation

Before the third demonstration, not after it.

The best time to bring us in is before you have seen any products — while the requirements can still be written independently of what a vendor has shown you.