Where AI Actually Works in Supply Chain Operations: A Field Guide for Mid-Market Operators

I have spent the last three years putting AI into real operations at manufacturers, logistics providers, and service companies. Not demos. Working systems that people rely on every day. The pattern is now clear enough to write down. A few use cases produce value fast and keep producing it. Everything else is a science project. Here is the field guide.

Where does AI create real value in operations today?

Three patterns account for most of the value I have seen. Each one has the same shape: high volume, repetitive judgment, and a clear place for the output to land.

1. Document-heavy back office work. At a $100M+ intermodal logistics provider, the accounting team was manually keying and coding a constant stream of carrier and vendor invoices tied to a 1,200-container fleet. I put AI in the middle of that flow. Invoices now get read, recorded, and assigned GL codes automatically, and anything the system is unsure about routes to a person. The team stopped keying and started reviewing. As a bonus, every coded invoice now lands in a data warehouse, which made lane-level profitability analysis possible for the first time.

2. Repeatable knowledge work, packaged as skills. A property management firm with 100,000+ residential units under management wanted to automate manual work without becoming dependent on a vendor or a consultant. I built reusable Claude Skills across 7 departments, covering document review, data entry, compliance reporting, and vendor coordination. The key word is reusable. Each skill is an asset the team owns, runs, and improves. When a new hire joins, the skill already knows how the company does the work.

3. Parsing messy inbound requests into structured work. A commercial landscaping company with 400+ field users on its operations platform receives work requests from property managers by email, in every format imaginable. Attachments, forwarded threads, three requests buried in one message. AI now parses those inbound emails into structured work orders inside the company's scheduling system. An office manager reviews and approves instead of retyping. The request gets to a crew faster, and nothing falls through the cracks of an inbox.

Notice what these three have in common. None of them asked AI to make a strategic decision. All of them asked it to do high-volume, well-defined work that humans were doing slowly, and to hand the result to a person or a system that could act on it.

What is a Claude Skill?

A Claude Skill is a packaged set of instructions, reference files, and examples that teaches Claude (Anthropic's AI model) to do a specific task your way, every time. Think of it as a standard operating procedure that the software actually follows. Instead of an employee writing a clever prompt from scratch each morning, the skill carries the company's rules, formats, and quality checks with it.

That distinction matters more than it sounds. When ten people prompt an AI tool ten different ways, you get ten different levels of quality and zero institutional memory. When the same ten people run one skill, you get consistent output, and every improvement to the skill improves everyone's work at once.

At the property manager I mentioned above, this is exactly how the program scaled to 7 departments. One skill reviews incoming documents against the company's compliance checklist. Another takes raw homeowner data from newly acquired communities and reshapes it for onboarding. A third drafts recurring reports in the house format. Each took days to build, not months, and the internal team maintains them without me.

For a mid-market operator, skills are the difference between "we bought AI licenses" and "we automated the work." The license is a tool. The skill is the process knowledge, captured and executable.

Where does AI NOT work yet?

This is the honest part of the field guide, because roughly half of what I see in the market is money spent on the failure modes below.

Pilots without owners. An AI pilot that belongs to everyone belongs to no one. The projects that survive have a named operator, someone with the time and the authority to review outputs, flag errors, and push for the next improvement. The projects that die had an enthusiastic kickoff, a vendor demo, and nobody whose job it was to care in week six. Before you approve a pilot, ask one question: who owns this on the first Monday after go-live?

Automating a broken process. AI is a fast learner, and it will faithfully learn your inconsistencies. If three people code invoices three different ways, automation gives you inconsistency at machine speed. At the intermodal provider, the automation worked because I tightened the coding logic with the client's team before automating it. Fix the process first, even if that takes two of your six project weeks. It is the cheapest part of the whole effort.

Chat without workflow. Giving everyone a chatbot license is not a transformation. It is a suggestion box. Real value shows up when AI output lands inside the system of record, a work order created, an invoice coded, a report drafted in the right folder, with a human review step where the stakes justify one. If the output of your AI initiative is text that someone copies and pastes, you have automated nothing.

I would also add a boundary: I do not let AI make unsupervised decisions that move money or commit the company. Approve a carrier invoice above a threshold, accept a proposal, change a customer commitment: those keep a human in the loop. The technology is improving fast, but in operations, trust is earned in production, one exception queue at a time.

How do you pick the first project?

Use four tests. A good first AI project passes all of them.

1. The rules fit in an hour. If your best person can explain how they do the task in a one-hour conversation, AI can probably learn it. If the explanation is "it depends" fifteen times, pick something else.
2. There is a measurable baseline. Hours per week, cost per invoice, days of cycle time. If you cannot measure the before, you will never prove the after, and the program will stall when budget season arrives.
3. It has a named owner. One person, with time carved out, who reviews the output and reports the numbers.
4. The output lands somewhere. A system, a queue, a file in the right place. Not a chat window.

Then keep the scope small on purpose: one process, one department. The property manager did not start with 7 departments. It started with one pilot, proved the numbers, and let the results recruit the next department. That sequencing is what makes the next department trust the rollout.