Software is eating the [enterprise] world.

Whether it’s evaluating communication and collaboration tools like Slack and Zoom; CRMs like Hubspot and Salesforce; Project Management tools like Asana or Jira; Business Intelligence platforms like Sisense etc. etc. etc., every enterprise is beginning or continuing software evaluations to enhance their company.

However, evaluation processes can be complex, distracting and biased. While at first sight, some software solutions seem to be the obvious choice for your enterprise, it may be the case that the non-obvious solutions are the best fit for you.

This post provides a general strategy for evaluating any software category. We’ll do this in two stages. First, we’ll define three important terms: Requirements, Blockers and Differentiators (RBDs). Then, we’ll consider the general RBDs which need to be included in every software evaluation regardless of the specific software category being evaluated.


Before we consider the general requirements, blockers and differentiators needed for every evaluation, we need to have a shared understanding of these terms:

  1. Requirements

A requirement is a feature, capability or outcome which you need a software solution to satisfy.

  1. Blockers

A blocker is a requirement which absolutely needs to be satisfied by a solution. If a blocker is not satisfied by a solution, the solution can immediately be disqualified from your evaluation.

  1. Differentiators

A differentiator is a feature, capability or outcome of a solution which distinguishes it from other solutions in its software category. Determining differentiators is important because most solutions in a category share the majority of their features or capabilities. Differentiators allow us to determine the solutions which can add the most value.

It is clear that these three terms overlap considerably. Some requirements will be differentiators (as only some solutions will satisfy them), some requirements will be blockers (because you absolutely need a solution to satisfy certain requirements), and blockers will act as concrete differentiators. However, the threefold distinction is useful for clarity.


RBDs can either be general or specific.

General RBDs are those which apply regardless of the specific software category being considered or evaluated.

Specific RBDs are those which apply only to a specific software category under consideration or evaluation.

This post concerns general RBDs only. The next section provides the general ones which should be considered by every enterprise when evaluating software.


Now that we have a shared understanding of RBDs, we can determine the general ones which need to be included in every software evaluation regardless of the specific software category being considered. As we discussed earlier, the three RBD concepts overlap. Therefore, we only need to determine the general blockers and differentiators (because requirements that are only requirements will likely be specific to your organisation or to the specific software category being evaluated).

  1. General Blockers

The blockers that need to be considered during your evaluation process will, for the most part, be specific to your needs as an enterprise. However, there are some common themes which blockers tend to follow.

  • Customer size

The question you need to ask here is: does the provider in question focus on serving enterprises? If they do not, they should be disqualified from your evaluation.

  • Industry focus

Does it matter to you whether the provider in question is focused on your industry? If so, general providers should be disqualified from your evaluation.

  • Desired outcomes

At the beginning of an evaluation, you need to be clear about the desired outcomes of introducing a new software solution. These will often be related to the use cases a provider indicates that their solution satisfies. If a solution does not fit your particular use case/desired outcome, you should probably disqualify it from your evaluation.

  • Deployment options

The question you need to ask here is simple: do you want a solution to be fully in the cloud, on-premise, or be capable of hybrid deployment? If you want an on-premise solution, all those solutions which are cloud-only can be disqualified from your evaluation.

  • Integrations

Because your enterprise probably uses a vast array of applications which contain important data, you’ll ideally want all your applications to be connected in some way. This is why integrations are important. If a new solution does not (or cannot) be integrated with your existing software solutions, you should probably disqualify it from your evaluation.

Perhaps the most important integration you need to consider is whether a solution integrates with your office suite, i.e. whether it integrates with G Suite and Microsoft Office 365, or your suite of choice.

  • Data security and compliance

Enterprises need to keep their data secure. Therefore, if a solution does not satisfy your security requirements, you should absolutely disqualify it from your evaluation.

There are many questions to ask when it comes to data security, but here are a few which may be vital:

  • Should be GDPR compliant
  • Should be certified under the EU-US Privacy Shield
  • Should support SAML-based SSO
  • Should be SOC-2 certified
  • Should be PCI compliant (if the vendor accepts payments)
  1. General Differentiators

General differentiators which need to be considered in every software evaluation can be separated into a number of categories:

  • Pricing and cancellation

It’s no surprise that companies compete on price. But, nowadays, it seems clear that those providers which are transparent about their pricing (structure) and make it exceptionally easy to cancel (and pause) are often at the top of their respective software category.

Providers can also differentiate on pricing structure (e.g. pay-as-you go, licence, per active user etc.). As a result, you should consider which pricing structure best suits your financial and accounting needs.

  • Support

The end-to-end support providers give their customers is a key dimension on which they can differentiate themselves. Key differentiators here include:

  • Whether a vendor provides 24/7/365 support,
  • Whether a vendor provides support over email, phone and chat,
  • Whether a vendor provides self-service support features (e.g. a knowledge base),
  • Whether a vendor provides a dedicated customer success manager, and
  • The average response time of the vendor’s support team
  • Functionality

While functionality is largely specific to the software category being considered, there are some general functionality-related differentiators which apply regardless of the software category being evaluated. Here are some general themes to consider:

  • Integrations 

Integrations was identified as a blocker. However, the more integrations a solution can provide, the more differentiated it becomes. As a result, solutions which do not fit your core integration needs can be blocked, but those which do can be differentiated by the number of integrations beyond your core integration needs that they provide.

Another consideration here is whether a vendor has easy-to-use, well-documented APIs for you to develop integrations from.

  • Reporting and analytics

If a solution has embedded reporting and analytics functionalities, you are able to determine the value the solution provides. As a result, this is an important differentiator to be considered.

  • Team management

There has been a general trend towards more open and collaborative organisations. As a result, solutions can differentiate themselves by providing team functionality (i.e. collaboration features) rather than simply having sole-user functionality.

  • Administration

There are several administration-related functionalities which solutions can differentiate themselves on. For example:

  • Whether a solution provides admins with audit logs (i.e. account activity)
  • Whether a solution supports role-based access control
  • Whether a solution supports automation of admin tasks and workflows
  • User experience

The UX and UI design of software solutions is increasingly a central consideration in software evaluations. We are seeing software providers win based solely on UX alone. Here are some UX differentiators which seem to apply regardless of the software category being evaluated:

  • Whether a solution is cross-platform (i.e. optimised for desktop, tablet and mobile),
  • Whether a solution has mobile application, or
  • Whether a solution supports multiple languages


While we did not determine general requirements in the previous section, it is important to emphasise one seemingly obvious thing about requirements during software evaluations:

The more requirements a solution satisfies, the better it fits your needs.

While this is obvious, people often ignore this because of the partiality and bias inherent in evaluation processes.


Olive is purpose-built to help enterprises evaluate technology. From requirement management through to vendor selection, Olive provides a single platform for collaboration and knowledge sharing. With all of your requirements and vendor capabilities in one place, you can make fast, accurate decisions based on data, not bias. Try us out today!