From Sales Request to Quote: Putting Commercial Intelligence Inside the Workflow

A salesperson receives a request for a part. At first glance, that sounds like a simple workflow: record who wants it, what they want, perhaps add a note or two, and save the request. Sometimes that is exactly what should happen.

But sometimes we already have the item. The moment we know that, the workflow changes. The salesperson is no longer simply recording demand; there is an opportunity to quote the item, and that introduces a much harder question: what should we charge for it?

We recently rebuilt this workflow in Uniti. What began as a relatively small improvement to creating sales requests ultimately became an interesting exercise in how we think about software at Simplexable: put substantial intelligence underneath the workflow, but be exceptionally careful about how much of that complexity reaches the person using it.

The result is a request-to-quote pipeline that can consider inventory, market activity, realized sales, customer precedent, inventory age and source economics—and ultimately present the salesperson with something as simple as $6,000–$7,000 exchange and $14,900–$17,500 outright.

That simplicity took some work.

Start with the workflow that already exists

The first rule was not to turn every sales request into a quoting workflow. In the example above, the requested item is out of stock, and Uniti says so prominently. That information matters because a salesperson shouldn't have to leave the request, search inventory, discover there is nothing available, and then return to finish what they were doing.

But there is also no reason to introduce pricing controls for an item we cannot currently sell, so we don't. The request remains a request.

This sounds obvious, but it reflects an important design principle: knowing more doesn't obligate software to show more. A system may have enormous amounts of information about an item. The interface should expose that information because it helps with the decision being made now—not merely because the information exists.

Inventory changes the problem

The second example looks almost identical, except this time Uniti finds three sellable units. That one fact materially changes the commercial situation, so we show the available inventory directly in the request, including the individual units, their condition, and how recently their condition was verified.

The salesperson now knows that this isn't merely demand to be recorded. We have something that can potentially satisfy it, so the workflow offers another action: quote this item.

There is no trip to another module. There is no need to save the request, navigate to Quotes, create a quote, search for the customer again, find the item again, and reconstruct the context that was already sitting in front of us. The quote is a natural consequence of the request, so we let the salesperson create it there.

A sub-workflow, not another application

Checking quote this item reveals a deliberately small set of controls. The salesperson can create a new quote or add the item to an existing active quote. We provide exchange and outright prices and construct the item description automatically. That's essentially it.

This is one of those places where software can easily become impressed with itself. We could have opened a full quote editor. We could have exposed customer history, inventory statistics, sales history, margins, requests, sourcing information and a dozen other things that might conceivably matter. Instead, we asked what the salesperson actually needs to complete this particular step, and the answer was surprisingly small.

The difficult part wasn't getting more information onto the screen. We already had plenty of information. The difficult part was deciding how much of it the salesperson should have to think about.

Then we reached the uncomfortable question: what is the price?

Putting an exchange and outright field on a form is easy. Deciding what belongs in those fields is not. For many specialized parts, there isn't a tidy retail price waiting in a catalog. The commercially appropriate price has to be inferred from a collection of imperfect signals.

What have we quoted this SKU for recently? What prices have customers actually paid? How much current interest is there? Do we have one unit or ten, and how long have those units been sitting there? Has this particular customer requested the item before, and did those requests convert? What do we have invested in the inventory?

Just as importantly, which of those things are evidence of market price, and which are merely context? A quote tells us somebody offered a price; it doesn't tell us a customer paid it. A request tells us somebody wanted an item; it doesn't prove strong commercial demand. An old sale is real commercial evidence, but it may be a poor description of today's market. Three aging units sitting on a shelf create pressure to sell, but they don't magically calculate a 17.3% discount.

This is where the project stopped being primarily a form-design exercise. We needed a pricing decision system.

We didn't build an AI price generator

The easy version of this feature would have been to collect a pile of data, hand it to a model, and ask, What should we charge? We didn't want that. A plausible number isn't enough. We wanted the system to preserve the distinction between what we know, what we can reasonably infer, and what is simply policy.

So the pricing-assistance layer builds a correlated commercial decision set. It considers signals including recent quote history, realized sales, request activity, available inventory, inventory age and movement, customer-specific precedent, and source economics. More importantly, those signals are considered together rather than treated as a collection of independent scorecards.

That matters when the signals disagree. Strong request activity might suggest demand while weak realized sales suggest something different. Several aging units create downward pricing pressure, while unrecovered acquisition economics create pressure in the opposite direction. There is no intellectually honest reason to pretend those observations always collapse into one objectively correct number.

