How to Forecast IT Spare-Parts Stock Levels with ChatGPT

The short answer: Export twelve months of stock-out records with dates, sites and part numbers, add supplier lead times and a criticality tier per part, and have ChatGPT run the reorder-point arithmetic on it rather than estimate in prose. You get defensible per-site reorder points in an afternoon. You do not get any warning about the failure you have not had yet.

Spare-parts stock is one of those problems everybody solves from memory. The field engineer knows the branch offices chew through power supplies. The ops manager knows the last time a switch died in Penang it took three weeks to replace. Between them they keep a mental model that works — until the person holding it takes leave, or the estate doubles, or someone in finance asks why there is a quarter of a million dollars sitting on shelves.

The arithmetic that would replace the mental model is not hard. It is standard inventory maths that any operations textbook covers. What stops teams doing it is that the data lives in stock-out exports nobody has ever aggregated, and the calculation has to be repeated per part, per site, which is exactly the kind of tedium that never reaches the top of anyone's week.

This is a good use of ChatGPT, with one important caveat that decides whether the output is worth anything — covered below.

The Two Ways Spare-Parts Stock Goes Wrong

They pull in opposite directions, which is why intuition handles them badly.

Dead capital. Parts bought for an estate you no longer run, models you have retired, or a panic order after one bad month. It is invisible on a P&L and obvious in a stock take: shelves of components with no consumption in eighteen months, some of them now unsupported by the vendor.

The part you did not have. A branch office is down, the replacement is a four-day courier away, and the SLA you sold is next-business-day. This is the expensive failure — not because of the part's price, but because of what the outage costs the client and what it costs you in credibility.

Teams overcorrect toward whichever one hurt most recently. A bad stock-out leads to over-ordering for a year; a stock-take write-off leads to running thin until the next outage. The point of doing the arithmetic is not precision for its own sake — it is to stop the pendulum.

What to Feed the Model — and What It Actually Computes

What data do you actually need?

Less than people expect, but it has to be the right shape.

Consumption history, per part, per site, with dates. Twelve months minimum, because seasonality and site-level differences are invisible in a shorter window. Your stock-out records are the source — every issue of a part against a ticket or a job. Quantity and date matter; the ticket text does not.

Supplier lead time, per part. Not the catalogue figure — your actual observed time from raising the order to the part being on the shelf, including customs if you move parts across borders in Asia. This is the single most under-recorded number in the whole exercise, and the one that most changes the answer.

A criticality tier, per part. Two or three tiers is enough. A part that takes a site down needs a service level that a cosmetic component does not, and without this the model will treat a laptop charger and a core switch power supply as the same problem.

Site context. Which sites exist, roughly how many devices at each, and whether a site can be served from a nearby hub within SLA. A part held centrally covers several sites; a part needed on-site within four hours does not.

That is the whole input. Notably absent: customer names, ticket descriptions, engineer names, pricing. Strip them — they add risk and contribute nothing to the calculation.

Why "ask ChatGPT for a reorder point" is a statistics question, not a prompt trick

Here is the caveat that decides the quality of everything downstream.

A reorder point is average demand over the lead time, plus safety stock sized to the variability of that demand and the service level you want to hold. That is arithmetic — and a language model asked to *estimate* it in prose will produce a plausible-looking number that is not the result of any calculation. It will be roughly right often enough to be dangerous.

The fix is to make the model write and run code rather than answer from its own reading. Upload the CSV and ask it to compute, per part and per site: mean demand over the lead-time window, the standard deviation of that demand, a safety stock for a stated service level, the resulting reorder point, and a suggested order quantity. Ask it to output the intermediate figures, not just the answer, and to state the assumptions it made about your data.

Two things follow from this, and both matter. You can check the working — the intermediate columns let a competent person confirm the maths is real rather than narrated. And you can change one assumption and re-run in seconds, which is where the actual insight lives: seeing what happens to your stock value when the target service level moves from 95% to 99% is more useful than any single recommended number.

Where the model earns its keep beyond the arithmetic is in the messy parts around it: reading your inconsistent part descriptions and grouping equivalents, spotting that one site's consumption tripled in March, flagging parts with too little history for the maths to mean anything.

A Worked Example — Twelve Months of Stock-Out Data Turned Into Per-Site Reorder Points

An MSP maintains hardware at 22 sites across three countries from one central store plus two regional hubs. The stock-out export is about 4,000 rows: date, site, part number, quantity, ticket reference. Lead times come from procurement as a separate sheet, and parts are tagged into three criticality tiers in an afternoon by the service manager.

The first pass is diagnostic, not prescriptive. Consumption by part shows the familiar shape: a small number of parts account for most movement, and a long tail of parts moved once or twice in a year. The long tail is the useful finding — for those parts, no forecast is meaningful, and the decision is a policy one (hold one as insurance, or accept the lead time) rather than a calculated one.

The reorder-point pass covers the parts that move. For each, mean demand over its own lead time, variability, safety stock at the tier's service level, reorder point, order quantity. Two results usually surprise people: the fast-moving cheap parts need less buffer than expected because their demand is steady, and a couple of slow-moving critical parts need more, because a long lead time multiplies even modest variability.

The site view changes the total. Aggregate demand across 22 sites and the numbers look comfortable; split them and the picture changes, because a part held centrally cannot meet a four-hour SLA at a site a day's travel away. The output that matters is not one reorder point per part but a decision per part about *where* it is held — and that decision is about your service commitments, not your consumption data.

