Order on Hold Email Template: Reason and Next Step

When a customer sees their order sitting in "on hold," they have one question: what do I need to do? If your email doesn't answer that clearly, they open a support ticket, call your phone line, or quietly dispute the charge. The email isn't hard to write—the hard part is writing the right one for the right reason.

An order on hold email template is only useful when it reflects what the system actually shows, not what you assume. "On hold" can mean the bank transfer hasn't arrived, a document is missing, or a manual review is in progress. Each situation calls for a different message with a different next step. Using the wrong template—or worse, sending a payment nudge to someone who already paid—erodes trust faster than a delayed order ever would.

This guide gives you three copyable messages, a table mapping hold reason to stop condition, and a worked example of the paid-but-still-held case that trips up automated systems.

Your turn · A one-minute experiment

What do you send to the customer — and when do you stop?

Fictional one-minute exercise. All business names, customer names, order references, amounts, and system states below are invented for practice.

The situation

FICTIONAL ORDER HOLD SCENARIO Business: Kessler Supply Co. (fictional) Operator: fictional character Dana Frye, operations coordinator Date: 2027-10-03 ORDER ON FILE: Order reference: KSC-2027-8841 Customer: fictional character Marlowe Osei Order total: $634.00 Payment method selected: bank transfer Order status in store system: On Hold SYSTEM CHECKS COMPLETED BY DANA: — Payment gateway log: bank transfer initiated 2027-10-01, funds NOT yet received — Payment system open balance: $634.00 (full amount still outstanding) — Customer support inbox: no reply from Marlowe Osei — Document queue: no missing documents flagged for this order type — Internal review queue: no manual review triggered COMPANY HOLD POLICY: Bank transfer orders are held until funds clear. Estimated clearing time is 2–4 business days. No action is required from the customer unless their bank confirms the transfer failed. A follow-up is suppressed automatically once payment is confirmed in the payment system.

Choose what you would do, then open it to see the reasoning. You can explore every option.

A · Send Template A — awaiting bank transfer; no customer action needed.

Correct. Dana's system checks confirm the hold reason is a pending bank transfer, the full balance is still open, and no document or review flag is present. Template A is written for exactly this state: it tells the customer their transfer is in progress, sets a timeframe, and makes clear no action is required unless their bank reports a failure. The article's stop condition for Template A is payment confirmed in the payment system — that condition has not been met, so sending is appropriate. The article's five-point checklist is satisfied: order reference verified, hold reason checked in the system of record, next step stated, stop condition defined, and contact option present.

B · Send Template B — request a document to unblock the order.

Wrong. Dana's system check shows no missing document flagged for this order type. Template B exists for holds caused by a missing file or customer detail. Sending it here invents a problem that does not exist and asks the customer to do something the system does not require. The article is explicit that the hold reason in the email must match what the system shows, not what you assume. Using the wrong template for the wrong reason creates confusion that takes more support time to unwind than the original hold.

C · Send Template C — manual review in progress, no customer action needed.

Wrong. Dana's check of the internal review queue shows no manual review was triggered for this order. Template C is reserved for holds where an internal check is under way. Sending it here misrepresents the hold reason. The article's reason-to-action table maps each template to a specific hold state — substituting Template C when the actual state is an awaiting bank transfer gives the customer an inaccurate picture of why their order is held and what will resolve it.

D · Send a payment-failed message — the funds haven't arrived, so the payment failed.

Wrong. A bank transfer initiated but not yet cleared is not a payment failure. The article's hold-reason table distinguishes 'awaiting bank transfer' from 'payment failure' as separate states requiring separate messages. Sending a payment-failed message to a customer whose transfer is simply in transit implies they did something wrong, damages trust, and directly contradicts the article's warning that sending a payment-nudge to someone who already initiated payment erodes the customer relationship. Dana's gateway log confirms the transfer was initiated — failure has not been reported.

Selecting the right hold email requires checking the actual system state — hold reason, payment balance, document queue, and review status — before picking a template. A bank transfer in transit is not a payment failure, and no template substitutes for a live state check before sending.

