Status Update Emails From Your ERP: What to Send and When

A good ERP status update email tells the recipient what changed, what happens next and when they will hear from you again, using data pulled from the order record rather than typed from memory. Most teams get the sending half roughly right. The harder half is the other direction: customer and supplier replies arrive in Outlook or Gmail, and someone has to turn them into updates on the right ERP record. This guide covers both, with the content each email needs, a simple way to track response SLAs, and how to keep the inbox and the ERP in agreement.

Ampwise

Keep Email Replies in Sync With Your ERP

Ampwise processes orders, inquiries and invoices from Outlook or Gmail, helping teams reduce manual data entry and errors.

Explore email-to-ERP automation

TL;DR

Send a status email only when a real order event happens, and pull every figure from the ERP record, not from a template someone edited by hand.
Put the change in the subject and first line, then give one next step and a commitment for the next update.
Track first response time and resolution time as separate SLA metrics, and define “unreplied” so bounces and system notices do not count.
Replies that change an order (dates, quantities, confirmations) are where errors creep in. Automate extraction, then review before posting.
Measure the result: hours from email received to ERP entry, share of orders touched by hand, and the volume of “where is my order?” emails.

Two directions of status email
What each stage of an order email should contain
How to write the email so it gets read
Triggering emails from real events
The inbound side: replies that must update the ERP
Tracking SLAs on email orders and replies
A practical setup in five steps
Measuring whether it works
Our perspective: the inbox is the missing ERP screen
See it on your own inbox
FAQ
Sources

Two directions of status email

When people search for status update emails in an ERP context, they usually mean one of two things.

Outbound. The ERP (or a layer on top of it) emails a customer, supplier or internal team when an order moves: confirmed, picked, shipped, delayed, delivered.

Inbound. A supplier confirms a purchase order by email, a customer changes a quantity in a reply, or a carrier sends a delay notice. Somebody reads it and updates the order.

Most advice online covers only the outbound half, and it is written for retail stores. B2B is different. Your orders are larger, the contacts are named people, the documents are PDFs and spreadsheets, and a wrong quantity costs real money. The principle is the same for both directions: the ERP record is the single source of truth, and email is a view of it.

What each stage of an order email should contain

The content depends on the stage. Industry guidance on transactional email is consistent here: confirmations need order numbers and pricing breakdowns, shipping notices need tracking links and the items included, and delivery notices should give proof of arrival and a support path. For a B2B setting, adapt it like this.

Stage	Trigger in the ERP	Must include	Often forgotten
Order or PO received	Order created or PO logged	Customer PO number, your order number, line items, quantities	Who is handling it
Confirmation	Order validated and released	Itemized lines, price breakdown with tax and freight, ship-to address, estimated delivery date	Payment terms
Partial or full shipment	Shipment posted	Carrier, tracking link, which lines shipped and which remain	Backorder date for the rest
Delay or exception	Promised date missed or stock short	What happened, new ETA if known, what you are doing	When the next update arrives
Delivery	Proof of delivery recorded	Delivery confirmation, invoice reference, support contact	How to report damage or shortage

Order confirmation emails in particular are expected to carry the order number, an itemized list, a pricing breakdown (subtotal, shipping, tax, total), the shipping address, an estimated delivery date and a support contact, according to the same guide. In B2B, add the customer’s own PO number to that list. Their accounts payable team will match on it.

How to write the email so it gets read

The rules are short, and they hold whether the message goes to a buyer in Ohio or a distributor in Rotterdam.

Lead with the change. The subject and first line state what changed. Status emails work best when they read like receipts of progress, not marketing.
Show verified status only. Include the current status, one clear next step for the recipient, and a reliable time or next-update commitment, as order update templates recommend. If you do not know the ETA, say so and say when you will.
Put timing changes at the top. Nobody should have to hunt through the body to learn the date moved.
Ask for one thing. If you need a confirmation, a corrected address or a signed document, name the person, the item and the deadline.
Keep promotion out. Order updates are transactional. Adding advertising can pull a message into strict email-marketing rules, including recipient consent. In the US, the FTC notes that the CAN-SPAM Act covers all commercial email and makes no exception for business-to-business messages, so keep the primary purpose of an order email on the order.

A short example of a shipping notice that follows these rules:

