# QRION showcase: stockout pipeline impact

> How a QRION workflow turns a low-stock event into an answer no single system holds: every open deal that contains the part, weighted by how soon it closes, scored by a versioned policy, and flagged on the deal with the reasons.

Source: https://co-worq.com/examples/stockout-pipeline-impact

QRION showcase · Data and record integrity

# A part runs low. Every deal it puts at risk is found, scored and flagged.

In most companies a low-stock alert reaches a planner and nothing else happens. Meanwhile a rep promises a delivery date on a deal that needs the part, and marketing keeps driving traffic to it. A stockout pipeline impact workflow connects the stock level to the deals it holds up.

QRION: Stock Out Pipeline Impact.A low-stock event on one part, traced to every open deal that contains it, scored by a versioned policy, and flagged on each deal with the reasons.

Transcript

This is QRION running one complete business process.

### Step 1: The exposure nobody sees

Stock on a part runs low. In most companies that is a planner getting an alert and nothing else happening at all. Everything that alert sets off downstream is where the money actually is, and almost nobody is looking at it.

Meanwhile a rep promises a delivery date on a deal containing that part. Marketing keeps spending on a campaign driving traffic to it. Customers place orders that will be backordered. The exposure is spread across three systems and visible in none of them, because answering the question means joining inventory to open pipeline to live campaign spend. No single system holds all three, so here the requirements document is the thing that builds the process.

### Step 2: Seventeen steps from the requirements

This is what the document became: 17 steps wired from the requirements themselves. An inventory event arrives and the process fans out: find the part in the CRM, find every open deal that contains it, and weigh what is at risk.

This is the one process in the suite that runs end to end without asking anybody anything. There is no decision to gate. Notifying a rep that their part is short is not a judgment call.

The same process as a list, every step in the order it runs. Read the level, check it against the threshold, resolve the part, query the pipeline, score the exposure and write the verdict back.

Note the first branch. If stock has come back up, the process reverses itself and clears the flags it set. A workflow that pauses things must know how to unpause them.

### Step 3: An explicit, versioned policy

The policy is explicit and versioned. Every exposed deal is weighted by how soon it closes. Inside two weeks counts in full. A quarter out counts for a fifth. The weighted total, the campaign burn, and whether a substitute exists produce a score and a priority band. The same figures that decide the band go into the tasks and go into the audit record. There is no second version of the arithmetic.

Published, listening to the store’s inventory events. No schedule to wait for. The level moves, the process runs.

### Step 4: A real part in a real store

Industrial sensor A100. Stock falls to four units against a threshold of 10. That movement is the trigger. Nobody files a ticket.

The run as it happens: below threshold, so the process resolves the part in the CRM and asks what it is holding up. Four open deals contain this part: $32,340 of pipeline, $25,800 of it weighted by closeness. That is the answer no single system had. Inventory did not know about the deals. The CRM did not know about the stock.

### Step 5: Scored, with reasons

The soonest of the four closes in nine days’ time. The policy scores it at 41 and bands it P2. And it says why in codes rather than prose: pipeline at risk and imminent close, no approved substitute on record, and no replenishment date. Four reasons, each of which a person can check. That is what makes the decision reviewable six months later.

There is a substitute part sitting on the shelf, but nothing in the CRM links it to this one. So the policy says no approved substitute rather than guessing. That gap is a configuration problem, and now it is a visible one.

### Step 6: Written back to every deal

And here is where it lands: every one of the four exposed deals now carries the band, the part that caused it, and the moment it was written. The owner of that deal opens it tomorrow and sees the risk, without anybody having to remember to tell them. Written by the process, not typed by a person, which is what makes it worth auditing.

One inventory event. Every exposed deal found, scored and flagged in the time it takes to read this sentence.

## What is a stockout pipeline impact workflow?

