To compare technology suppliers fairly, assess each proposal against the same business requirements. Look at what is included, the full cost, the work left with your team, the support available and how the arrangement could adapt as the business changes. Where proposals differ, make those differences clear before deciding which offer is the best fit.

For transport and logistics IT teams, a network review provides a useful example. Imagine receiving three proposals: one includes installation, ongoing support and coordination with existing providers; another has a lower monthly price but leaves more work with your team; the third includes additional services that may or may not be needed. The prices are easy to put next to each other. The offers are not.

A useful comparison should make those differences understandable without forcing every supplier to propose the same solution. The aim is to see what each approach would mean for the operation, the internal team and the business’s future plans.

Compare the same requirement, not identical products

Different approaches can be valuable. One supplier might recommend improving what is already in place, while another proposes a replacement. Both deserve consideration if they address the agreed business need.

Ask each supplier to explain how its proposal meets that requirement, what is included and what sits outside the offer. Government guidance for public sector technology buyers recommends considering the full cost, the organisation’s own capabilities and the product’s life from purchase through to retirement. Although written for public sector buyers, those commercial questions are useful when comparing private sector proposals too.

For a business reviewing connectivity, give each provider the same information about locations, operating hours, existing equipment and expected changes. Where a supplier suggests a different approach, ask it to explain the benefit and the trade off.

A practical comparison can start with these questions:

These are starting questions, not a fixed scoring model. Decide which requirements are essential and which involve an acceptable trade off before comparing the final offers.

Compare the full cost and the work left with your team

Ask suppliers to price their proposals using the same assumptions: the same sites, users, service period and expected usage. Make one off charges, optional services and future price changes visible, rather than comparing a monthly figure from one provider with a broader package from another.

The proposal should also explain what the supplier expects your team to do. Who will gather the information, coordinate other providers, organise testing, support staff and resolve questions during the change? Those responsibilities belong alongside the price.

Consider two hypothetical offers. One includes someone to coordinate the change across several depots. The other expects the internal IT team to manage that work. Neither is automatically better, but they place different demands on the business. The lower priced offer may still be the better fit if the team has the time and experience available; that should be a conscious choice.

ArrowXL’s experience shows why capacity deserves attention. With a small internal IT function and significant technology reviews approaching, the business brought Darwin in to add market knowledge and manage the supplier review workload. ArrowXL retained control of the decision without having to carry the whole process internally. Its review ultimately confirmed that staying with the existing network provider was the right choice.

Ask what support looks like during a real working day

Rather than comparing the word “support” across proposals, ask each supplier to explain how its service would work in a situation that matters to your operation.

Suppose a depot loses connectivity before the morning shift. Who can report the issue? Who starts investigating? Who coordinates with other providers, and how will the business receive updates? Ask what the supplier commits to doing, not simply whether someone will answer the phone.

For cyber incidents, the National Cyber Security Centre recommends checking suppliers’ recovery plans and agreeing how incidents will be managed and reported, including timescales, contacts and expected actions. This provides a more useful basis for comparison than a broad statement that a supplier takes security seriously.

Choose scenarios that reflect your own operation. That might be an overnight warehouse shift, a customer booking service or access to information needed by drivers. The point is to turn a service description into something the people relying on it can understand.

Check how the supplier will support future change

A proposal can meet today’s requirement and still leave important questions about tomorrow. Rather than asking whether a service is “flexible”, give suppliers a few realistic changes to work through.

What happens if the business opens another site, takes on a customer with different reporting needs or needs to connect another piece of technology? Ask what would change in the service, the price and the work required from your team. It is also worth testing a smaller requirement: what happens if a site closes or demand falls?

Flexibility involves trade offs. Government guidance on cloud technology recognises that using more of one provider’s services can reduce management work while making it harder to move elsewhere later. It encourages organisations to weigh those benefits against the cost and difficulty of switching.

Depending more heavily on one partner may be entirely reasonable. The important thing is to understand what the business gains and what options it gives up, rather than treating flexibility as a promise that needs no further explanation.

Separate confirmed answers from assumptions

Not every detail will be settled in the first proposal. Some answers may depend on a site survey, access to technical information or a discussion with another supplier. That is not necessarily a problem, provided the uncertainty remains visible.

Record what is confirmed, what has been assumed and what still needs checking. Give each open question an owner and decide whether it needs resolving before the choice is made. This is more useful than a comparison sheet that gives similar scores to answers supported by very different levels of evidence.

Security provides a helpful example. The National Cyber Security Centre advises organisations to assess supplier evidence in proportion to the importance of the relationship and the risk involved. It also warns against treating supplier checks as a box-ticking exercise.

The same discipline can be applied to other important claims. If a proposed connection has not been checked, label it as unconfirmed. If a delivery date depends on something outside the supplier’s control, record that dependency. The team can then discuss the uncertainty openly, rather than discovering later that different people understood the offer differently.

Make the final comparison useful

The final recommendation should explain the differences that matter to the business. Which option best meets the requirement? What work remains with the internal team? What support is included? How would the arrangement handle a change in plans, and which questions are still open?

A short summary of those points, supported by the detailed proposals, gives IT, operations and finance something concrete to discuss. The cheapest option might be the right one. A more expensive option might justify its price through additional support or less internal work. Neither conclusion should be assumed before the offers have been compared on the same basis.

Darwin supports that work by helping teams clarify requirements, manage supplier questions, compare final offers and understand the commercial detail. The purpose is to give the internal team a clearer view of its options while keeping the decision with the customer.

Choosing for what comes next is not about finding a proposal with an answer to every possible future question. It is about understanding what the business is choosing, what it will need to contribute and how that choice can support the direction it wants to take.

Explore Choose for what’s next to see how Darwin supports major technology decisions across transport and logistics.