Multi-path Intake
PRM
Partner Network Portal
Four partner types at four levels of fluency converged on one validated output, and a scaling failure in the specified eligibility logic was caught before it shipped.
A global semiconductor manufacturer's partner network registered deals and built quotes across fragmented tooling with no single validated path. The existing CRM and quoting systems were too embedded to displace, so the portal had to sit on top of them as a platform-agnostic layer. The tooling was never the hard part. Partner types with very different levels of product fluency all had to arrive at the same validated output, while the commercial logic driving it stayed invisible to them.
MY ROLE
Design Lead
TIMELINE
1 month, joined mid-program
SCOPE
Referred in with no formal scope
I converged four partner types instead of building four products
I had experienced service providers who work in exports and expect to, novices who need a guided configurator, OEM partners on a distinct configuration path, and distributors submitting standard intake. Rather than segment the product, I converged all four on a single validated output before submission. Partners also cannot be shown the thresholds that determine their commercial motion, which ruled out the obvious progress-transparency patterns and made invisible routing a design constraint as much as a technical one.
I split intake rather than making AI the only door
AI-assisted configuration was proposed as the entry model for every path. For a novice that is real value. For an expert who already knows the part numbers it is a tax on a workflow that was working. I split intake into two paths instead: one with AI-assisted support for partners who want it, one preserving the existing way of working for partners who do not. The question was never whether AI belonged in this product, but where it earned its place and where it needed to get out of the way.
I found the scaling failure before it shipped
As specified, eligibility logic would have fired on every save and every line-item addition. I proposed consolidating to a single evaluation at the decision point. Engineering validated it and the quoting vendor's team reached the same conclusion independently. The change also fixed a business problem underneath it: discount eligibility had depended on someone internally noticing, or on a partner knowing enough to ask. Both paths now converge on one detection point, so a qualifying configuration gets flagged regardless of partner fluency, and routed to a human conversation. No pricing is ever displayed.
What I'd revisit
The partner relationship product did not exist as finished capability yet, so I turned the requirements into build inputs for that product team rather than a custom implementation. That was the right call, and I made it after the routing questions had already been answered. I would now run the product-team feasibility session before locking the routing model, so the model is shaped by what will actually ship.
In their words
“It was pivotal to have UX come in with an outside view and really focus on the journey and wireframing for partners, something technical folks and business analysts tend to lack, especially when it comes to portal workflow design. If we could redo the project, I'd support having UX resources involved from the beginning, to ensure a proper journey is designed and agreed upon before building out the solution.” - Project Owner