The stock-value comparison closes it. Current holding against modelled holding, per tier. The realistic result is not a dramatic saving; it is a reallocation — less capital in the fast-moving items that were over-buffered, more in the handful of critical parts that were quietly under-covered.

AI-Assisted Forecasting vs a Stock Management System vs Engineer Intuition

• Time to a defensible number — AI-assisted forecasting wins. An afternoon against a system implementation, and it needs no new tooling.
• Handling inconsistent part descriptions and messy exports — AI-assisted forecasting wins clearly. Grouping "PSU 650W", "650w power supply" and a part code into one item is exactly what it is good at.
• **Explaining *why* a number is what it is** — AI-assisted forecasting wins, if you make it show the working. Intuition cannot explain itself to a CFO, and most systems just display a threshold.
• Knowing things the data does not contain — Engineer intuition wins, and this is not a small category: a site about to expand, a model reaching end of life, a supplier who is quietly unreliable.
• Keeping stock accurate day to day — A stock management system wins outright. A forecast sets a threshold; a system tracks the balance against it and tells you when you cross it.
• Acting on the answer without anyone remembering to — The system wins. Automated low-stock alerts tied to movements are the mechanism that turns a calculated reorder point into an order actually being placed.

The combination is the honest recommendation: forecast to set the thresholds, then hold them in something that watches stock levels continuously. A reorder point in a spreadsheet is a number nobody looks at.

Where the Forecast Breaks

Four places, and knowing them is most of using this well.

Parts with no history. New hardware has no consumption record, so the maths has nothing to work on. Use the vendor's failure-rate guidance and the behaviour of the model it replaced, and mark those figures as estimates rather than letting them sit in the same column as calculated ones.

End-of-life parts. Demand for a part on a platform you are retiring will fall — but availability falls faster, and the last-time-buy decision is a judgement about the retirement schedule, not a forecast.

One dominant site. If a single large site drives most consumption, the aggregate statistics describe that site and nothing else. Model it separately.

One bad batch. A firmware fault or a defective production run creates a demand spike that is not a pattern. Left in the history it inflates every subsequent recommendation. Ask for outliers to be identified and decide deliberately whether to exclude them — this is a judgement call, and it should be a conscious one.

Getting This Right — Operational Data, Supplier Terms, and When to Bring in IT

Three practical points.

Know what is in the export. Stock-out records usually carry ticket references, which can carry client names, site addresses and occasionally end-user names. For a forecast you need dates, part numbers, quantities and a site identifier. Strip everything else before the file leaves your environment, use a business or enterprise tier, and check that tier's current data-handling and training terms rather than assuming — consumer tiers commonly differ and terms change.

Supplier terms are commercially sensitive. Lead times and order quantities imply your negotiated position. That is not catastrophic to disclose, but it is worth deciding consciously rather than pasting a procurement sheet without looking at it. Substitute a supplier code for the supplier name and nothing is lost.

The forecast is the small half. Holding stock in the right places, moving it between hubs, reconciling what engineers actually consumed against what was issued, and placing orders before the alert becomes an outage is the operational work — and it is what our AI+ support practice and managed IT support exist to carry. Brocent has run managed IT across Asia since our founding in Beijing in 2007, with headquarters in Singapore and a Hong Kong office since 2016. What this looks like when it is run as a managed service, rather than as an analysis you repeat yourself, is covered in our guide to spare-parts management and hardware maintenance in Asia.

Frequently Asked Questions

How much consumption history do we need before a forecast means anything?

Twelve months is the practical minimum, because it captures seasonality and lets you see whether variability is real or an artefact of a short window. Six months can support a rough tier-level view. Below that you are pattern-matching on noise, and you are better off using vendor failure rates and stating plainly that the numbers are estimates.

Can this handle parts with a twelve-week lead time?

Yes, and long lead times are where the arithmetic helps most — variability compounds over the lead-time window, so a long lead time on an otherwise modest part can justify surprisingly high safety stock. The bigger constraint is commercial: covering a twelve-week lead time properly may cost more in held capital than the risk warrants, and that trade-off is a decision, not a calculation.

Should the AI place the order?

No. Have it produce the recommendation and the reasoning, and keep a person on the approval. Ordering commits money against supplier terms and depends on context the model does not have — a contract ending, a site closing, a platform being replaced. Automate the *alert*, not the purchase.

What about parts we have never consumed?

They fall outside the forecast by definition. Treat them as an insurance decision: what does this part protect, what does the outage cost, and what does holding one cost? Some are obviously worth stocking and some obviously are not, and the model can frame the question but cannot answer it for you.

Does this work across multiple countries?

The arithmetic does, per site. What changes across borders is lead time — customs clearance, import duties and restricted-item handling can add more variability than the supplier's own dispatch time. Use observed door-to-door times per country rather than one global figure, or your safety stock will be wrong in both directions at once.

Do we still need a stock system if we do this?

The forecast tells you what the thresholds should be; it does not know your current balance, and it will not tell anyone when you cross one. A system that records stock-in and stock-out against tickets, holds balances per location and raises low-stock alerts is what turns the numbers into behaviour. The forecast sets the target; the system holds you to it.

Where to Start

Take one criticality tier — the parts that take a site down — and run the calculation for those alone. It is a short list, the data is manageable, and it answers the question that actually matters: are you carrying the right buffer on the parts where being wrong is expensive? If the answer turns out to be that the numbers are fine but nothing tells you when you cross them, that is an operational gap rather than an analytical one — get in touch.