Subject: PO 48213: 3 of 5 lines shipped, 2 lines ship Nov 4

Hi Dana, lines 1 to 3 of PO 48213 left our warehouse today with tracking 1Z… (link). Lines 4 and 5 are waiting on a pallet of gaskets due in on Nov 3, so they will ship the next day. Nothing is needed from you. We will confirm by email when the second shipment leaves.

Notice what it does not contain: a greeting paragraph, a logo banner, a discount code. It answers the question the buyer would otherwise phone to ask.

Triggering emails from real events

The most common failure is an email that says something the system does not know. Status messages should be triggered by real order events and use verified status data from the commerce or shipping system. That means the trigger is a field change in the ERP (status moves to “released”, a shipment is posted), not a person remembering to write.

For stores where the order data lives in a web shop and the ERP behind it, how the two systems exchange data matters. This breakdown of Shopify and ERP integration with webhooks versus batch shows why event-based sync gives fresher status data than nightly batches, which is what a status email depends on.

Delays and exceptions

Delays are the emails that matter most, and the ones teams write worst. When shipping slips, the email should explain the situation using verified facts and give a clear, measurable commitment for the next update. The same source suggests designing a “state matrix” rather than a single template, so split shipments and repeated delays do not break the wording.

For long lead times, another guide recommends that a delay message offer reassurance, a new ETA if known, what you are doing about it, and an escalation link. In B2B, the escalation link is usually a named account owner with a direct phone number.

Do not over-send. Proactive notifications reduce “where is my order” questions, but only if they are sent at real milestones, otherwise people learn to ignore them. Five meaningful emails per order beat fifteen automatic ones.

The inbound side: replies that must update the ERP

Here is where the manual work hides. A buyer replies “Please change line 2 to 40 units and deliver Thursday.” A supplier sends a PDF acknowledgement with a new ship date. A carrier emails a delay. Each one should change a field in the ERP, and each one normally depends on a person reading, interpreting and typing.

Three things go wrong:

Matching. The email references a PO number in the subject, the body, or only inside a scanned attachment. Picking the wrong record means the update lands on the wrong order.
Interpretation. “Same as last time but 10 more” requires context.
Delay. The reply sits in a shared inbox until someone has time, so the ERP shows a stale status and your next outbound email repeats it.

This is the problem we built Ampwise to solve. It reads incoming messages and attachments in Outlook or Gmail (emails, PDFs, Excel files, scanned documents), extracts the data without needing templates, validates it, and lets a person approve it with one click before it is posted to the ERP. If you want the detail on how that review step works, read our guide on automating email orders with human review before posting. For changes that arrive after an order is already entered, see how to handle order changes after entry, and for routing, how to auto route order emails from inbox to ERP.

A PO confirmation from a supplier is a good example of a check worth automating. Comparing the confirmed prices, quantities and dates to what you ordered before they touch the record is covered in our piece on validating purchase orders before ERP release.

Tracking SLAs on email orders and replies

If orders arrive by email, the email clock is part of your order-to-cash clock. Teams that ask how to track SLAs on email orders usually need three things: a definition, a target and an alert.

Define the clock precisely

For SLA reporting, define “unreplied” so that bounces and system notifications are excluded, and keep first response time separate from resolution time. For order email, that translates into two measurements:

Acknowledgement time: from email received to a reply or an order confirmation sent.
Posting time: from email received to the order existing in the ERP with a verified status.

They are different. A fast “we got it” is good for the customer, but only posting time tells you whether the order can actually be picked.

Set targets by urgency

Targets should vary. One example from a team-inbox guide uses 2 hours for urgent billing or outage emails and 8 business hours for general support, with alerts as deadlines approach. For orders, a sensible split might be:

Email type	Example target	Alert when
Rush or same-day order	Posted within 2 business hours	75% of the window has passed
Standard purchase order	Posted within 1 business day	End of day if still unposted
Order change after entry	Posted before the pick is released	Pick is scheduled and change unconfirmed
General inquiry	Acknowledged within 8 business hours	Window closes with no reply

These numbers are starting points, not standards. Set them from what your warehouse cutoffs and customer contracts actually require. As a baseline for internal messages, one communications guide suggests acknowledging emails that need a response within one business day, and no later than two. The same guide says the sender carries the duty of stating the expected response time, so your outbound emails should include a specific deadline whenever you need input.

