A web-enabled store lets online information support physical retail work: finding products, reserving stock, preparing pickup orders and handling returns. Start by mapping one purchase from the customer's screen to the store shelf. Decide which system owns each fact and what staff should do when updates are late.
Assign an owner to each business record
| Record | Decision to make | Evidence that it works |
|---|---|---|
| Product and variant | Which system owns names, SKUs, sizes, images and barcodes? | The same exact variant is identifiable online, at POS and on the shelf. |
| Price and promotion | Where is each channel price maintained? | A test order shows the intended price and any documented channel difference. |
| Inventory | Which system determines sellable stock at each location? | Sales, reservations and receipts produce explainable quantities. |
| Order and payment | Where are order identity, payment status and fulfillment status tracked? | Staff can distinguish accepted, paid, prepared and completed states. |
| Customer message | Which event sends each confirmation? | The message reflects what has actually happened. |
| Return and refund | Who authorizes the refund and when can stock be resold? | Refund and stock disposition are recorded separately and reconciled. |
Write down the owner even if one platform handles everything. Integrations, apps and spreadsheets can become competing editors when responsibility is implicit. Use permissions so that routine staff work does not require broad access to settings or customer exports.
Make stock promises conservative and explainable
Physical stock, sellable stock and incoming stock answer different questions. A product reserved for pickup is still on a shelf but already promised. A damaged return can be physically present while unavailable to sell. An order on its way from a supplier may arrive too late for today's pickup request.
As a concrete system example, Shopify documents available, committed, unavailable and incoming stock separately. Use those distinctions to ask what your own connector sends, how often it updates, and which events release a reservation.
A shared catalog alone cannot settle concurrent sales. Depending on the system, you may need reservations, a small availability buffer, pickup confirmation after staff locate the item, or a combination. Decide the promise first, then verify the system can support it.
Trace pickup and return events end to end
- Order accepted: create a stable order identifier and record the selected location and payment status.
- Stock reserved: remove the committed quantity from what other customers can buy under your chosen policy.
- Item located: staff scan or check the exact variant, inspect it and put it in the designated holding area.
- Ready message sent: communicate location, hours, collection deadline and identification or authorization requirements.
- Collected: verify the order using the established process and record fulfillment once.
- Canceled or expired: follow the cancellation/refund policy and release stock only when appropriate.
For returns, separate money movement from inventory movement. An accepted refund does not establish that a product is saleable. Inspect the item, assign it to available, unavailable or another documented state, and verify that the online quantity reflects the result.
Ask how duplicate messages, retries and partial failures are handled. A connector should be able to recognize that a particular event was already processed, so retrying a delivery does not create another order or refund. Keep identifiers in support logs while limiting customer data to what staff need.
Write an outage procedure for the actual equipment
List what remains usable when the internet, payment connection or inventory connector fails. Treat these as separate failures. Record who can pause pickup orders, revise availability, switch to an approved backup connection and authorize exceptional handling.
For example, Shopify's offline-feature documentation says that orders and inventory cannot sync to the admin while POS is offline. It also describes limits on pickup fulfillment and returns. Card processing behavior depends on hardware and configuration. Check the current provider guidance for the exact installation.
Follow the provider's instructions for retaining offline transactions and reconnecting. Avoid improvised collection of card details. After recovery, verify order counts, stock, payment status and any failed transaction requiring follow-up before declaring the incident closed.
Launch with a small, observable pilot
Choose a limited group of products and a quiet operating period. Use test modes where the providers support them; label test records so they are excluded from real demand reporting. For each case, write the expected stock, order and payment state before running it.
| Test | Expected evidence |
|---|---|
| Ordinary online pickup | One order, correct reservation, ready message after preparation and one fulfillment. |
| Last item sold through two channels | A documented conflict outcome, correct customer communication and reconciled stock. |
| Cancellation before collection | Correct refund decision and reservation release. |
| Damaged return | Refund processing separated from the decision to make stock sellable. |
| Interrupted connection and retry | Retained records, recognized duplicate events and a reconciled result after recovery. |
| Restricted staff account | Staff can complete assigned tasks while protected settings remain restricted. |
Download the integration test record (plain text). It provides space for expected and actual results, evidence, owners and unresolved issues. Expand the rollout after the pilot passes and staff can explain how to resolve exceptions.
Monitor practical outcomes: stock conflicts, uncollected orders, preparation time, failed syncs and unreconciled payments. A connection is useful when the customer promise survives ordinary mistakes and interruptions.