Integrate freight quotes at checkout to prevent cancellations and costly delivery fees

At Inxeption, a B2B industrial e-commerce startup, buyers paid upfront for products but received freight quotes later via Ops calls.

This delayed pricing caused order cancellations from sticker shock. When orders did proceed, incorrect delivery details led to unexpected fees that Inxeption absorbed to protect customer relationships, despite terms placing responsibility on buyers. These fees were causing the company to lose money on orders.

Here's an overview of the final design in about a minute. Read on to learn about the journey and how I led the project forward.

I took on this project while juggling two other high-impact initiatives:

• A third-party payment terms integration

• A redesign of product configuration, which was a core platform feature

I was the sole app designer at the time, and our junior PM was filling in after multiple departures. Company instability added urgency and uncertainty.

Examples of decisions our Ops team made instinctively, which I had to figure out how to digitize:

1. Shipping mode (Less Than Truckload or LTL vs. Full Truckload or FTL) is based on linear footage—how much trailer space a shipment needs—and has a major impact on cost. Each mode also uses a different API. And because LTL cutoffs varied by carrier, we worked with Ops to standardize the logic.

2. Delivery dates vs. pickup dates create complexity: While buyers care about delivery dates (especially in construction where timing is critical), freight APIs and booking systems operate on pickup dates. Our Ops team would manually iterate through multiple quotes, adjusting pickup dates to meet delivery requirements, similar to optimizing airline bookings. Did Ops think this was necessary for MVP or was there a workaround?

3. Warehouse location affects pricing: While Ops could check an inventory spreadsheet, our code had to identify the nearest warehouse with inventory and handle edge cases like stock spread across multiple warehouses, no stock, or sellers not using the inventory feature. What would Ops do?

These are just three of the insights revealed through interviews.

Example: Optimizing pallet orientation to reduce linear footage could be harmful

I proposed automatically rotating pallets 90 degrees to optimize truck space and reduce costs. Through diagrams (above) showing a 53-foot trailer with standard 48" x 40" pallets, I illustrated how rotation could reduce linear footage from 16 feet to 13.3 feet, potentially saving money by qualifying for LTL rates instead of FTL.

Counterintuitively, logistics experts advised against automatic rotation to save money, explaining that warehouses may lack equipment to reorient pallets, and some products (like glass solar panels) cannot be safely stacked. This insight led to letting manufacturers specify stacking and turning capabilities, rather than making assumptions.

Input A: How do the items fit in the truck?

In the product configuration, I added a field to define the type of handling unit (such as a pallet) and a conversion field allowing sellers to specify N items per handling unit. I also clarified that the dimensions and weight fields applied to the handling unit, not an individual item, which was a point of confusion in past user feedback.

Based on interviews with Ops, I added flags to indicate if a handling unit could be turned and stacked. We had also worked with stakeholders and PM to standardize the cutoff between LTL and FTL, choosing a conservative linear footage of 15 feet and removing carriers with shorter cutoffs.

Together with the formula to calculate linear footage developed by our engineer, we had all the data to determine how much space a shipment would occupy and whether it should be quoted as LTL or FTL.

Now that we could capture all the data for freight quoting, we needed to map data sources to the APIs. While our engineer understood the data flow, I created a numbered, color-coded diagram to help QA and future collaborators. It mapped every UI input to the existing logistics quoting fields, assuming those already aligned one-to-one with the APIs.

Once all API data sources were identified, I designed the experience of requesting quotes and viewing responses. Since dozens of results could be returned, I needed to prevent analysis paralysis while still offering choice, especially for buyers who avoid certain carriers due to past experiences.

We explored several models, including expandable sections and showing the top three cheapest and fastest options. Ultimately, we streamlined the interface to show just the cheapest quote, the fastest quote, and an invoice option for complex cases. Our reasoning: most buyers either want the fastest or cheapest shipping; those with special needs could pay for the product now and coordinate shipping later with Ops.

I designed corresponding seller interfaces to show the selected quote and enable one-click booking, streamlining the handoff to fulfillment. I also added a link back to the order for context, an enhancement that benefited all quote pages.

To ensure accurate implementation, I authored multiple supporting documents:

• Requirements specifications: Screen-by-screen breakdown of all changes and new functionality documented in over 10 specs, in collaboration with the lead engineer.

• Data mapping: Color-coded diagrams showing how each input field connects to the API, shown earlier.

• Testing calculator: Tool for QA to understand LTL vs. FTL logic without attending all design discussions.

I collaborated closely with Engineering and stakeholders throughout implementation, resolving issues via async communication and targeted meetings.

Example: During development, we discovered that outdated shipping destination fields were incompatible with the new APIs, causing incorrect destination data and costly accessorial fees.

I had already begun redesigning that section, which was slated for post-MVP implementation, but I quickly finished the design, aligned with stakeholders, and documented the changes for Engineering and QA. These updates were successfully included in the MVP.

This experience reinforced the importance of uncovering dependencies earlier in the planning process.

Our Ops team, who served as subject matter experts throughout the process, confirmed that the solution provided a competitive advantage in B2B e-commerce while accurately reflecting their operational needs.

This case study demonstrates my ability to translate complex operational requirements into intuitive user experiences while managing technical constraints and business priorities in a resource-constrained environment.