ChatGPT and LLMs for Supply Chain Management: 7 Use Cases That Work in Production
Seven LLM use cases I have deployed in logistics operations since 2023, what each delivers, and the three places where the model is the wrong tool.
A large language model does two things: it reads text and it writes text.
Everything useful it does inside a supply chain is one of four moves built on top of that, and knowing which move you are asking for is the difference between a pilot that ships and one that gets cancelled.
It can read a document a person used to read, it can classify what it read, it can draft a message or a report from structured data, and it can answer a question by translating plain English into a query.
Since November 2023, when I connected a GPT model to a shipment database for the first time, I have built and deployed each of those four moves for logistics operations, and I have also watched several fail.
Gartner's own forecast is that over 40% of agentic AI projects will be cancelled before the end of 2027.
The pattern behind the failures is consistent: teams evaluate an LLM the way they evaluate a forecasting model, and 80% accuracy sounds like a strong result.
In a warehouse it is not, because the 20% is where the penalties live, and nobody accepts a tool that gets one order in five wrong.
In this article, I will go through seven use cases I have built for supply chain management, from a control tower you can question in plain English to a voice interface for cycle counting.
For each one I will state what the model does, what it produced, and where it stops.
The scenario: a fashion retailer's distribution chain
Take an international clothing group with a global store network, shipping from warehouses to stores through a chain of steps that each carry a timestamp.
The order is transmitted before a cut-off, the truck is loaded, it reaches the airport, the aircraft lands, and a second truck reaches the city before the store opens.
Each step has a flag, and a shipment is late if any one of them is missed.
The operational questions are simple to state and slow to answer, because they need a query written against that table every time somebody asks.
How many shipments were delivered late in the first seven days of May?
The right answer, on the dataset I used, is 6,816 shipments.
Before an LLM, that answer lived in a control tower dashboard built with Python, refreshed on a schedule, and any question the dashboard did not anticipate went back to an analyst.
That waiting analyst is the bottleneck every use case below removes, in one form or another.
Seven use cases, and what each one actually delivers
1. A control tower you can question in plain English
The first thing I built was a LangChain SQL agent connected to that shipment database.
The agent receives the question, writes the SQL, runs it, reads the result and answers in a sentence, and on the delayed-shipments question it returned 6,816 after some prompt work to stop it inventing column names.
I wrote up the LangChain experiments, then rebuilt the same agent in n8n with no code: a chat interface, a language model node, a memory node for the conversation, and a tool node that executes the query.
What it delivers: the analyst stops being a queue.
Where it stops: the agent answers what the data contains and nothing more, so a question about why a route is late gets a count, not a diagnosis.
2. Reading emails into structured orders
A logistics company was receiving purchase orders as plain emails, with the order number, the delivery date, the references and the quantities written in the body, and somebody retyped each one into the system.
The workflow now picks up the email, hands the body to an agent that extracts the four fields, reshapes them into one row per product, and writes them into the sheet the team already uses.
Nobody built an integration, and the customer never noticed anything changed, which is the whole argument for automating around the tools people already have.
What it delivers: the retyping stops existing, and the customer keeps sending exactly the same email.
Where it stops: see use case seven, because a reading step that is wrong on a formatted document is a different problem from one that is wrong on prose.
3. Running an optimisation model from an email
Planners in User Acceptance Tests ask the same thing every time: can we receive the results by email?
Take a production planning problem, where the trade-off is between setup costs of around $500 per batch and holding costs of around $1 per unit per month.
I wrapped the optimiser in a FastAPI service and put two agents in front of it with n8n.
The commercial team emails the demand file as an attachment, with the parameters in the body.
The first agent reads the parameters into JSON, the second agent calls the API, and the optimal plan comes back to the sender by email.
What it delivers: a working model that people actually use, because using it means sending an email rather than opening another application.
Where it stops: the model does the optimising, and the agent only carries the request, which is exactly the division of labour that keeps the answer correct.
4. Filtering a hundred documents a week down to four a day
We monitor European legislation for our sustainability work, and the first automation scraped the parliament's legislative observatory every day and sent every item to our legal expert.
It worked perfectly, which was the problem, because she was receiving well over a hundred documents a week, and the reading was still entirely hers.
The fix was a reading agent in front of her, which takes the title, the description and the committee of every item and answers one question: is this related to sustainability?
Only the ones that pass become tasks on her list, with the reference and the link already attached.
On the day I recorded it, twenty-one items came in and four came out.
The same shape produces a curated sustainability newsletter and a compliance report summariser, and none of them decides anything, they all read.
What it delivers: the expert reads four things instead of twenty-one, and every one of the four is worth her time.
Where it stops: it is allowed to be wrong, because a person is still looking at what comes through, and a wrong pass costs her one minute.
5. A custom GPT that runs ABC and Pareto analysis
When OpenAI opened custom GPTs, I built The Supply Chain Analyst: upload a CSV of sales transactions by SKU and day, pick a metric, and it returns the Pareto chart, the ABC classes and a written interpretation.
It attracted more than a thousand users, mostly supply chain professionals with a dataset and no Python.
What it delivers: an analysis that used to need a notebook, delivered through a chat window, with the model writing the commentary around numbers the code produced.
Where it stops: the arithmetic is done by code the GPT calls, not by the model, and that is why the classes are right.
6. Voice on the warehouse floor
Cycle counting in most warehouses is a printed sheet, an operator walking the aisles, and a walk back to a computer to type the corrections.
I replaced the paper with a voice workflow, where the operator speaks the count at the location and an agent records it, and the ElevenLabs build removed the walk that carried no information.
What it delivers: productivity rose about 30% and recording errors fell by about 60%, because the count is entered once, by the person who did it, at the moment they did it.
Where it stops: the model transcribes and structures, and the warehouse system still owns the stock figure.
7. Monitoring the automations themselves
Once you run more than a hundred workflows, the failure mode changes: an automation that stops does not complain, it goes silent, and the alert system becomes a customer typing "I have not received anything for the last five hours".
So I built an assistant that reads the execution logs and finds the failures before the customer does, which turns a twenty-minute search through a hundred workflows into a question.
What it delivers: reliability that lives in what the customer believes, which is the part of reliability nobody puts in the architecture diagram.
Where it stops: it finds and explains, and a person still fixes.
The three places where the model is the wrong tool
When the input is already structured
A small factory in Southeast Asia receives orders by EDI, a machine format, and wanted an AI step that reads any dialect of it.
I built it, and on a proper test set it parsed 75% of the messages correctly, which is a strong result for a language model and a useless one for an order intake.
I replaced the AI step with one parser per format, more than ten of them written in about an hour and a half with a coding assistant, and the same test set came back at 100%.
An LLM reads prose. A parser reads formats. Do not pay a probabilistic tool to do a deterministic job.
When there is no one at the end
Every use case above that survived has a person downstream, and the ones with the most forgiving economics are the reading steps, where a wrong answer costs a minute.
An agent that decides, that releases an order or changes a plan, has no such safety net, and being wrong is expensive and discovered late.
That is not a reason never to build one, it is a reason to start with the reading steps and earn the right to the deciding ones.
When 80% is the benchmark
People evaluate AI pilots the way they evaluate a machine learning model, and 80% sounds like a good number until you are the factory director explaining the other 20% to a customer with penalties in the contract.
Handling the exceptions is most of the job in an operation, and a spreadsheet survives precisely because it absorbs the exception.
A mandated tool that cannot absorb the exception does not get adopted, it gets worked around.
How to start, in an afternoon
Pick one task on your team that is reading, not deciding: an inbox somebody triages, a report somebody summarises, a document stream somebody filters.
Count it first, because the ratio of what arrives to what matters is the whole business case, and if a hundred things arrive and four matter, the case writes itself.
Build the reading step in front of the person, not instead of them, with n8n if nobody on the team writes code, and measure what reaches them a week later.
Then, and only then, connect it to a model that computes something, the way the budget planning agent connects a conversation to a linear programme, so the model does the arithmetic and the LLM does the reading and the writing.
Conclusion
Seven use cases, and every one that works keeps the same division: the language model reads, classifies, drafts or answers, and something else decides or computes.
What we covered in this article
A control tower questioned in plain English, orders read out of emails, an optimiser driven by email, a legal document filter, a custom GPT for ABC analysis, voice cycle counting, and an assistant that watches the other automations.
Three cases where the model is the wrong tool: structured input, no person downstream, and an 80% benchmark.
What comes next
The agents that survive are being deployed into simulations before they meet real operations, which is how I let an agent monitor a live supply chain simulation across eight routes before a customer saw it.
If you want the concepts before the builds, start with what supply chain analytics is, because an LLM in front of bad data is a faster way to get the wrong answer.
Related videos
The videos behind this article, already on the channel:
- You Do Not Need an Agent: You Need One Working Workflow
- You Email a Spreadsheet: You Get an Optimal Production Plan Back
- This AI Agent Reads Every EU Sustainability Debate for You
- Create your AI Agent to Automate Logistics Workflows with n8n
- I Deleted the AI and the Automation Started Working
The ones coming next, with the date each goes public:
- They Loved the AI Agents: Two Weeks Later, Nobody Used Them, 21 September 2026
- Your AI Project Is Sitting on Five Systems That Don't Talk, 12 October 2026
- HTS Codes Explained: How to Legally Save Millions in Import Duties with AI, 19 October 2026
About Me
Let's connect on LinkedIn and Twitter. I am a Supply Chain Engineer who is using data analytics to improve logistics operations and reduce costs.