Escalate like an order system does

Order management platforms separate two kinds of messages: event notifications that communicate status and move fulfillment to the next step, and jeopardy notifications that alert people when a deadline is missed. Borrow that split. Status emails go to customers. Jeopardy alerts go to your own team: the order has been in “received” for four hours, the supplier confirmation is overdue, the customer has not answered the address query.

If your response-time reporting depends on email delivery events, keep the data clean. Failed deliveries distort the numbers unless you handle them, and this guide to bounce handling for email APIs and webhooks explains how to separate them from real replies.

A practical setup in five steps

Map your statuses. Write down every ERP status and decide which ones deserve an email. Usually: received, confirmed, shipped, delayed, delivered.
Write one template per state, not per order. Include the variables from the table above, plus a delay variant and a partial-shipment variant.
Connect triggers to events. Use the ERP’s own status change or a webhook, never a manual send.
Automate the inbound reads. Capture order emails, replies and confirmations, extract the data, and queue it for one-click approval.
Report weekly. Acknowledgement time, posting time, share of orders touched manually, and the count of status-chasing emails.

If you are deciding where to begin, a 2 to 4 week pilot from inbox to ERP gives you real numbers on a single customer or mailbox before you commit further.

Measuring whether it works

Three measures tell you quickly:

Time from received to posted. This should fall sharply once extraction is automated. It is the number your customers feel.
Manual touch rate. The share of orders where someone retyped data. Our order processing automation guide covers how teams cut manual entry by up to 90%.
Status-chasing volume. Count emails and calls asking where an order is. If outbound updates are working, this falls. If it does not, your emails are missing the question buyers actually have.

Add error corrections (credit memos, wrong-quantity returns) as a fourth measure. It is the cost of manual entry made visible.

Our perspective: the inbox is the missing ERP screen

We talk to operations teams every week, and the pattern is consistent. The ERP is accurate about what has been entered. The inbox is accurate about what customers and suppliers have said. The gap between the two is where late shipments, wrong quantities and awkward phone calls come from.

Most companies respond by writing nicer outbound emails. That helps, but it treats the symptom. If the ERP status is a day behind the inbox, a beautifully written update still tells the customer the wrong thing. We think the order of work should be: first get what arrives by email into the ERP quickly and correctly, with a person approving anything uncertain; then send status messages from that verified data; then measure the clock.

We also believe in keeping people in the loop. AI should do the reading and the typing, and your team should keep the judgment. That is why Ampwise works inside Outlook and Gmail, needs no templates from your customers and does not ask staff to learn a new system. If your orders are mostly structured and high volume, EDI may serve you well, and we explain where each fits in our comparison of EDI versus email. For the long tail of messy emails, automation of the inbox is usually the faster win.

— Evert

See it on your own inbox

Ampwise connects Outlook or Gmail to your ERP, extracts orders, confirmations and changes from emails, PDFs, Excel files and scans, and posts them after one-click approval. If status mismatches and manual entry are costing your team hours, you can see how Ampwise works and start with a single mailbox.

FAQ

How do I write an email for delivery status?

Open with the status and the order reference in the subject, such as “PO 48213: shipped, arriving Nov 4”. In the body give the carrier and tracking link, the lines included, and what the recipient needs to do, if anything. Close with when you will next update them if the delivery is delayed.

How do I politely ask a supplier for a status update?

Name the PO number and the line in question, state the date you were promised, and ask for a specific answer by a specific day. A message like “Could you confirm the ship date for PO 48213 line 2 by Thursday noon?” is easier to answer than a general request for news, and it is courteous because it costs the supplier little time.

Should ERP status emails include marketing content?

It is safer not to. Order updates are transactional, and adding promotion can bring them under email-marketing rules such as consent requirements. In the US, the CAN-SPAM Act applies to commercial messages even between businesses, so keep order emails focused on the order.

How can I track SLAs for orders that arrive by email?

Measure acknowledgement time and posting time separately, define what counts as unreplied, and set alerts as each deadline approaches. Targets should differ by urgency, for example a rush order versus a routine inquiry. Review the metrics weekly and escalate overdue items to a named owner.