How to Set Stock Alert Thresholds for Critical MPNs

Direct answer

Set a stock alert threshold from the quantity and time the build needs, not from a generic number. Define required quantity, safety stock, lead-time buffer, supplier scope, freshness, and escalation owner. Keep separate alerts for low stock, no stock, stale evidence, and connector failure.

Why one threshold is not enough

“Alert when stock is below 100” may work for one line and fail for another. A prototype may need 10 pieces; a production run may need thousands. A part with a long replenishment signal needs more protection than a commodity item that can arrive tomorrow.

The threshold should answer a business question: “When should a human review supply before the build is at risk?” It is not a claim that the supplier will reserve inventory.

Use MPNRadar for the monitoring record and unknown stock is not out of stock to keep missing evidence separate from an explicit zero.

Define the criticality first

Classify the BOM line before choosing a number:

Criticality belongs to the design and supply context, not to the part family name. The same MPN can be routine in one product and blocking in another.

Calculate the quantity threshold

Start with a transparent model:

``text quantity threshold = demand during replenishment window + approved safety stock + receiving or qualification buffer ``

For a simple planning view:

``text demand during replenishment window = usage per build * builds expected during the window ``

The inputs are internal assumptions. Record their date and owner. Do not present the result as a supplier guarantee.

Example

Suppose a line uses 20 pieces per build, the plan has 30 builds before the next viable supply, and the team has approved 100 pieces of safety stock. The planning threshold is 700 pieces before any source-specific adjustments. If the observation is stale or the quantity is not confirmed for the required package, the alert should remain open even when the displayed number is higher.

Add a time threshold

Quantity alone can hide danger. Track:

• the latest acceptable arrival date;
• receiving and inspection time;
• supplier or manufacturer estimate type;
• source freshness limit; and
• time needed to qualify an alternate.

A part above the quantity threshold may still be risky when the source cannot ship within the build window. Read lead-time monitoring for an event-based approach to dates.

Use source-specific thresholds

Do not combine all supplier results into a single global quantity without checking semantics. Store:

``text source: region: availableQuantity: expectedQuantity: requestedQuantity: observedAt: freshUntil: ``

One source may report warehouse quantity; another may report a regional total or a future delivery. Normalize distributor inventory data shows how to keep these meanings visible.

Make the alert states distinct

Use separate states:

``text LOW_STOCK fresh quantity below policy NO_STOCK source explicitly reports zero or unavailable STALE last valid observation is too old UNKNOWN response cannot support a conclusion CONNECTOR_ERROR request or parser failed ``

The first two are supply signals. The last three are evidence or operational signals. Evidence-first monitoring describes why they should not be merged.

Add hysteresis to avoid alert flapping

If a quantity moves around a threshold, the system can notify repeatedly. Use a small gap or a confirmation count:

``text open alert below: 700 close alert above: 850 or close after: two fresh observations above threshold ``

Choose values with the supply owner. Do not use hysteresis to hide a rapidly falling stock position; show the movement in the observation history.

Escalation should match the risk

Include these fields in an alert:

• exact manufacturer and MPN;
• source and region;
• current and prior quantity;
• requested quantity and threshold;
• observation time and freshness state;
• current lead-time signal;
• design or buyer owner; and
• next decision date.

The first message may go to procurement. A blocking line may also need engineering, quality, and production planning. The system should create a task, not just a red color.

Review thresholds when the plan changes

Recalculate when:

• forecast volume changes;
• build dates move;
• safety stock is approved or released;
• an alternate is qualified;
• a supplier region changes; or
• the source's freshness or semantics change.

Keep the prior threshold with its effective date. A historical alert should be evaluated against the rule that was active when it fired.

Test the rule before enabling it

Use replayed observations or a disposable test set:

1. fresh quantity above threshold;
2. fresh quantity below threshold;
3. explicit zero;
4. stale last observation;
5. unknown response;
6. connector failure; and
7. quantity recovery above the close threshold.

