diff --git a/WorkflowsOrdersBuyerClaim.md b/WorkflowsOrdersBuyerClaim.md
new file mode 100644
index 0000000..9c1fba3
--- /dev/null
+++ b/WorkflowsOrdersBuyerClaim.md
@@ -0,0 +1,36 @@
+# Buyer Claiming
+
+Eventually for each OrderProduct it will need to be determined who is responsible for purchasing the product from the vendor in order to fulfill the customer's order.
+
+Some shops will be lucky enough to have computer-automated ordering, in which case some non-human "user" may be the buyer.  This level of automation is left up to the imagination of each organization for now...
+
+Most smaller shops though will not be so lucky, and will need to instead provide manual steps in their workflow for the buyer to claim the products for purchase.  This document describes some ideas toward that end.
+
+## The Basics
+
+ 1. Buyer applies filter to queued OrderProducts so as to discover those of interest.
+ 1. Buyer selects OrderProduct(s) and signifies his/her intention to take responsibility for their purchase.
+ 1. A new OrderProductEvent is created for each OrderProduct, to log who claimed it.
+
+## The Claim Interface
+
+It is assumed that each OrderProduct will at some point have a status of "awaiting buyer claim" or something similar.  All such OrderProducts will then be available for claiming via a user interface.  The buyer will select the vendor for which they're assembling a purchase order; this will be used to filter the list of OrderProducts shown to the buyer.  The buyer may wish to further filter the products shown according to department, etc.  Some shops may also wish to pre-filter the OrderProducts so the buyer can only see certain ones.
+
+ 1. Buyer selects a Vendor for which they are assembling a purchase order.
+ 1. List of OrderProducts is pre-filtered if necessary.
+ 1. Buyer applies filters to list of OrderProducts if necessary.
+ 1. Buyer selects and claims OrderProducts which they will include on their purchase order.
+ 1. A "buyer claimed" OrderProductEvent is logged.
+
+## Purchase Orders
+
+Some shops may wish to identify the BuyerClaimBatch with a PurchaseOrder within the system.  How this happens will depend though, perhaps on many things.  The buyer may also be responsible for creating the PurchaseOrder within the system, or they may provide paperwork to another worker whose task that is.  Regardless, if this step is required then it may look like the following:
+
+ 1. A PurchaseOrder is identified (created or ETLed if necessary) within Rattail.
+ 1. The BuyerClaimBatch is identified within Rattail.
+ 1. The BuyerClaimBatch is attached to the PurchaseOrder.
+ 1. `OrderProduct.status` is set to "on order" or similar, for each OrderProduct within the BuyerClaimBatch.
+
+## Unavailabilities
+
+Sometimes it is known very soon in the purchasing process (e.g. as soon as the purchase order is submitted to the vendor) that some products are in fact not available at this time.  If any of these should happen to represent OrderProducts, it is probably important that the OrderProduct(s) be re-queued as soon as it is known so that the next purchase attempt can be made as quickly as possible.  Any OrderProduct thus re-queued will once again await buyer claim.