Offshore oil-and-gas equipment procurement · via Softeq
EIT — Where a Procurement Argument Becomes an Interface
Buying a subsea separator is not a purchase. It is an argument about several hundred numbers, and it used to live in email.
The challenge
Offshore equipment is not bought from a catalogue. A separator, a compressor, a subsea tree or a blow-out preventer is a specification of several hundred parameters, and buyer and supplier negotiate it for weeks. That negotiation ran on email and spreadsheets. Versions diverged, a comment about one parameter sat in a different thread than the parameter itself, and by the time a value was agreed nobody could say why. The cost of the package moved with every settled figure, and no one saw it move. Fifteen system types, each with its own parameter set and its own suppliers. Four roles who all write to the same record but must never see the same thing.
What I did
1. Made the argument visible. Buyer and supplier were resolving hundreds of parameters in email, where a value and the reason for it lived in different threads. I put both sides on one row — designed value, requested value, agreed value — so a disagreement is a cell, not a correspondence.
2. Attached the conversation to the parameter, not the document. Comments thread on the individual row, deviations flag themselves the moment a requested value differs from the designed one, and the decision is recorded with a name and a date. Nobody has to remember why a number moved.
3. Split progress into three meters instead of one status. A specification is never simply "in progress" — it is found but unanswered, or answered but unverified. Search, Collaboration and Validation each track their own share, which is what let a buyer see where a package was actually stuck.
4. Gave each role its own view of the same record. Buyer, supplier, inspection engineer and the contractor across projects see one specification rendered four ways — the supplier never sees a rival's quote, the engineer sees the points they have to sign off, the contractor sees cost rolling up across projects.
Fig. 01 — One record, four ways in
Who sees what
01 · Buyer
Procurement engineer
Owns the specification and the budget
Search by parameters
Short list
Request to supplier
Negotiation table
Approve or reject
02 · Supplier
Equipment manufacturer
Answers with what it can build
Incoming requests
Requested value per parameter
Deviation with a reason
Inspection points
03 · Engineer
Inspection & test
Signs off that it was verified
Witness & hold points
Request validation
Decision per parameter
Validation history
04 · Contractor
Across projects
The only role that sees more than one
Project list
Cost roll-up
Documentation
Progress by stage
Fifteen system types share this shape — separators, compressors, subsea trees and manifolds, blow-out preventers, drilling risers, pipelines, umbilicals. The supplier never sees a rival’s quote; the contractor is the only role that sees across projects.
Fig. 02 — What shipped
Delivered design, clickable
The solution
A platform where the specification itself is the workspace: search by technical parameters across 15 system types, a short list, a request to the supplier, and then the negotiation table where every parameter is resolved in place. Threaded comments per row, deviation flags, inspection points tied to the values they verify, a validation history with who decided what and when, and a project cost that recalculates as the specification settles.
What I’d do differently
I designed the table before I understood the argument. The three-column model came out of the data — designed, requested, agreed — and it was right, but I arrived at it by mapping the fields rather than by watching a negotiation. The threads, the deviation flags and the three progress meters all came later, once it was obvious that the hard part was not storing the values but knowing whose turn it was. I would start from the argument next time, and let the table fall out of it.