Why "On Hold" Is Not One Thing

"On hold," "cancelled," and "payment failed" are distinct machine-level order states. "On hold," "Failed," and "Cancelled" are distinct machine-level order states — your messaging and stop logic need to treat them separately.

Here's what that looks like in practice:

Hold reason	What it means	Wrong message to send
Awaiting bank transfer	Payment initiated, funds not yet received	"Your payment failed"
Missing document or information	Order can't proceed without a file or detail from the customer	"Please pay your invoice"
Manual review in progress	Internal check under way; customer action may not be needed yet	Anything that implies they did something wrong
Payment failure	Card declined or gateway error	"We're reviewing your order"
Cancelled	Order ended	A reminder to complete payment

Sending the wrong message for the state isn't just unhelpful—it creates confusion that takes more support time to unwind than the original hold would have.

Three Copyable Templates

Each template below includes the order reference, a plain statement of the hold reason, one next step, and a contact option. They're written conservatively—treat them as marketing communications and review applicable regulations for your audience before sending at scale.

Before you copy any of these: check the actual order record in your system of record. The hold reason in the email must match what the system shows, not what you expect.

Template A — Awaiting Bank Transfer or Payment Confirmation

Subject: Your order [ORDER-REF] is on hold — payment confirmation needed

Hi [Customer Name],

Thank you for your order ([ORDER-REF]) placed on [DATE].

We're holding your order while we wait for your bank transfer to clear. This is normal for bank payment methods and usually takes [TIMEFRAME] depending on your bank.

What happens next: no action is required from you unless your bank confirms the transfer didn't go through. We'll update your order as soon as payment is confirmed.

If you have questions or want to use a different payment method, reply to this email or contact us at [CONTACT].

We'll release your order as soon as funds arrive.

[Your Name / Team]

If you'd prefer not to receive order status emails, reply with "unsubscribe" and we'll remove you from this list.

Stop condition: payment received and confirmed in your payment system. Do not send a follow-up if payment has cleared.

Template B — Missing Document or Information Required

Subject: Action needed on order [ORDER-REF] — one thing required

Hi [Customer Name],

We received your order ([ORDER-REF]) and we're ready to process it — we just need one thing from you first.

What we need: [SPECIFIC DOCUMENT OR INFORMATION — e.g., a signed delivery authorisation, a valid business registration number, proof of address]

How to send it: reply to this email with [DOCUMENT] attached, or upload it here: [LINK IF AVAILABLE].

We'll process your order within [TIMEFRAME] of receiving it. If we don't hear from you by [DATE], we may need to cancel the order to avoid it sitting open indefinitely.

If you have questions about what's needed and why, contact us at [CONTACT] and we'll walk you through it.

[Your Name / Team]

If you'd prefer not to receive order status emails, reply with "unsubscribe" and we'll remove you from this list.

Stop condition: document received and verified. Do not send a second request if the document is already in the queue awaiting review.

Template C — Manual Review in Progress (No Customer Action Required)

Subject: Your order [ORDER-REF] is under review — we'll be in touch

Hi [Customer Name],

Your order ([ORDER-REF]) is currently being reviewed by our team. This step is part of our standard process for orders of this type, and it doesn't mean anything is wrong.

What you need to do: nothing right now. We'll contact you within [TIMEFRAME] if we need anything from you.

If your order passes review without any issues, you'll receive a confirmation and we'll proceed with fulfilment as normal.

Questions? Contact us at [CONTACT].

[Your Name / Team]

If you'd prefer not to receive order status emails, reply with "unsubscribe" and we'll remove you from this list.

Stop condition: review complete. If the outcome is approval, send a confirmation, not another hold notice. If the outcome is cancellation, send a cancellation email—not a hold follow-up.

The Paid-But-Still-Held Problem

Here's a situation that breaks simple automations: the customer paid, the payment cleared in your gateway, but the order is still showing "on hold" because the status update hasn't propagated yet—or because a secondary review is still running.

