PRODUCT STRATEGY

BUILD IT INTO THE FLOW, NOT BESIDE IT

Choosing how to rebuild a quoting and contracting tool inside a platform that had grown apart.

Role:
Product Designer, sole designer on the platform
Company:
Intelisys, a ScanSource company
Sector:
B2B SaaS, telecom services distribution
Dates:
May to July 2026

THE PROBLEM SPACE

Our platform had a tool to build a quote. A separate tool to submit an order. A separate tool, not ours, to configure cable pricing and generate the contract, holding the packages, the commissions, and the special deals. And a dashboard where partners tracked their opportunities and orders.

None of it was connected. Between those pieces sat our own staff, working across a project management system and their email, hand carrying deals between partner and supplier.

The tool worked. It was also clunky, and it was not ours.

Between sixty and seventy percent of the traffic through that tool was our own staff, doing the work on behalf of partners who had emailed and asked them to. The tool was sold as a partner tool. Most of the hands on it were ours.

We had about a year to replace it. We had the technology to build it ourselves, and the actual prize was not the tool. It was the chance to take a disconnected chain and make it one task flow, for both the partners it was sold to and the staff who were actually running it.

The bucket matrix. Every capability from address entry through order submission assigned to a place it could live, with the pros, cons, and ruled-out reasons for each of four build options.

HOW WE DECIDED

I was asked to recommend how to implement it, weighing risk against development time.

I brought the assumption I had learned to bring. The appetite here for risk and for developer time had always been low, so I recommended the low-risk option: a new standalone tool. It could not break the quote flow for partners who do not sell cable, and it scoped cleanly. I built the analysis as a bucket matrix, every capability from address entry through order submission assigned to a place it could live, each placement carrying its pros, its cons, and the reasons an option was ruled out.

Putting that in front of the product manager surfaced the assumption rather than confirming it, and he told me this project was different. A year is a real runway, and this replacement mattered to the business in a way most projects did not. That combination unlocked things that were usually closed: access to staff and subject matter experts, room to run an actual process, and appetite for integrating the work into the product properly instead of standing another tool beside it.

Scope also narrowed in a way that helped. Phase one would cover a single supplier, the one carrying nearly all the traffic, with a new API from them freshly delivered to drive the contract process. That meant the capability had to appear only when it applied, which is progressive disclosure, and which a standalone tool cannot do.

So the scope grew, the time commitment grew, and the recommendation changed. We would weave the capability into the flows people already used, which meant the configurator arriving at the end of the quote flow and reachable again from the opportunities section of the dashboard. That also settled the staff question, because staff start from an opportunity record rather than from a tools page.

The matrix was not built to be right. It was built to find out what was actually possible, and it did.

The current state flow. Every screen and state in the tool being replaced, mapped before any decision about what would replace it.

WHAT THE SMEs GAVE US

The mapping got validated rather than assumed. Subject matter experts were in it through discovery and straight through the lo-fi reviews, and the sessions were rich in ways no amount of desk work would have produced.

The biggest finding was one nobody had named. Everything was entered twice. Quoting and contracting were separate acts, so a partner who got their customer to agree on a quote started over at zero to make it a contract. Resume from quote became the most requested improvement in the project, and it settled the architecture: the contract had to be built where the quote already lived.

The pricing configuration prototype, built in Figma Make and seeded with the platform CSS. Live pricing, promotions, and contract generation in one view.

WHERE AI CAME IN

Moving into mid and hi-fi, I built the prototype in Figma Make, seeded with our own CSS so it came out looking like our product rather than generic software.

It needed steering. Left alone it produced convoluted flows that broke our own style guide. What it bought was an interactive prototype early, which exposed flow problems a static mockup hides. One long-running argument settled here too, mobile first against a desktop and tablet user base, resolved with blocks that collapse into accordions and became the precedent for dense configuration at small sizes.

The style guide describes CSS, the front end is React in Storybook, and closing that distance needs design tokens a generator can work from. That is what turned this project into something larger than itself.

The configurator reached from the opportunity record, where staff already begin their work. Configure pricing and generate contract sit on each location rather than in a separate tool.

THE BRIDGE

This project became a bridge to a problem I had been working on for years.

I had a style guide, the CSS, and the Figma component library. The development team had Storybook and React components. The tokens were the thing that would join them.

The story ended before it really began. Three months in, and a week after that work started, I was laid off, and I never got to see how the project turned out.

What it did show was a real UX design process working with iteration, and AI brought into the build. It was my first go at design tokens and at putting AI into my own workflow, which I have kept studying and applying since.