The PO lands at 7:42 AM. By 9:15 the buyer has emailed twice: "Did you get this?" Customer service is still hunting — ERP screen, email thread, a spreadsheet that says "entered" but nobody wrote the ship date, quantity, or ship-to the customer will actually see.

So someone drafts the confirmation by hand. Again. Same template, different numbers, slight chance the line qty or promise date is wrong because they copied from the wrong tab. The confirmation goes out at 11:40. The buyer already escalated to their purchasing manager.

That is not a customer-service problem. It is an order-confirmation loop that still lives in one person's inbox. The order entered the building. The customer does not know what you committed to — or whether you saw the PO at all.

We build this as a bounded n8n workflow on the outbound customer lane: pull order signals from email or ERP, draft a customer-facing confirmation, route exceptions (credit hold, partial ship, unknown SKU, bad ship-to), and hold every send for human approval. Claude can summarize messy PO emails. Humans still own the language that commits you to a date and a quantity.

This is the opposite direction from a supplier acknowledgement watchdog. That post watches vendor replies on POs you issued. This one confirms orders you received — the message your customer is waiting on.

The Pain Customer Service Already Knows

On a 20–80 person distributor or job shop with a front office of two or three people, order intake is still mostly email plus the ERP. Customers send POs as PDFs, portal dumps, or "please confirm the attached" replies with three change lines buried in the body.

Typical failure modes:

• No confirmation inside the window the customer expects (often same day, sometimes within a few hours on rush lines)
• Confirmation goes out, but promise date, qty, or ship-to does not match what is in the ERP
• Partial ship / backorder / credit hold never gets called out — customer assumes full release
• Same PO confirmed twice because two people both "owned" the thread
• Status lives in one inbox; when that person is out, the phone lights up

Late or wrong confirmations turn into expedites, chargebacks, and the ops manager answering "where's my order?" instead of running the floor. The fix is not a full OMS rebuild on day one. It is a draft-and-hold loop on the confirmation work you already do by hand.

What the Workflow Does

n8n is the spine. Claude handles messy PO text when the ERP is not the first signal. Slack (or email) is the exception and approval channel — not the system of record.

When a new order signal arrives (or on a short poll of today's open orders), the workflow:

1. Pulls the order from the customer inbox and/or an ERP / sheet export of new orders needing confirm
2. Extracts customer, PO / order number, lines, quantities, ship-to, requested date, and special notes
3. Matches against ERP / open-order truth where you have it — flags mismatches
4. Classifies: clean confirm, exception (credit, partial, unknown SKU, address fail), or needs triage
5. Drafts a customer-facing confirmation (or exception note) into a review queue
6. Routes exceptions to the right owner in Slack with a short summary
7. Holds send until a named person Approves / Edits / Dismisses
8. Logs confirmation status so you can see what went out, when, and who approved it

Clean, matched orders become fast draft → approve → send. Ambiguous or changed orders always stop for a human.

How to Build It

You will need: n8n (cloud or self-hosted), access to the order / CS mailbox (Gmail or Microsoft 365), a place to track open orders needing confirm (Google Sheet is fine to start; ERP export works), Slack for exceptions and approval, and optionally a Claude API key for PO email extraction.

Step 1: Define the "needs confirmation" list

Create a simple tracker: order / PO number, customer, ship-to, lines / qty summary, requested date, promise date, confirmation status, exception reason, owner, source message link, draft link.

Status values that work in practice: received, draft_ready, exception, approved, sent, customer_replied, closed.

If the ERP already creates the order on entry, export "entered today / confirm pending" once an hour into the sheet. Do not wait for a perfect ERP API to start.

Step 2: Capture the order signal

In n8n, add a Gmail or Microsoft Outlook trigger (or Schedule + Get Many) on the orders mailbox or a dedicated label/folder. Optionally add a second path that polls the ERP export / sheet for rows still in received.

Match mail to an open order by PO number, customer domain, or order number in subject/body. Unmatched mail goes to a Slack "needs triage" queue — do not force a bad match into a customer confirmation.

Step 3: Extract the confirmation facts

For structured EDI / portal emails, parse with regex or a Code node. For real customer POs — PDF attachments, multi-line change notes, "confirm ASAP" with no ship-to — call Claude with a fixed schema:

• po_number / customer_order_ref
• customer_name
• line_items (sku / description, qty, uom)
• ship_to
• requested_date
• special_instructions
• change_or_exception_signals
• confidence
• one_paragraph_summary

Require JSON back. If confidence is low or required fields are blank, route to exception — never invent a promise date or quantity for the customer-facing draft.

Step 4: Compare against ERP / open-order truth

Add an IF / Switch path:

• Order in ERP matches extracted lines → draft standard confirmation
• Qty / SKU / ship-to mismatch → exception (do not send a confident wrong confirm)
• Credit hold, backorder, or partial release flagged in ERP → exception draft that names the gap
• No ERP match yet → triage queue, not auto-draft as confirmed

This is where the workflow earns its keep: the wrong confirmation never leaves because the mismatch hit Slack before send.

Step 5: Draft the customer confirmation — human approves send

Use Claude (or a template + Code node) to draft a short confirmation: PO / order number, lines confirmed, promise date (only if you have it), ship-to, and a clear reply-to for changes.

Do not auto-send customer-facing mail on day one. Post the draft to Slack or email CS with Approve / Edit / Dismiss. After approval, n8n sends from the CS mailbox and logs the outbound message.

Commitment language belongs to a human. The automation's job is to make sure the draft is ready while the buyer is still waiting — with the right facts attached.

Step 6: Route exceptions, then log everything

Post exceptions to #orders or #cs with: customer, PO, why it flagged, Claude's one-paragraph summary, link to the thread, and suggested owner (CS, credit, warehouse).

Every state change writes a row: timestamp, order, old status → new status, exception reason, actor (workflow or approver name), message link. That log answers "when did we confirm?" without digging through inboxes during the next OTD review.

What Good Looks Like After 30 Days

For a distributor or shop that previously confirmed by hand when someone had time:

• Same-day confirms become the default for clean orders, not the exception
• Mismatches and credit holds surface before the customer gets a confident wrong email
• CS spends review time on Approve / Edit, not rewriting the same letter from scratch
• You can show confirmation history per order without asking one person to check their Sent folder

Start narrow: one mailbox, one customer tier (top accounts or EDI-light email POs), one CS owner. Expand after the team trusts the draft queue.

What This Does Not Do (On Purpose)

This workflow does not replace the ERP, auto-promise inventory you do not have, renegotiate pricing, or send unsupervised commitments to customers. Those are separate designs — and some of them should stay human forever.

Keep the first build boring: detect the order, draft the confirm, route exceptions, human gate, log the result. That is enough to stop the buyer from escalating while the draft sits unfinished.

Where to Start

If your CS team already knows which accounts chase hardest, start with those POs and the draft-and-hold pattern above. If you are not sure whether the bottleneck is intake, ERP match, or the send step, map the current path first.

Book a Free Quick Assessment at cloudbeast.io/schedule if you want a short walkthrough of the current confirmation loop. If you already know this is the pain and need a written scope map, the Tier 1 AI Audit ($999) is at cloudbeast.io/audit. From there, a Quick Win or Custom Sprint only if the first loop proves it saves time — with humans still on every customer-facing send.