AI Tools for Operations Management: Weekly Exceptions Report From Exports

Export orders, delivery or delay records, and costs from your systems as three spreadsheets, upload them to ChatGPT or Claude with a written rule for each exception, and ask for a list of items that break a rule. Then check the joins and one figure by hand before you act on the list.

The advantage over a dashboard is that the rules are yours, written in plain words and changed in a minute. The risk is that three exports from three systems rarely line up cleanly, and a join on the wrong field gives a tidy list that is simply wrong. That is why the join checks deserve as much of your time as the prompt.

Follow me on Instagram@sagnikteaches

The review as a decision list, not a report

Start from the decisions you make on a Monday morning, not from the data you have. A manager of a wholesale distributor, for instance, wants to know five things: which orders will miss their promised date, which suppliers are late repeatedly, which orders shipped at a loss after freight, which customers have changed their ordering pattern, and where costs are running over what was budgeted. Each of those is a rule the assistant can apply, and each ends in an action: call the customer, chase the supplier, reprice a lane, ring the account owner, challenge the spend.

Connect on LinkedInSagnik Bhattacharya

Write the rules first, in one table, before you export anything.

Subscribe on YouTube@sagnikteaches

The thresholds (2 days, 3 in 4 weeks, 8%, 15%) are placeholders that suit an illustrative distributor. Replace them with figures from your own history. If you do not know what is normal, run the first week with no thresholds and ask for the distribution, then pick the cut-off that gives you about ten items. An exceptions list of 80 lines is not an exceptions list.

The three exports and how they join

In the worked example, the distributor has three exports from three systems.

• orders.csv from the order system: order_id, customer_id, order_date, promised_date, status, lines, sales_value, discount.
• shipments.csv from the warehouse or carrier portal: order_id, ship_date, delivered_date, carrier, freight_cost.
• costs.csv from the accounting package: week, cost_centre, category, amount, budget.

Orders and shipments join on order_id, so that is the easy join. Costs do not join to orders at all; they are a separate lens, compared to budget by week and category. Say so explicitly in the prompt, because an assistant will try to find a relationship between any two tables you give it. Freight cost per order is already on the shipments file, which is why that margin calculation can be done without touching the accounting export.

Before you upload, clean three things. Make order IDs the same format in both files (leading zeros, prefixes and spaces cause silent mismatches). Remove columns you do not need, especially customer names and addresses. Make dates unambiguous: use the year-month-day form in every file, because a day-first export and a month-first export in the same set produces nonsense between the 1st and 12th of any month. One tool detail: Claude takes CSV files directly, but it accepts an XLSX file only once its code execution and file creation setting is switched on, so save the three exports as CSV if you are unsure.

The review prompt, written once and kept

Save the prompt in a ChatGPT or Claude Project along with the rules table, so that next week's run uses identical wording. A version that works for the example:

You are preparing a weekly operations review. I am uploading
three exports for the week ending [date]: orders.csv,
shipments.csv and costs.csv. Use only these files.

Step 1. Reading test. For each file report rows, columns, the date
range, and any blank or duplicated order_id. For orders and
shipments, report how many order_ids appear in both, only in orders
and only in shipments. Stop and wait for me.

Step 2 (after I confirm). Apply the five rules in the attached
table. For each exception list: rule name, order or supplier
or cost line, the values used, and the suggested action from
the table. Put the five lists under separate headings, longest
first, and cap each list at ten items sorted by value at risk.
If more than ten qualify, say how many were left out.

Step 3. Finish with a five-line summary of what changed
versus last week's summary (attached) and anything you were
unable to test because data was missing.

The pause after step 1 is deliberate. It forces the reading test before analysis, and it is the point where a wrong join shows itself in the counts. If 600 order IDs appear in orders, 580 in shipments and only 410 in both, the first question is not "which orders are late" but "why do 170 orders have no shipment". Often the answer is innocent: open orders have not shipped yet. But sometimes it is a formatting mismatch, a different ID in the carrier portal or a split shipment under a new reference.

A sample result, and what to do with it

This sample is illustrative. After step 1, the counts look sensible: 612 orders in the week, 540 shipments, 538 in both files, 74 only in orders (open orders, not yet shipped) and 2 only in shipments (re-sends under old order numbers). Step 2 returns:

• Late-order risk (14 found, 10 shown): the largest is an order worth $18,400 promised for Thursday that is still at "awaiting stock". Action: phone the customer today.
• Repeat-late supplier (2): one supplier late four times in four weeks, average delay 3.5 days, affecting 9 open orders.
• Loss-making orders (6): five are small orders with a flat freight charge above the order margin; one is a large order with a 12% discount and an expensive carrier.
• Cost overrun (3): temporary labour 31% above its eight-week average; packaging 18% above; vehicle repairs 22% above.
• Quiet customer (4): four regular buyers with no order for three weeks, one of them among the top twenty by value.

