How to automate 'the usual' recurring B2B orders

Who this is for: Small and mid-sized US wholesale distributors on QuickBooks Online whose regulars order in shorthand and expect you to know what they mean.

Common pain points

• Regulars email 'the usual' or 'same as last time' and assume you know their history
• What each customer's usual actually is lives in one experienced person's head
• Rebuilding near-identical orders by hand eats time on the accounts that should be easiest
• Blindly repeating last month's order quietly ships the wrong thing when the pattern drifts

The workflow

1. Connect QuickBooks Online. Your customers and items sync in, and PeasyOrders reads your past invoices once — so each customer's buying history, what 'the usual' actually is, exists from the first day. The pricing it proposes from those invoices applies only once you accept it.
2. Let it learn each customer's shorthand. When your team corrects and confirms a draft, PeasyOrders remembers what that customer's phrase resolved to. After a few orders, the same shorthand from the same customer arrives already matched, with the alias shown on the line.
3. Capture the repeat order. A one-line email, or a forward of last month's order — PeasyOrders identifies the customer and proposes a draft from their pattern. Phone regulars are added in one click into the same queue.
4. Apply pricing and the change. The draft carries that customer's pricing, and a tweak like 'the usual plus 2 more cases' is reflected as an explicit change against the pattern.
5. Review and confirm. You check the proposed order; anything ambiguous or changed is flagged so you confirm rather than assume. Nothing is placed or exported without a person approving it.
6. Export to your books. Approve and export to QuickBooks Online as an Estimate by default (configurable), or to Google Sheets or CSV.

Two different things people call "recurring orders"

"Recurring orders" means two different things, and they're automated differently. One is recognizing "the usual" — a repeat customer ordering roughly what they always do, sent ad hoc and abbreviated. The other is a standing order that repeats on a fixed schedule with no customer action. Most of your daily repeat-order work is the first kind, and the way to automate it is to recognize the customer's pattern and propose the order for them to confirm — not to retype it from memory every time.

If a chunk of your week is rebuilding near-identical orders for the same accounts — "send the usual," "same as last month," a forward of the last order — you're doing by hand what a system can recognize. For small and mid-sized US wholesale distributors on QuickBooks Online, this page covers how.

The two problems call for opposite designs: standing orders remove the customer from the loop entirely; recognizing "the usual" keeps the customer in the loop and makes your side faster. This page is mostly about the second, with an honest note on where standing orders fit at the end.

Why is "the usual" harder to automate than it sounds?

It seems trivial — just repeat the last order. The traps:

• The order is unstated. "The usual" isn't data. Someone has to know what this customer's usual actually is before it can become line items.
• The knowledge lives in a person. Usually one experienced person. When they're out, "the usual" becomes a guessing game, and orders wait or go wrong.
• The pattern drifts. Usuals change — a product drops, quantities shift, a new line appears. Blindly repeating last time quietly ships the wrong order.
• Pricing still applies. A repeat order needs the same customer-specific pricing as a fresh one, not a stale copy of old numbers.
• The shorthand is personal. "The blue ones" means one thing at the café and another at the restaurant across town. Recognition has to be per customer, or it's worse than useless.

What are the options?

Ask customers to use a template. Costs nothing, helps a little. But customers who write "the usual" do it precisely because they won't fill in a form — adoption is partial at best.

Set up standing orders in a portal or ERP. For truly fixed, scheduled replenishment with predictable accounts, this is the right tool. Its limits: it needs setup per customer, it only fits orders that genuinely don't change, and it does nothing for the ad-hoc "the usual" sent by message — and many buyers won't log into a portal at all.

Recognize "the usual" from history. Read the repeat request, identify the customer, propose a draft from their pattern, apply their pricing, and flag it for a person to confirm. This handles how repeat orders actually arrive — no template compliance, no customer login. It's what PeasyOrders does.

How PeasyOrders handles repeat orders

PeasyOrders is built for the "the usual" case, not for scheduled standing orders:

• The history is there from day one. When you connect QuickBooks Online, PeasyOrders reads your past invoices once — so each customer's buying pattern already exists before their first email arrives. (The pricing proposed from those invoices applies only once you accept it.)
• It learns each customer's shorthand in use. Every confirmed correction teaches it one mapping — that customer's phrase to your item. After a few orders, the same phrase arrives already resolved, with the alias shown as the line's source. There's no alias list to import, because nobody has one written down.
• It proposes, with changes made explicit. "The usual plus 2 more cases" becomes the pattern plus a visible change, priced with that customer's current rules.
• A person confirms. Usuals drift, and silent repetition is how wrong orders ship. Anything ambiguous or changed is flagged; nothing exports until you approve it.

What "the usual" resolves to

Say a café emails "the usual plus 2 cases of the IPA." For a known account, that becomes a draft you can read at a glance:

Every line priced at that café's rate, ready to confirm — not rebuilt from memory. The confirmed order exports to QuickBooks Online as an Estimate by default, or to Google Sheets or CSV.

The honest boundary: PeasyOrders speeds up the repeat orders your customers send; it doesn't auto-place orders no one asked for, and it doesn't capture calls — a phoned "usual" is added in one click by your team, and the history and pricing take it from there.

When are standing orders the right call?

To be fair to the other approach: if you have accounts whose orders genuinely never change — same items, same cadence, no exceptions — a true standing order in a portal or ERP is the cleaner fit, because it removes even the reorder step. Use that for the predictable core, and use capture to recognize the long tail of "the usual" that still arrives as a message. Most distributors have both.

The bottom line

Most recurring-order pain isn't about scheduling — it's about a customer writing "the usual" and someone rebuilding that order by hand. Automate it by recognizing the customer's pattern from their history, applying their current pricing, and proposing a draft a person confirms. Keep true standing orders for the accounts that never change, and stop spending your week re-deriving orders the system has already seen.