It is a governed process that starts when stock on a part falls below its threshold. It finds the part in the CRM (Salesforce in this example), finds every open deal that contains it, weights each deal by how soon it closes, and scores the exposure with a versioned policy. Each affected deal is flagged with the priority band, the part that caused it and the reasons, so the deal owner sees the risk without anybody having to tell them. If stock recovers, the workflow clears the flags it set.

Systems

Shopify inventory events in, Salesforce deals flagged

Policy

Explicit and versioned: close-date weighting, score, band and reason codes

People

None in the loop; every step recorded for audit

Showcase

QRION capabilities on demo data; not a customer result

Why the exposure stays hidden

## Three systems each hold part of the answer. None holds all of it.

- ### Inventory knows the stock

    It raises an alert for a planner, but it does not know which deals depend on the part.

- ### The CRM knows the deals

    Reps keep promising delivery dates because nothing tells them the part is short.

- ### Marketing knows the spend

    Campaigns keep driving traffic to a part that will be backordered.


The workflow

## One inventory event, every exposed deal flagged

The 17-step workflow was built from its requirements document. It listens to Shopify's inventory events, so there is no schedule to wait for: the level moves, the workflow runs.

1.  1

    System step

    ### Read the level

    An inventory event arrives and the level is checked against the threshold.

    Role

    Shopify

2.  2

    System step

    ### Resolve the part

    The part is found in the CRM. If stock has recovered, earlier flags are cleared instead.

    Role

    Salesforce

3.  3

    System step

    ### Query the pipeline

    Every open deal that contains the part, with its value and close date.

    Role

    Salesforce

4.  4

    System step

    ### Score the exposure

    A versioned policy weights each deal by close date and produces a score, a band and reasons.

    Role

    Pipeline-impact policy

5.  5

    System step

    ### Write the verdict back

    Each exposed deal carries the band, the part that caused it and when it was written.

    Role

    Salesforce


In the demo run, stock on one part fell to 4 units against a threshold of 10. Four open deals contained it: $32,340 of pipeline, $25,800 weighted by close date, the soonest closing in nine days. The policy scored it 41, band P2.

What this shows

## An answer no single system had, with reasons a person can check

A showcase of QRION's capabilities, run on demo data. It is not a customer result or a project estimate.

- ### Reasoning across systems

    Inventory joined to open pipeline in the time it takes to read a sentence, with no person needed.

- ### One version of the arithmetic

    The figures that decide the band are the ones on the deal and in the audit record. There is no second version.

- ### Reasons in codes, not prose

    Pipeline at risk, imminent close, no approved substitute, no replenishment date: each one checkable months later.

- ### Gaps made visible

    A substitute part was on the shelf but not linked in the CRM, so the policy said so rather than guessing.


Questions

## About this example

Is this a customer result or a project estimate?

No. It is a showcase of what QRION can do, run on demo data. It shows the capabilities a governed workflow uses; it is not a customer result, a project estimate or a forecast of return.

Why does nobody approve anything?

Because there is no decision to gate. Telling a rep that a part in their deal is short is not a judgment call, so this workflow runs end to end on its own. Every step is still recorded, and the score, band and reasons can be checked later.

How is the exposure scored?

By an explicit, versioned policy. Each exposed deal is weighted by how soon it closes: inside two weeks counts in full, a quarter out counts for a fifth. The weighted total, campaign spend on the part and whether an approved substitute exists produce a score and a priority band. The same figures go into the deal flags and the audit record.

What happens when stock comes back?

The workflow reverses itself and clears the flags it set. A workflow that flags things has to know how to unflag them.

Which systems does it use?

This example reads inventory events from Shopify and open deals from Salesforce, and writes the result back onto the deals in Salesforce. QRION works with more than 1,000 business systems, so the same pattern applies to other stacks.

## Which of your deals is waiting on a part that just ran low?

Bring one of your processes to a working session and see how QRION would run it.

[Book a working session](https://calendar.app.google/yF5awaB5GSSMDumE8)[See the golden record](https://co-worq.com/examples/golden-record)