The line is ready. The traveler is printed. The operator is waiting for material that "should be on the dock."

Purchasing sent the PO two weeks ago. The supplier never sent a clean acknowledgement. Or they did — buried in a reply that changed the ship date, split the quantity, and forgot the mill cert. Nobody noticed until the floor asked where the parts were.

That is not an inventory-math problem. It is a confirmation problem. The PO went out. The status in the spreadsheet still says "ordered." The truth is sitting in an email thread nobody owns.

We build this as a bounded n8n workflow: watch the purchasing / vendor inbox, extract what the reply actually said, compare it to the confirmation window you expect, route exceptions to the right owner in Slack, draft the follow-up, and log the confirmation status. Claude summarizes messy supplier replies. Humans still approve anything that goes back to a vendor.

Here is the workflow, step by step.

The Pain Purchasing Already Knows

On a 30–60 person shop, vendor communication is still mostly email and phone. POs leave the ERP or get typed into a PDF. Confirmations come back as free-text replies, forwarded PDFs, portal screenshots, or "looks good — ship Friday" messages with no PO number.

Typical failure modes:

• No acknowledgement inside the window you need (often 48–72 hours after send)
• Acknowledgement arrives, but promised date moved and nobody updated the schedule
• Quantity, revision, or price changed in the reply and nobody flagged it
• Docs missing: C of C, material cert, FAIR, packing list — discovered at receiving or at the customer
• Same PO chased three times because status lives in one person's inbox

Late confirmations turn into late material. Late material turns into late customer shipments, expedite fees, and the ops manager walking the floor with a fire. The fix is not a new ERP module on day one. It is a watchdog on the confirmation loop you already run by hand.

What the Workflow Does

n8n is the spine. Claude handles the messy text. Slack is the exception channel — not the system of record.

On a schedule (and on new vendor-inbox mail), the workflow:

1. Pulls open POs that still need confirmation (from a sheet, Notion table, or ERP export)
2. Watches the purchasing / vendor mailbox for replies tied to those POs
3. Extracts supplier, PO number, part / line, promised date, quantity notes, and missing-document signals
4. Compares today against the expected confirmation window and the promised date vs. need-by date
5. Routes exceptions to the right owner in Slack with a short summary
6. Drafts a vendor follow-up (hold for human approve before send)
7. Logs confirmation status so you can see who confirmed what, when, and what changed

Clean acks can auto-mark "confirmed" and update the log. Ambiguous or changed replies always go to a human.

How to Build It

You will need: n8n (cloud or self-hosted), access to the purchasing inbox (Gmail or Microsoft 365), a place to track open POs (Google Sheet is fine to start), Slack for exceptions, and a Claude API key for reply summarization.

Step 1: Define the open-PO list

Create a simple tracker with columns you already care about: PO number, supplier, part / SKU, quantity, need-by date, sent date, expected confirm-by date, promised date, confirmation status, missing docs, owner, last vendor message link.

Status values that work in practice: sent, awaiting_ack, confirmed, date_changed, docs_missing, exception, closed.

If purchasing still lives in the ERP, export open POs once a day into the sheet. Do not wait for a perfect ERP API to start.

Step 2: Watch the vendor inbox

In n8n, add a Gmail or Microsoft Outlook trigger (or a short poll on a Schedule + Get Many messages). Filter to the purchasing mailbox or a label/folder used for vendor replies.

Match each message to an open PO by PO number in subject/body, supplier domain, or part number. Unmatched mail goes to a Slack "needs triage" queue — do not force a bad match.

Step 3: Extract the confirmation facts

For structured portal emails, parse with regex or a Code node. For real supplier replies — the ones with three paragraphs, a new date buried in the middle, and "certs to follow" — call Claude with a fixed schema:

• po_number
• supplier_name
• promised_ship_date
• quantity_notes
• price_or_revision_changes
• documents_mentioned / documents_missing
• confidence
• one_paragraph_summary

Require JSON back. If confidence is low or required fields are blank, route to exception — never invent a ship date.

Step 4: Compare against the confirmation window

Add an IF / Switch path:

• Past expected_confirm_by and still sent / awaiting_ack → overdue ack exception
• Promised date later than need-by → schedule-risk exception
• Docs required but not mentioned / attached → docs-missing exception
• Clean ack inside window → mark confirmed, write promised date, stop

This is where the workflow earns its keep: the exception appears days before the dock is empty, not after.

Step 5: Route exceptions in Slack

Post to #purchasing or #ops with: PO, supplier, part, why it flagged, Claude's one-paragraph summary, link to the email thread, and the suggested owner (buyer, planner, quality).

Slack is for visibility. The status still updates in the PO tracker. If the only record is a Slack thread, you will lose the audit trail the next time someone asks "when did they confirm?"

Step 6: Draft the vendor follow-up — human approves send

Use Claude (or a template + Code node) to draft a short follow-up: PO number, what you still need (ack, revised date, certs), and a clear reply-by date.

Do not auto-send vendor-facing mail on day one. Put the draft in Slack or email the buyer with Approve / Edit / Dismiss. After the buyer approves, n8n sends from the purchasing mailbox and logs the outbound message.

Vendor relationships and commitment language belong to a human. The automation's job is to make sure the chase happens on time with the right facts attached.

Step 7: Log confirmation status

Every state change writes a row: timestamp, PO, old status → new status, promised date, exception reason, actor (workflow or buyer name), message link.

That log is more valuable than a flashy bot. It answers customer OTD questions, internal "who dropped this?" debates, and the next process review without digging through inboxes.

What Good Looks Like After 30 Days

For a shop that previously found out about slipped suppliers at receiving:

• Overdue acks surface inside the confirmation window instead of on the dock
• Date changes hit planning before the traveler hits the floor
• Missing certs get chased before the customer pack, not during it
• Buyers spend review time on exceptions, not inbox archaeology
• You can show a confirmation history per PO without asking one person to "check their email"

Start narrow: one buyer, one supplier tier (critical path / long-lead only), one mailbox. Expand after the team trusts the exception queue.

What This Does Not Do (On Purpose)

This workflow does not replace MRP, auto-place POs from stockouts, renegotiate pricing, or send unsupervised commitments to vendors. Those are separate designs — and some of them should stay human forever.

Keep the first build boring: detect missing or changed confirmations, notify the owner, draft the chase, log the result. That is enough to stop the line from waiting on an unread email.

Where to Start

If your purchasing team already knows which suppliers go quiet, start with those POs and the inbox rules above. If you are not sure which supplier loop burns the most schedule risk, map it first.

Book a Free Quick Assessment at cloudbeast.io/schedule if you want a short walkthrough of the current confirmation path. If you already know this is the loop and need a written scope map, the Tier 1 AI Audit ($999) is at cloudbeast.io/audit. Either way, the goal is the same: confirmations that show up before the line waits — with humans still on the vendor-facing messages.