Rebuilding a complex quote system for custom packaging

TL;DR

• Context: Lead UX at a B2B packaging e-commerce scaleup.
• Problem: When quoting custom packaging, a sales rep retyped data into a second system by hand. A quote took several days.
• What I did: I merged quoting with building the offer and organized it into 3 paths on one screen.
• Result: A quote is ready the same day. A team ~20% smaller kept sales at the same level.

Diagnosis

Quoting custom packaging can’t be done simply. One order can have many line items, and each of them several variants (size, material, print, quantity). Each variant is priced from one of three sources, and at the end someone has to decide on the margin. That complexity couldn’t be removed. What could be removed was the unnecessary work around it. A sales rep retyped the same order data into a second system and waited several days for a price. So I kept the dense screen, because experienced people use it, and dealt with the retyping instead. I connected the two systems and organized quoting into three paths right where the rep builds the offer.

flowchart TD
    subgraph Before["Before"]
        A1["Sales rep enters the order<br/>into the quote system"] --> A2["Gets prices"]
        A2 --> A3["Retypes everything by hand<br/>into the offer system"]
        A3 --> A4["Customer waits several days"]
    end
    subgraph After["After"]
        B1["Customer enters line items<br/>and variants"] --> B2["Sales rep picks 1 of 3 quote paths<br/>where the offer is built"]
        B2 --> B3["Offer ready<br/>the same day"]
    end

    classDef good    fill:#e6f2ea,stroke:none,color:#1f4d33,rx:14,ry:14
    classDef bad     fill:#faeaea,stroke:none,color:#5f2626,rx:14,ry:14
    classDef accent  fill:#27272a,stroke:#3f3f46,stroke-width:1px,color:#fafafa,rx:14,ry:14
    class A1,A2,A3,A4 bad
    class B1,B2 good
    class B3 accent
    style Before fill:#fdf5f5,stroke:#e0c3c3,stroke-width:1px,color:#5f2626,rx:14,ry:14
    style After fill:#f2f8f3,stroke:#c2dcc8,stroke-width:1px,color:#1f4d33,rx:14,ry:14
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

What I did

• I led the quoting rebuild as Lead UX, with two designers on my team. When the PM left in the middle of the project, I took over the whole process.
• In an old Ruby on Rails app I designed a table where line items and their variants are visible at once. Each cell can be expanded to show quote details: the quote type on the left, details on the right.
• I designed 3 quote paths: instant from an API, through the supplier platform, and manual. The rep starts them where the offer is created and picks the fastest one that fits.
• I removed the manual retyping between the quote system and the offer system. Line items and variants entered by the customer are the rep’s starting point right away.

A reconstructed sketch. Each row has a quote status (⚡ means an instant quote; otherwise a request goes out and 1 to n quotes come back). Nothing has to be retyped into a second system.

Results

• A quote takes one day instead of several (at least a day faster).
• The team of sales reps handling custom orders was ~20% smaller, and still kept sales at the same level during a market slump.
• 3 quote paths on one screen (instant, supplier platform, manual) instead of a separate quote system and retyping.
• Line items and variants entered by the customer go straight into the offer. Nobody enters data twice.

The problem

What wasn’t working in quoting custom packaging?

Anything outside the standard catalog had to be priced by a person. A sales rep entered the order into the quote system, got prices, and then retyped everything by hand into a separate offer system to prepare the customer’s offer. A quote like that took several days. The rep was stuck, and the customer could walk away in the meantime.

Why not just simplify the screen?

Because this complexity is real and the sales rep needs it. A custom order really does have many line items with variants, each priced from a different source, and at the end someone has to decide on the margin. If I had “simplified” the screen and added white space, I would have hidden things the rep has to see to decide quickly. The most could be gained on the work around quoting.

My role / scope

• I was Lead UX for the back-office and custom-order sales area. I had two designers on my team, and after a wave of layoffs, one.
• I mapped the current process together with the PM. When she left, I took it over completely.
• The rebuild covered several systems: the quote system, the offer system, the supplier platform and the customer portal.

Process

• A process map with sales reps. Before I designed anything, I mapped out the entire current quoting process with the people who worked in it every day.
• A table prototype and tests with 2–3 sales reps. In these sessions we worked out how much information to fit on the screen so it could still be scanned quickly.
• During the project I took over the whole delivery and coordinated the work of the backend teams and the supplier platform.

Key decisions & trade-offs

• Quoting inside the offer, with no separate system. What slowed things down most was retyping data between the quote system and the offer system. After merging them there’s more information on one screen, but the double work is gone.
• Three quote paths. An instant quote from an API works for small changes to a standard product and gives a price in seconds. A one-click request through the supplier platform fits moderately complex orders, takes 1–2 days and has a live status. Manual entry is kept for truly unusual orders, often after a conversation in which a supplier agreed to a lower rate. A single path couldn’t handle such different cases.

• A dense screen for experienced sales reps. The table shows all quote statuses at once, and each cell can be expanded. Here, density is what lets people work fast. Simplifying would have slowed down exactly the people who close the sales.
• A dependency between systems we missed. I have to admit we made a mistake here. The customer portal displayed an element from the supplier platform, and we noticed it too late. Developers had to do extra work, and the project got longer. Partly it was our oversight, and partly the result of knowledge about such connections leaving the company after a wave of layoffs.

flowchart LR
    A["Quote system"] --> B["Offer system"]
    D["Supplier platform"] --> B
    C["Customer portal"] -->|"displayed element, dependency noticed late"| D

    classDef info    fill:#e9eff8,stroke:none,color:#1e3a5f,rx:14,ry:14
    classDef bad     fill:#faeaea,stroke:none,color:#5f2626,rx:14,ry:14
    class A,B,D info
    class C bad
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

A reconstructed sketch. Three quote sources on one screen, choice on the left and details on the right. Nothing has to be retyped into a separate offer system.

How it turned out

Quotes went from several days to one. The sales team was ~20% smaller and still kept sales at the same level during a slump in which sales usually dropped. The hardest part wasn’t the screen itself but coordinating the several systems behind it: the supplier platform, the customer portal and several backend teams. That’s what made the project longer. Once it was clear where the time was being lost, designing the screen was the easy part.

What I took away

• Instead of fighting complexity, it’s worth removing the work around it. Quoting was genuinely complicated, and sales reps needed that. What helped most was removing the retyping and the waiting.
• I map dependencies between systems first, then design. The portal dependency we noticed late cost us a lot of time. In my view, projects spanning several systems most often break where those systems meet.
• During layoffs, knowledge leaves with people. The person who knew about the dependency might no longer have worked at the company. When I take over something from others, I assume there’s something I don’t know.
• A dense screen can be an advantage. A screen that looks cluttered to an outsider is often exactly what an expert working on it every day needs.