Sometimes the right answer is a range.

The recommendation is small. The reasoning isn't.

For this item, the result is $6,000–$7,000 exchange and $14,900–$17,500 outright. That is what we want the salesperson to see first—not seventeen metrics, not a dashboard, and not a paragraph generated by an AI explaining itself. Two commercially useful ranges.

Underneath them is a simple show details control. This is progressive disclosure doing actual work rather than merely cleaning up a screen. The application has considerably more to say, but it waits until somebody asks.

Show the reasons that can change the decision

Opening the first level gives the salesperson a compact explanation. Recent quoting supports a $7,000–$7,500 exchange neighborhood, but there is no realized sale within 180 days. Market interest is strong while realized commercial performance is weak. Three sellable units and weak movement create high inventory exposure, with aging inventory adding downward pressure. Recent requests from this customer have not converted, while source economics argue for protecting value. Older realized prices remain historical context rather than setting today's recommendation.

That's enough for most decisions, and more importantly, those aren't arbitrary reasons selected to make a recommendation sound convincing. They expose the tensions in the evidence. There is market interest but weak realized performance. There is inventory pressure but also an economic reason to protect value. Recent quoting provides a useful neighborhood but isn't presented as a realized market price.

We think that qualification is important. Software that advises people should be allowed to say that the evidence is mixed.

And make the evidence available when somebody really wants it

There is another disclosure level: deep-dive. This is intentionally not the default experience. Here we expose the underlying commercial analysis in considerably greater detail: the recommendation, pricing context, market interest, realized commercial performance, inventory exposure, customer precedent, economics, competing pricing pressures, outright-price methodology, and limitations.

The limitations may be the most important part. For example, the system explicitly identifies that no qualifying recent realized sale exists rather than manufacturing a current realized market band from older history. It distinguishes quote activity from completed sales. If an outright recommendation depends on our 2.5× exchange-price policy because there is insufficient recent outright evidence, it says so.

Policy is labeled as policy. It isn't quietly presented as market evidence.

We are comfortable with software making inferences. We are much less comfortable with software becoming more certain as its evidence gets worse.

The software can advise. The salesperson still decides.

Pricing guidance provides useful starting values, but it doesn't take ownership of the transaction away from the salesperson. The prices remain editable, and once edited they remain ordinary application data subject to ordinary deterministic validation. Required values are required. An outright price cannot accidentally violate the commercial relationship we require between outright and exchange pricing. The interface clearly distinguishes ready from not ready.

That separation is deliberate. We use intelligence to help answer a fuzzy commercial question, and conventional software to enforce rules that aren't fuzzy at all. There is no benefit in asking an AI whether a required field is empty.

The finished workflow should look almost boring

This is my favorite screenshot of the project, not because it is visually dramatic, but because it isn't. After everything underneath—the inventory observations, quote history, realized commercial activity, customer precedent, aging analysis, source economics, correlation, policy, inference and explanation—the operational interface is essentially a checkbox, two recommended price ranges, three fields, and a button.

That's the point. Complex systems don't have to produce complex interfaces. In fact, we increasingly think the opposite should be the goal. The more work the software can do to assemble context, distinguish strong evidence from weak evidence, identify contradictions, and put the result at exactly the point where a decision is being made, the less work we should require from the person using it.

The intelligence belongs underneath the workflow. The decision belongs inside it.

What we were actually building

It would be easy to describe this project as an AI pricing feature, but that description misses most of what interests us about it. We were building a connection between two things enterprise software often separates.

One is the transactional system: create the request, select the customer, quote the item, enter the price. The other is the analytical system: study inventory, investigate history, compare activity, understand economics, and decide what the data means.

Traditionally, we make people move between those worlds themselves. Open another screen. Run a report. Look up the SKU. Remember a number. Go back to the transaction. Enter it. Every one of those transitions asks the user to become the integration layer.

We think the software should do more of that work, but not by dumping the analytical application into the transactional one, and not by hiding everything behind a magical AI button. Instead, we can bring the smallest useful conclusion from the analytical system directly to the point of action, preserve access to the reasoning behind it, and let the user decide how far down they need to go.

For this workflow, that ultimately meant two numbers: $6,000–$7,000 exchange and $14,900–$17,500 outright.

Everything else is there when you need it—and almost nothing else is there when you don't.