Products May 28, 2026

Why We Built Held Orders — How Order Drafts Changed Rush Hour

Customer is still deciding, but the queue keeps moving. Without held orders, the cashier is trapped: wait or skip. Here's the story of a seemingly simple feature that changed how cashiers handle rush hour.

C
CrescendPOS Team

A Problem That Seems Small

This scenario happens every day in almost every cafe: the customer at the front is still deciding what to order. Behind them, 5 people who already know exactly what they want. What does the cashier do?

Without held orders, the cashier has only two options — both bad:

  • Option A: Wait. Cashier waits for the customer to finish deciding. 5 people behind them wait. 30 seconds turns into 2 minutes. Queue grows.
  • Option B: Skip. Cashier says "take your time" and moves to the next person. But now the cashier has to remember: "that customer will come back, and they already chose 2 items but weren't done." Where does this info live? In the cashier's head. Which is already full with 10 other things.

This seems like a small problem — but during rush hour, every customer who holds up the queue has a ripple effect on everyone behind them.

What We Built: Orders You Can "Park"

The concept is simple: a cashier can start an order, then "park" (temporarily save) it without finishing or processing payment. The order is stored as a draft — resumable at any time, by the same cashier or a different one.

The flow:

  • Customer A starts ordering → cashier enters 2 items → Customer A is still thinking
  • Cashier holds Customer A's order → automatically moves to a fresh screen for a new customer
  • Customer B orders → cashier enters it → payment → done
  • Customer C orders → cashier enters it → payment → done
  • Customer A returns → cashier opens the draft → continues from the 2 items → done

Nothing is lost. Nothing needs to be remembered. Nobody blocks the queue.

Why This Isn't as Simple as It Looks

From the outside, held orders look straightforward: "just save it." But there were design decisions we debated for a while:

Question 1: How Long Should Drafts Last?

If drafts last forever, the held orders list fills with abandoned orders that never get resumed — creating clutter. If they expire too quickly, customers who genuinely intend to come back lose their orders.

We settled on: drafts last for the duration of the shift. When the shift closes, all unresolved drafts are automatically cleared. This makes sense because: if a customer doesn't return before the shift ends, they probably won't.

Question 2: Who Can Resume a Draft?

Option A: only the cashier who created the draft can resume it. This is "safe" but limiting — if that cashier takes a break or their shift ends, the draft is stuck.

Option B: any cashier can resume any draft. This is more flexible and fits the reality of F&B operations where cashiers frequently overlap or alternate.

We chose Option B. The reasoning: in small cafes, cashiers often overlap or take turns. A draft locked to one person is an unnecessary bottleneck.

Question 3: How Does the Cashier Know Which Draft to Resume?

If there are 5 drafts, the cashier needs to identify which belongs to the returning customer. We use labels — the cashier can tag a draft with a name or note ("woman in red shirt", "Table 3", "Andy"). Labels are optional but very helpful when the queue is busy.

Effects We Didn't Anticipate

After held orders went live, some uses emerged that we didn't expect:

  • Table pre-orders. A server walks to a table, enters the order on a tablet, holds it — then the customer confirms and the cashier finalizes. A flow we didn't design but that works naturally.
  • Incremental orders. Customer orders coffee first, 30 minutes later adds food. Cashier resumes the same draft, adds items — everything stays in one order, one receipt.
  • "Save my order." Customer who wants to pay later (waiting for a friend to split the bill) asks the cashier to hold it. Cashier moves on to serve others.

Impact on Throughput

We don't have exact numbers from an A/B test (this feature launched for all users), but from cafe owner feedback:

  • Customers "blocking" the queue decreased significantly. Cashiers are no longer stuck waiting for one person — they can always stay productive.
  • Cashiers are more confident during rush hour. They know that if a customer isn't ready, there's a proper mechanism — not improvisation.
  • Less mental load. Incomplete order information lives in the system, not in the cashier's head. This lets them focus entirely on the customer in front of them right now.

Why "Simple" Features Are Often the Most Impactful

Held orders aren't flashy. Nobody ever bought a POS because of held orders. But it's an example of our design philosophy: the most impactful features are often not the most visible — but the ones that remove friction that happens most frequently.

Rush hour is a stress test for the entire cafe operation. Every friction during peak time is amplified — and every friction removed is also amplified. Held orders remove one friction (undecided customers blocking the queue) that occurs multiple times per shift. The small impact multiplies.

The Bottom Line

Held orders solve a specific problem: a customer who isn't ready to order shouldn't halt the entire queue. The solution is simple in concept (park the order, resume later), but there's nuance in implementation (how long do drafts last? who can resume? how to identify them?). And the impact — less blocking, less mental load, more throughput — is felt most strongly at the moment that matters most: rush hour.