If your reminder system doesn't check actual payment status before sending, it fires a payment reminder to someone who paid. That's a fast way to damage a customer relationship and create a chargeback risk.

The fix is the same principle that good payment reminder email templates follow: check the current state of the invoice or payment record, not just the order status field. Stripe's payment reminder guidance notes that omitting the invoice reference, amount, or payment instructions are among the most common reminder mistakes (Stripe payment reminder guide). Checking actual payment status before sending is a separate discipline — the template alone can't substitute for a live state check. BILL's official help documentation confirms that reminders are sent against invoices with more than $0 due, including partially paid invoices, and that reminder templates can be customised with placeholders (BILL auto-reminders help). Both sources reinforce the same principle: check the actual open balance, not the order status field, before deciding whether to send.

Concretely: before any follow-up goes out, confirm in your payment system that the balance is still open. If it's been paid—even partially—the message changes or stops entirely.

Reason-to-Action Table with Stop Conditions

Hold reason	Template	Next step for customer	Stop sending when
Awaiting bank transfer	A	None — wait for confirmation	Payment confirmed in payment system
Missing document	B	Send specified document	Document received and in review queue
Manual review	C	None — wait for team	Review completed, confirmation sent
Payment failed	(separate message)	Retry payment or contact bank	Payment successful
Cancelled	(cancellation notice)	—	Order closed

Hold and cancellation are different states requiring different messages. Do not reuse a hold template for a cancelled order.

Before You Send: A Five-Point Review

Run this check on every draft before it reaches a customer:

Order reference confirmed — the [ORDER-REF] field pulls from the actual order record, not a placeholder
Hold reason verified — you checked the system of record, not assumed the reason
Next step is specific — one action, not a list; "reply with your document attached" not "get in touch if needed"
Stop condition defined — you know what state clears this hold and have a rule to suppress follow-ups when it does
Contact option included — the customer has a direct route to a person, not just a link

The Stripe guide identifies vagueness—omitting invoice number, amount, or payment instructions—as a recurring cause of failed payment follow-up (Stripe payment reminder guide). BILL's documented reminder behaviour—stopping automatically when a balance reaches $0—illustrates the same principle in a live system (BILL auto-reminders help). These five checks catch the same problems in a hold context.

When You're Sending at Volume: Human Approval Before the Draft Leaves

The payment reminder email template examples above are written for manual or low-volume sending. If you're running a queue of holds and reminders across many orders, the risk isn't the template wording—it's whether the system checks current state before drafting, and whether a person reviews the draft before it sends.

This is exactly the design problem the Finance Collections Agent solves for B2B invoice workflows. Before every reminder, the agent checks payment status across QuickBooks, BILL, and the Gmail mailbox—four branches: paid (reminder cancelled), replied (cadence pauses for a person), partially paid (message rewritten from the real balance), unreadable (nothing sends, row is flagged). Every draft sits in Slack until a person clicks send. The invoice email and every follow-up require separate approvals; no message reaches a customer without a human click (Finance Collections Agent).

That's the same logic these templates assume you're running manually: check actual state, select the right message, confirm before sending. The agent applies it at scale for reseller-shaped businesses working across Salesforce, QuickBooks, BILL, Gmail, and Slack. Connecting a WooCommerce store would be a custom scope, not a native integration—but the underlying principle is transferable to any system where hold state and payment state are separate records.

For a broader look at why an AI draft needs human review before it makes a promise, the AI email reply guide works through exactly that decision.

Your Exercise

Pull one order currently on hold in your system. Before writing a single word, answer these four questions:

What is the specific hold reason shown in the system of record?
Has payment been received anywhere in the payment chain, even if the order status hasn't updated?
What is the one action, if any, the customer needs to take?
What state change will tell you to stop sending?

Now pick the template that matches question 1, fill in the verified details, and run the five-point checklist. If you can't answer question 2 with confidence, don't send the payment variant—send Template C or confirm payment status before proceeding.

If you're managing invoice holds at volume and want to see how the state-check and approval flow works in practice, book a walkthrough with the Splice Work team.