How a price approval screen becomes a decision system

Most “decision system” discussions stay abstract. This article will proceed through a concrete example: a price approval screen. Because this most ordinary-looking screen, designed well, contains all the elements of a decision system.

The starting point is familiar. A sales rep wants to give a customer a non-standard price or discount. This requires approval. In most companies, this approval runs over email: the rep writes, the manager says “approved,” the decision is made.

This is not an approval but a gap. Which price, on what rationale, with what margin impact, against which alternatives was it approved? None of it is recorded. Six months later, there is no trail of this decision.

Now let us turn this simple approval, step by step, into a decision system. Each step is the concrete counterpart of an abstract “decision system” principle.

Step 1: Bringing context to the screen

The first transformation is bringing the right context in front of the person making the decision.

In email approval, the manager usually sees only the requested price. They have to look up the context the decision needs themselves: what is the current price? What will the margin be? What did we give this customer before? Where is the competitor?

A decision system brings this context to the moment of approval. The screen shows, along with the requested price, the current price, the margin impact, the customer’s past terms, their volume and, if available, the competitor price. The decision-maker no longer searches; they compare.

This is the first concrete form of the “not a report, but a decision system” principle: information is moved to where the decision is made.

Step 2: Defining thresholds

The second transformation is no longer putting every approval in the same basket.

Not all price exceptions are at the same risk level. A 2 percent discount and a 30 percent discount do not deserve the same approval process. A small flexibility for a standard customer and a large concession for a strategic customer cannot be handled with the same attention.

A decision system defines thresholds. Exceptions below a certain limit are approved automatically or pass in one step. Those above a certain threshold go to a higher approval. If margin falls below a certain level, the system produces an additional alert.

This way, the approval burden becomes proportional to the risk of the decision. Low-risk decisions speed up, high-risk decisions slow down and are reviewed properly.

Step 3: Offering recommendations and alternatives

The third transformation is the system not only showing the requested price but offering options.

A good price approval system goes beyond “do you approve this price?” It can show the recommended price range, alternative scenarios (for example, a better margin with a smaller discount) and the impact of each option.

This enriches the decision. The manager does not just say yes or no; they choose in a decision space. Perhaps, instead of approving the requested 20 percent, they counter-offer 12 percent.

Here AI can play a meaningful role too: finding similar past decisions, calculating margin impact, flagging risky points. But the final approval stays with the human.

Step 4: Recording the rationale

The fourth transformation is capturing the rationale of the decision.

When approval is given, a short rationale field captures the “why” of the decision. Competitive pressure? Protecting a strategic customer? In exchange for a volume commitment? Even as a single sentence, this makes the decision’s context permanent.

This is the decision trail itself. Six months later, the question “why did we give this customer this price?” is not searched in the email archive; it is seen in the approval record in seconds.

The rationale also enables learning. Which kinds of rationales for discounts worked, and which only cost margin? This produces better pricing policy over time.

Step 5: Tracking the outcome

The fifth and final transformation is tracking the outcome of the decision.

After the approved price is applied, what happened? Did customer volume rise? Did the expected commitment come? Did the margin estimate hold? Most approval systems stop here — the decision is made and forgotten.

A decision system closes the outcome. It compares the result of the approved exception with the expectation. This way, the system does not only make decisions; it learns from the decisions it makes.

When these five steps are complete, an ordinary approval screen is no longer a form. It is a decision system that contains context, thresholds, recommendations, rationale and outcome tracking.

Closing

Even the most ordinary-looking screen — a price approval — contains, when designed well, all the elements of a decision system. An “approved” reply in email is a gap with no trail and no context. The same decision, equipped with context, thresholds, recommendations, rationale and outcome tracking, becomes a process that is faster, more consistent and learns.

The important thing is that these five steps are not specific to price approval. The same structure applies to almost any recurring decision, from a stock action to a campaign approval, from a budget line decision to a customer term.

The right question is:

Are our approvals just a “yes/no” reply, or a decision system that carries context, rationale and outcome?