Verify that each state produces the intended task and that recovery does not erase the evidence that caused the alert.

Questions procurement teams ask

Is a fixed stock threshold bad?

Not always. It can be a useful first rule for a stable, low-risk item. Add demand and time context for critical MPNs.

Should expected stock count toward the threshold?

Keep it separate. A policy may consider future stock, but it should not confuse expected quantity with available quantity.

Does an alert mean I should place an order?

No. It means a review is needed. Verify identity, source, price, delivery, quality, and authorization before purchasing.

Final review

A threshold is ready when a buyer can explain where the number came from, what source and region it applies to, how fresh the evidence must be, and who acts when it fires. Keep stock, evidence, and connector states separate so the alert says what is actually known.

MPNRadar supports monitoring and evidence organization; it does not guarantee stock, allocation, price, or delivery. Confirm the current source before ordering. Continue with BOM monitoring without false alerts, validate a distributor result before you buy, and MPNRadar pricing.

Use a threshold worksheet

For every critical line, record the assumptions behind the threshold:

``text Build or forecast version: Usage per finished unit: Expected units during the replenishment window: Approved safety stock: Receiving and qualification buffer: Approved supplier and region: Source freshness limit: Threshold owner: Effective date: ``

This worksheet makes a threshold portable between planning cycles. If the forecast changes, the owner can update the inputs rather than adjusting the final number by instinct. Keep an old worksheet with the alert history it produced.

Add a coverage rule

Some teams count only current available quantity. Others may count a confirmed allocation or a supplier quote. Make the rule explicit:

``text coverage = available now + approved allocation + acceptable future quantity ``

The terms must define what each component means. Expected stock should not be added to available quantity merely because both are numbers. If a future quantity is allowed, it needs a date and an owner who confirms that the date still meets the build plan.

Example: two lines, two thresholds

Line A uses one low-cost resistor per unit, has several approved sources, and has a short replenishment window. Its threshold can be tied to near-term demand and a modest buffer. Line B is a processor with no qualified alternate, a long engineering review, and a fixed production date. Its threshold should include the time needed to react, not just the quantity needed for the next build.

The example is not a universal formula. It shows why a single company-wide number creates either noise for routine items or late warnings for blocking items.

Review threshold ownership

Procurement can own source quantity and supplier evidence. Planning can own forecast demand. Engineering can own criticality and alternate timing. One person should coordinate the final threshold, but changes should identify the role that supplied each input.

When a threshold is changed, record whether the change came from demand, source semantics, a new alternate, a build-date change, or a policy decision. This prevents a later review from mistaking a business-policy change for a supply recovery.

Include coverage confidence in the alert

The threshold is only as useful as the coverage behind it. Add a coverage field:

``text critical MPNs expected: [count] critical MPNs with fresh valid observations: [count] sources currently healthy: [count] items requiring manual review: [count] ``

If the monitor checked only half the watch list, a green summary can be misleading. Show the coverage beside the inventory result and escalate when the missing set includes a blocking part.

Distinguish absolute and percentage rules

An absolute threshold works well when demand is stable. A percentage rule can help when usage varies:

``text alert when available quantity < next build requirement + buffer or when available coverage < [approved number] days of demand ``

The rule still needs a demand date and a source definition. Percentage coverage based on an old forecast can create the same noise as a fixed number. Recalculate when production volume or need date changes.

Use a two-step escalation

The first alert can ask a buyer to confirm the source and quantity. A second escalation can involve engineering and planning when the item remains below threshold or the build window is breached. This keeps ordinary fluctuations from paging every stakeholder while ensuring that a persistent shortage does not become background noise.

If the source is DigiKey, compare the threshold fields with the current Product Information V4 search documentation before treating a returned quantity as an available-stock fact.

Audience and limitations

This article applies to procurement, engineering, and operations teams monitoring electronic components. It does not promise supplier accuracy, stock, price, delivery, lifecycle status, equivalence, or any specific business outcome; current source evidence and internal approvals remain the authority.