Two engineering firms bid to survey and inventory the facility network of a private industrial group. Similar price, comparable teams, methodologies that read almost the same. The award turns on a detail neither firm had treated as central: one proposal attached a link to a sample inventory the client's committee could open, navigate and filter from a browser; the other described the deliverable as a set of drawings and an Excel database. The committee — operations people who would live with that inventory for years — scored the first one high. Not for the quality of a survey that had not yet happened, but for what the deliverable promised to leave in their hands.
In private procurement, when price and team fall into similar ranges, the technical score decides. And that score is set by people who judge not the elegance of the proposal but its future usefulness. That shift in criteria — from what is promised to what the client will be able to do afterwards — is the competitive lever many technical offices have yet to build into how they bid.
The wrong reflex: standing out by adding weight
Faced with the need to raise the technical score, the usual reflex is to add: more tools, more deliverables, more layers of enterprise-grade software. The trouble is that the client who scores rarely wants to administer a heavy platform. A system that demands weeks of training before the team can use it does not add points, it subtracts them, because the evaluator senses the cost of adoption and discounts it mentally. Differentiation by piling on complexity works on the page and fails in the head of the person reading it.
The differentiation that does score runs the other way. A modern, light layer the client can use with no onboarding signals something the evaluator values above raw power: that the firm understands their operation and will not dump a maintenance burden on them. Real sophistication is measured by how little the end user has to learn, not by how much the system can do.
What the committee actually values
It pays to look at who scores. In a private client, the technical evaluation committee usually includes the head of operations, the maintenance lead and sometimes an asset manager. They are the ones who will live with the deliverable. Three attributes weigh on their judgement far more than the rhetoric of the proposal.
The first is the navigability of the deliverable. An inventory of tens of thousands of assets handed over as a stack of drawings and spreadsheets is, in practice, a dead archive: no one opens it twice. When that same inventory arrives on a map layer the client moves through smoothly, the asset reads as live and usable. The technical difference lies in the visualisation architecture: a layer built on vector tiles and browser GPU rendering sustains navigation of networks above 100,000 assets with no upfront paging or filtering, where a viewer using traditional markers slows down far sooner. The committee does not need to know the mechanics; it sees the result on the first click.
The second attribute is traceability and fit with the standard. A client aiming to order its asset management in line with ISO 55001:2024 values a deliverable that speaks that language from the start: criticality, asset hierarchy, structured history. This is not bureaucracy; it is the foundation on which the client will build its management system. A bid that hands over the inventory already aligned with that framework saves the client later work it knows to be costly, and that converts into points.
Portability as a trust argument
The third attribute is less obvious but increasingly decisive: what happens to the data the day after. An experienced committee has at some point suffered dependence on a vendor that held its information hostage. So it rewards proposals that guarantee in writing the export of data in standard formats — those defined by the Open Geospatial Consortium, such as GeoPackage or GeoJSON — and the existence of a documented API to integrate with its ERP or plant system. The firm that offers real portability is not granting a technical concession; it is telling the client it trusts the quality of its own work and has no need to lock it in. Maptainer was designed on that open GMAO + GIS premise, but the criterion holds for evaluating any tool a technical office decides to prescribe: if the data does not come out clean, the deliverable does not belong to the client, it belongs to the software vendor.
There is a further advantage the evaluator appreciates without asking for it. A tool that works in the field without depending on coverage lets the survey happen on site with no notebooks and no later transcription, which cuts delivery time and the risk of error in digitisation. The client does not score offline capability in the abstract, but it does score a credible delivery schedule and a low revision rate, which is exactly where that capability shows.
From a closed project to a recurring service
There is also a commercial consequence that goes beyond the single award. A deliverable the client uses daily opens the door to a recurring relationship: support, inventory updates, extension to new sites. The technical office that hands over a live layer stops billing a closed project and starts sustaining a service — the difference between one-off revenue and a client that renews. That recurring logic is hard to build on top of a stack of PDF drawings; it is natural on top of a navigable inventory the client has already folded into its daily operation. For a firm that weighs the lifetime value of a client against the cost of winning it, the shift is far from minor.
Before the next bid
The useful question for a technical office preparing its next proposal is not how many features it can list, but a more uncomfortable one: when the client's committee reads this bid, are we promising a document they will file or an asset they can operate the day after they receive it? If the answer is the former, the proposal competes on price and team alone, and gives up the ground where the technical score is truly won.