Describe the inventory before the orders
List the products and variations that need to be tracked separately. Include approximate dimensions, weights and expected inbound quantities where you know them. State whether stock arrives as individual units, mixed cartons, full cartons or pallets.
Explain the identifiers already in use—SKU, barcode, label or another reference—and note any special handling, restricted goods or tracking requirements.
Do not assume every product can be accepted. Suitability, receiving arrangements and any special conditions should be reviewed before stock is sent.
Explain the order pattern
Share the expected number of orders, typical items per order and any known peaks. If the program is new, estimates are fine as long as they are labelled as estimates and the assumptions are clear.
Separate very different order types. A one-time bulk shipment to an office is not the same operation as hundreds of individual employee kits or a continuous stream of customer orders.
Include destination countries or regions and any common delivery constraints. The geography can affect the operating model even when the products are identical.
Define the packing and assembly rules
Describe what has to happen after an order is released. List the packaging, inserts, gift messages, protective materials and any assembly steps.
If there are several kit versions, explain how they differ and how the correct version is identified. If presentation matters, provide a packing reference or approved sample so the intended result is repeatable.
Also identify who supplies each component and who is responsible for replenishment. A warehouse can have plenty of product stock and still be unable to complete an order if the required insert, carton or printed card is missing.
Set the information and reporting requirements
Explain how orders or release instructions will be provided and what information your team needs back. If a system connection is important, describe the workflow you expect rather than listing a platform name and assuming an integration exists.
Define the data fields, update frequency and responsibility for maintaining them. A live portal, real-time synchronization or automated ordering should be treated as a requirement to review, not as an assumed feature.
The same applies to reporting. Decide whether you need periodic stock balances, dispatch confirmations, exception reports or another agreed summary.
Include the exception path
Fulfillment is easy to describe when every order is perfect. A useful inquiry also explains what should happen when something is wrong.
Think through incomplete addresses, cancellations, stock differences, damaged items, missing components and returns. State who is allowed to approve a change and when an order should be held instead of improvised.
For returns, specify the work you actually need: receipt, identification, inspection, repacking, restocking, hold or another agreed disposition. Each activity creates a different handling requirement.
Compare the whole scope, not one headline rate
When proposals arrive, compare the units and scope behind the price. Review receiving, storage, picking, packing, assembly, packaging materials, shipping, reporting and any other stated charges.
Check operating schedules, dispatch commitments, unusual-work rules and exit arrangements. A low pick fee does not describe a program if the rest of the required work sits elsewhere in the quotation.
07 · Checklist
What to bring to the first conversation
A useful first fulfillment brief can be simple:
Tick what you already have
Keep recipient address files and unnecessary personal information out of the initial public inquiry. Once the program is scoped, agree the appropriate transfer process. Branding Czars can then review the operating model before the quotation is treated as a simple price-per-order comparison.
