01 / The business problem
One proposal carried several competing risks.
North American tendering engineers worked with sales and Category Management to prepare bids for major projects. They needed credible component and bill-of-materials costs, supplier terms, manufacturing lead time, logistics time, and enough context to judge whether those inputs still held.
Before iTender, that evidence was fragmented across spreadsheets, email, SAP purchasing records, supplier outline agreements, and earlier tenders. Pricing one part could mean finding the latest invoice, checking negotiated terms, and locating the cost used the last time a similar project was bid.
Win the project while damaging margin or making the work unprofitable.
Lose potentially profitable work to a competitor.
Win based on a schedule the supply chain cannot support.
This made iTender a decision-support problem, not merely a quoting interface.
02 / Sources of truth
Different evidence carried different confidence.
A recent last-price-paid record was usually the strongest signal because it represented a verified supplier transaction. An outline agreement provided strong contractual evidence, but actual purchases could still diverge from it. The cost used in a previous tender was useful context, but it remained the weakest of the three because it was an earlier estimate rather than a completed transaction.
The product did not pretend to know one universally correct answer. It placed source type, dates, validity, currency, quantity, supplier, transit time, and lead time together so an experienced engineer could compare the evidence and account for changing market conditions.
A more predictive cost model was being explored with the project’s data scientist, using broader market and historical signals. It remained future work and was not part of the limited release.
03 / My role
Sole design ownership across a shared business problem.
I led discovery interviews, synthesis, user stories and journeys, information and workflow modeling, wireframes, stakeholder validation, high-fidelity design, and iteration. I also contributed to the React UI and maintained design ownership as the product moved toward implementation.
I worked closely with product management, engineering, tendering, and Category Management. A dedicated data scientist sourced SAP purchasing history through the data lake and integrated it into the application’s backend dataset. Based on recollection, the project moved from discovery toward implementation in roughly six months; that timing is not presented as an exact project metric.
04 / Product workflow
Move from the tender portfolio to the evidence behind one part.
The experience progressively narrows the decision. It begins with every tender in flight, moves into the parts and completion state of one proposal, then opens the sourcing evidence available for a single component.
After an engineer selected a source, the system extended the cost by the required quantity, updated the tender total and timing assumptions, and routed the part to the responsible subcategory lead for approval. Status and ownership remained visible at the project level.
The interface below uses demonstration data. Production tender, supplier, and purchasing records are not shown because that information is commercially sensitive.
The portfolio view brings active tenders, deadlines, total cost, missing-cost progress, and approval progress into one place. Search, urgency ordering, and personal work filters help engineers move quickly to the right proposal.
View full-size image ↗Inside a tender, the parts list exposes quantity, cost, approval state, ownership, and missing information. The team can understand the proposal’s completeness as an assigned punch list instead of reconstructing it from separate files.
View full-size image ↗At the part level, engineers compare outline agreements and last price paid alongside validity, currency, quantity, transit time, lead time, and supplier context. A third source farther down the profile preserved the cost used in the previous tender as lower-confidence historical context.
View full-size image ↗05 / What the product enabled
Move the work from finding evidence to judging it.
iTender reached a limited production release with the North American tendering team. Instead of hunting through spreadsheets, email, and SAP, engineers could work through an assigned list of parts while the application brought the available pricing and timing evidence into one place.
The value was not an automatically generated “correct” number. It was a shared environment where people could see what remained, compare sources, explain a choice, and send the selected cost and lead time to a subcategory lead for review.
I left TechnipFMC not long after launch, before I could observe a complete live tender move from creation through submission. The case study therefore makes no claim about win rate, margin improvement, cycle-time reduction, or longer-term adoption.