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.