Read that as a list of questions. The manager spends the first hour on the late-order list and the supplier, because those hurt customers soonest. The loss-making orders become a pricing question for the sales team: is the flat freight charge covering small orders? The labour overrun goes to the person who books agency staff, with the question "was this planned for a stock-take?" and not a conclusion. The quiet-customer list goes to the account owner for a call.

That Monday review should end with a short log: each exception, who owns it and the date it will be rechecked. Ask the assistant to produce the log as a table, and paste it into the shared sheet the team already uses. Next week's run takes last week's log as an input so that the report can say "still open" and "closed" rather than rediscovering the same items.

Where a wrong join hides, and how to catch it

Most errors in an exceptions report are join errors, not rule errors. The shapes to know:

1. One-to-many duplication. An order with three shipments appears three times after a join, so its sales value is counted three times and a margin rule goes wrong. Check: the total sales in the joined table must equal total sales in the orders file. Ask for both numbers.
2. Silent drops. A join that keeps only matches removes orders with no shipment, which is exactly the open and late ones. Check: the count of exceptions for late orders must include orders with no shipment record, and the assistant should say so.
3. Mismatched keys. "SO-1042" versus "1042" produces zero matches for that system. Check: the reading test counts. A low overlap is a symptom.
4. Different grain. Orders are one row per order and a cost file is one row per week per category. Joining them multiplies rows. The two should not be joined at all.
5. Stale files. A shipments export from Friday and an orders export from Monday show orders as unshipped that shipped on Saturday. Check: put the export time in the file name and the first line of the prompt.

Here is a realistic before and after. In the first run, the loss-making list had 31 orders, many of them large. The manager noticed that the total margin looked wrong against last week's report. The reading test had not been run. Checking, the assistant had joined on customer_id as well as order_id, so each order appeared once for every shipment the customer had that week. After fixing the key and rerunning, the list had six orders and the totals reconciled. The fix was to require the reading test every run and to add "total sales value after the join must equal total sales value before it" to the prompt as a check the assistant reports on.

A short reconciliation block that you can add to step 1 of the prompt:

Reconciliation. Report: (a) sum of sales_value in orders.csv;
(b) sum of sales_value after joining to shipments on
order_id only; (c) the difference. If (c) is not zero, stop
and list the order_ids that explain it.

A second example: scoring a supplier from receipts

The repeat-late supplier rule deserves its own prompt, because a single "late" count hides a lot. Give the assistant the purchase receipts for the last eight weeks: supplier_id, purchase_order, promised_date, received_date, quantity_ordered, quantity_received. Ask for a small scorecard per supplier:

For each supplier give: number of deliveries; share received on or
before the promised date; average and longest delay in working
days (late deliveries only); share of quantity received versus
ordered. Rank suppliers by the number of orders currently open
that depend on them. Show the formula for each measure and
list any rows you excluded and why.

An illustrative result for one supplier: 12 deliveries, 7 on time (58%), average delay on the five late ones 3.4 working days, longest 6, quantity received 94% of ordered. A second supplier has 20 deliveries, 19 on time, but received only 81% of quantity, which is a short-shipping problem, not a lateness problem. The single rule "three late deliveries in four weeks" would have flagged the first and missed the second entirely. Quantity fill rate is worth a rule of its own.

A quick sum puts the cost in view. If the first supplier's late deliveries hold up nine open orders averaging $2,000, the sales at risk are $18,000. That number goes in the supplier conversation, along with the dates. The exceptions list is the evidence; the conversation is yours, and it is better held with the dates than with a general complaint.

A filled-in weekly log and the note to the owner

The report is only useful if it ends in actions and a short message. Ask the assistant to turn the list into a log with fixed columns, and to draft the note to the owner or the leadership team. A filled-in log row, with invented content, looks like this:

And the note, which should fit on one screen and avoid hedging that the data cannot support:

Week 12 operations review.
Needs a decision this week: order 20417 ($18,400) will miss its
Thursday date; sales will offer a part-shipment. Supplier 07 has
been late four times in four weeks and affects nine open orders
($18,000).
Watch: temporary labour is $2,150 above its eight-week average;
warehouse manager to confirm whether this was the stock-take.
Not tested: transport costs, because the carrier file for Friday
had not arrived.
All figures reconciled to the order export (sales total $412,300).

That last line, the reconciliation, is the habit that earns trust. When the owner sees "reconciled" and "not tested" each week, they learn that the report says what it did not cover, and so they believe it when it says something is fine.

Checking one number by hand every week

Whatever the assistant does, reproduce one figure yourself. A good habit is to rotate: one week the total late orders, the next the largest margin shortfall, then a cost line. Use a pivot table or a simple filter in the spreadsheet. If you want a refresher on the filters and pivots, the ChatGPT and Excel guide covers the spreadsheet side. The check takes five minutes and gives you a measure of how far to trust the other lines. Keep a tally in the log: if two weeks in a row the numbers agree, you can reduce the check to every other week. If they ever disagree, go back to checking weekly until you find the cause.

