Handle review exceptions#

Most StackCube setup improvements come from repeated review exceptions. Treat every exception as either an order decision or a setup signal. Do not approve a shipment-affecting order just to clear the queue.

StackCube review flags and approval controls — Review flags, order amount, order state, approval, and rejection controls should guide exception handling before fulfillment.

Unknown customer#

Pause approval when the sender, login ID, or file source cannot be tied to one customer record.

Check whether the customer exists under another name, whether the buyer used a new email or phone number, and whether the order belongs to a related branch. If the customer is new, create the customer record before approving the order.

Unmatched item#

Do not approve a line when the item affects shipment and the match is uncertain.

Use the source message, attachment, prior orders, and catalog aliases to decide whether to correct the line, reject the order, or leave approval pending. After a repeated correction, add the alias to the catalog instead of fixing the same line again.

Price mismatch#

Price exceptions should be reviewed as policy decisions. A reviewer can correct a typo, but a repeated override usually means the customer price tier or tier rule is missing or outdated.

Before approving, confirm whether the submitted price, configured item or tier price, or sales agreement is the source of truth. Record the decision so the next reviewer does not repeat the same discussion.

Duplicate-looking orders#

Hold the order when the same customer, same item, and similar quantity appear close together.

Check the original message and any follow-up messages. Some duplicates are corrections, but some are intentional repeat orders. Approve only when the source evidence makes the intent clear.

When to reject#

Reject instead of editing when the source is clearly not an order, the customer cancels, the item cannot be identified, or the requested fulfillment would violate the agreed operating policy.

Record the operational reason in the order memo or internal operating notes. The next reviewer should understand why the order did not move forward.

Improve setup after review#

At the end of each day, group repeated exceptions:

Add customer aliases or contact links for repeated unknown sender issues.
Add item aliases for repeated unmatched item names.
Update customer price tiers or tier rules for repeated approved price overrides.
Adjust channel instructions when customers keep sending incomplete orders.