Offers: a digital quoting experience for industrial commerce

From an unconstrained vision to something buildable

Exploring the vision

I was given the opportunity to explore Dynamic Purchase Order (DPO), an unconstrained concept for how Buyers and Sellers could collaborate on a Purchase Order in real time. This meant I could design the experience without being limited by Inxeption's existing UI/UX patterns or technical architecture. I researched how quoting and purchasing processes work in the real world, learning the terminology, the stakeholders involved, and the flow between them.

That research surfaced a naming problem. Purchase Orders are issued by the Buyer, but the same document takes on different names as it moves through the cycle: a Request for Quote (RFQ), a Quote, a Purchase Order (PO), and finally an Order once accepted. The concept itself went by several names: Dynamic, Digital, and Living Purchase Order. Anchoring the whole concept to “Purchase Order” only captured one part of that cycle.

Grounding it in reality

Running in parallel was Deals, an internal tool built for Inxeption's sales reps that mirrored the milestone of a Seller sending a Quote to a Buyer. After Deals launched, the Director of UX merged the Deals and DPO flows into one unified experience, expanding beyond the original internal use case toward the goal of serving Buyers and Sellers transacting within the Inxeption Marketplace.

I took ownership of the next iteration, which became Offers, and moved it away from Deals' more internal sales-facing framing toward something more neutral to both parties involved in the transaction. Offers was a meaningful step toward the original DPO vision, but no longer free from constraints. It was scaled to what we could realistically build within Inxeption's existing systems in the near term.

Rethinking the long form

Offers inherited its tab structure from Deals, but most of an Offer’s fields lived in the Overview tab, a single long form that was difficult to navigate given the complexity of industrial transactions. I designed Train Stop, which broke the form into six steps in a guided sequence, like moving from one train stop to the next. I explored a track-line stepper pattern and settled on a numbered tab sequence with status icons, which fit the existing tab structure and let users see at a glance which steps were complete or missing information.

The full Train Stop design was never built, but one piece of it shipped: creating an Offer with only the minimum required fields.

Giving Buyers a way in

The Offers launch revealed an important gap: Buyers could view a Seller-initiated Offer, but they couldn’t initiate a structured request themselves, which left the Marketplace skewed toward Sellers. The only option was a simple quote request that collected the product along with contact details and an optional note.

I designed the Request for Offer form as a structured alternative that let Buyers specify what they needed up front, including details only they would know, such as a pickup contact, rather than leaving the Seller to fill them in. The Marketplace button uses the real-world term “Quote,” while the form uses “Offer” to distinguish it from the simple quote request, which remained available.

Editing together without conflicts

Buyers needed to edit an Offer after submitting a request, which created a new problem: two parties could now change the same Offer. A Buyer shouldn’t accept an Offer after a Seller changed a detail they hadn’t seen. I worked through the scenarios behind Offer snapshots, which capture every field and its current value, so a Buyer would only ever accept a version they had actually seen.