Also look at what the assistant did not flag. Pick two orders you know are late from the warehouse, and confirm they are in the list. A report that finds nothing when you know there are problems is worse than a noisy one. If an item you know about is missing, the rule or the data is wrong, and you want to learn which before it matters.

Tuning the rules after three weeks

The first weeks will produce too many or too few exceptions. Adjust with care. Keep a table of rule changes with the date and the reason, because moving thresholds to make a list look shorter hides real problems. Three typical adjustments, each illustrative:

• The late-order rule flags 40 orders a week because many customers book collection and the promised date is a pickup window. Add a column for delivery method and exclude collection orders from that rule.
• The cost overrun rule flags utilities every winter. Compare each cost line with the same weeks in the previous year instead of the last eight weeks, if you have the history.
• The quiet-customer rule flags seasonal buyers. Add a "seasonal" tag to the customer export and exclude those accounts outside their season.

After a month, count how many exceptions led to an action. If only one in five did, tighten the rules; if you found problems through other routes that the report missed, loosen them or add a rule. The best exceptions report is one that shrinks over time because you fix causes, not one that grows because you keep adding checks. Sibling tutorials cover the daily version for route data in a daily exceptions report for delivery managers and the root-cause method in tracing pick errors back to their cause.

The same method in a small manufacturer

The distributor example leans on orders and shipments. A small manufacturer has a different set of three exports, and the pattern still holds. Suppose it exports work orders (job, product, quantity, due date, status), a machine or labour log (job, hours booked, hours quoted) and a materials cost file (job, material, quantity used, standard quantity). The rules become: jobs due within three days and not yet in the final stage; jobs where booked hours exceed quoted hours by more than 20%; and jobs where material used exceeds the standard by more than 5%.

The join key is the job number, and the classic trap is reworks, which reuse the original job number with a suffix in one system and not in another. The reading test shows 310 jobs in the work-order file and 296 in the labour log, and the 14 missing turn out to be reworks logged under "-R" numbers. Without the test, the labour overrun rule would have missed exactly the jobs that went wrong. Add a line to the prompt telling the assistant how to treat the suffix, and a count of how many jobs it applied that to. The report then shows, for the week, that three jobs overran hours by more than 20% and two of them were reworks, which is a quality conversation as much as a costing one.

Handling confidential data in the exports

Operations exports contain customer names, prices and supplier terms. Remove what the rules do not need: names, addresses, contact details and negotiated price lists. Use customer IDs and map them back on your own computer. Check your plan's data controls: ChatGPT's business plans and Claude's Team and Enterprise plans do not train on your content by default, while on individual plans you switch model training off in the privacy settings. Follow any confidentiality clause in supplier or customer contracts. If a rule needs commercially sensitive information, such as a supplier's discount tier, consider whether the check can run inside your own system instead of an outside tool.

The assistant's role in this process is narrow and useful: it applies written rules to tables faster than you can by hand and writes up what it found. You keep the rules, the checks and the decisions. If you want to set up the exports, rules and the review routine for your own operation, that is the work of an AI implementation consultation, and the SOP and incident log tutorial shows how to keep the written procedures behind the rules up to date.

Questions operations managers ask about an AI exceptions report

What is an exceptions report?

A short list of the items that fall outside a rule you set, such as orders shipped late, costs above budget or delays beyond a threshold, instead of a table of everything. The point is to read ten lines that need a decision rather than scan a thousand that do not.

Do I need a data warehouse or BI tool?

No. Three CSV or Excel exports from the systems you already use are enough to start. A BI tool or database becomes worth it when you run the same review daily across many sources and the manual export step is the bottleneck.

How do I stop the AI inventing numbers?

Make it show its working. Ask for row counts, the exact filter used and the source file for each figure, then reproduce one number yourself in the spreadsheet every week. Instruct it to say 'not in the data' when something is missing instead of estimating.

Can this run automatically every week?

Parts can. Exports can be scheduled in many systems and a Project keeps the prompt and rules fixed, but a person should still read the list and own the decisions. Automate the preparation first, and the reading and decisions last, if ever.

Further reads

• Business Operations Automation AI for a Bakery: What Is Worth Automating — What is worth automating first, shown for a bakery.
• Best AI for Ecommerce Operations: Orders, Stock, Returns, Suppliers — Orders, stock and returns for an online store.
• Recruitment Agency KPIs: A Weekly Scorecard From Your CRM Export — Another weekly scorecard built from a system export.
• Multi-Unit Franchisee: One Weekly AI Summary Across Locations — How a multi-unit franchise owner turns each store's POS export into one KPI sheet, an AI-written weekly summary, an exceptions list and a call sheet.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: OpenAI's business data privacy page and ChatGPT plan page; Anthropic's file upload and model training help pages, checked 5 November 2026; general operations-review practice. The business, exports and figures in the examples are invented for illustration.