Shipping Fulfillment Workflow

Use this runbook when a workspace sells physical products and operators need to ship, track, return, or refund orders through Sophosic.

Outcome

At the end:

• Shipping settings are ready for checkout and fulfillment.
• Product parcel details support rate shopping and labels.
• A paid order can move from ready to ship to fulfilled.
• Operators can buy a single label or batch labels.
• Customers can view order and tracking status.
• Returns, refund ownership, and troubleshooting paths are clear.

Before You Start

Collect:

• Workspace slug and console URL.
• Public site URL.
• Shipping origin address.
• Supported destination zones.
• Carrier/provider credentials and owner.
• Package sizes, label printer format, and packing process.
• Return policy, refund policy, and restocking rules.
• Payment test boundary approved by the payments owner.

Label buys and return-label buys can create live carrier charges. Refunds can move real money. Do not run those actions against a live workspace unless the owner approves the cost, accounting treatment, and cleanup path.

Step 1: Configure Shipping Settings

Console surfaces: Shipping > Settings, Settings > Shipping.

Actions:

1. Open Shipping settings.
2. Confirm ship-from origin.
3. Set default weight unit and dimension unit.
4. Enable only supported carriers.
5. Configure markup or handling fee.
6. Configure free-shipping threshold if the workspace offers one.
7. Save and reload the page.

Verify:

• The saved origin is the real fulfillment location.
• Units match the team’s scale and label process.
• Carrier list matches the provider account.
• Checkout policy and shipping policy say the same thing.

Failure checks:

• A missing origin blocks rate shopping and label creation.
• A mismatched country or postal code can produce no carrier rates.
• Markup and free-shipping thresholds can make totals look wrong even when rates work.

Step 2: Create Package Presets

Console surface: Shipping > Settings > Packages.

Actions:

1. Add the standard boxes, mailers, or envelopes the team uses.
2. Enter length, width, height, dimension unit, weight, weight unit, and package type.
3. Mark the most common preset as the default package.
4. Save each preset.

Verify:

• The default preset pre-fills label creation.
• Preset names are operator-friendly.
• Package values match the physical supplies.

Failure checks:

• A preset without a weight still requires the operator to add weight before rates can load.
• The wrong default package can silently create bad rates.

Step 3: Configure Product Shipping Settings

Console surface: Products.

For each shippable product:

• Confirm the product requires shipping.
• Enter weight and weight unit.
• Enter dimensions and dimension unit.
• Select package type when needed.
• Configure flat shipping fee if the product has a special rate.
• Confirm free-shipping eligibility.
• Confirm inventory behavior.

Verify on sites:

• The product appears in the shop.
• A non-shippable product does not ask for shipping unexpectedly.
• A shippable product collects a shipping address.
• Checkout totals respond to shipping address and product quantity.

Step 4: Create A Test Order

Sites surfaces:

• /shop.
• /shop/{productSlug}.
• /cart.
• /checkout.
• /checkout/success.

Actions:

1. Add a shippable product to cart.
2. Change quantity.
3. Enter customer and shipping details.
4. Select shipping.
5. Confirm tax, discount, shipping, and total.
6. Complete or stop at the approved payment boundary.

Verify in console:

• Order appears in Orders.
• Payment status matches the test path.
• Shipping address is present.
• Line items and inventory look right.
• The order appears in Shipping when it is paid and ready to ship.

Step 5: Buy A Single Label

Console surfaces: Orders, Shipping.

Actions:

1. Open the order detail page.
2. Confirm payment status and fulfillment status.
3. Confirm ship-to address.
4. Confirm parcel data from product or package preset.
5. Fetch rates.
6. Select the intended carrier service.
7. Choose label format.
8. Decide whether to notify the customer.
9. Buy the label only after owner approval.

Verify:

• Shipment appears on the order.
• Label URL is available.
• Tracking number and tracking URL are present when provider returns them.
• Fulfillment status moves to fulfilled or partially fulfilled.
• Customer order page shows shipment details.

Failure checks:

• Address validation messages.
• Missing or zero parcel weight.
• Missing dimensions for the selected package mode.
• Expired rate.
• Unsupported carrier service.
• Provider credentials or account status.

Step 6: Batch Buy Labels

Console surface: Shipping.

Actions:

1. Open the ready-to-ship queue.
2. Select multiple paid orders.
3. Choose Batch buy labels.
4. Review every row, parcel, and selected rate.
5. Remove unresolved or suspicious rows.
6. Select label format.
7. Confirm customer notification behavior.
8. Buy labels only after owner approval.

Verify:

• Batch detail shows succeeded and failed rows.
• Each succeeded order has a shipment.
• Failed rows are not assumed fulfilled.
• No duplicate labels were bought for the same order.

Failure checks:

• Mixed package needs can make the default preset wrong for some rows.
• One bad address should not block review of the whole queue.
• A failed row should be corrected and retried deliberately.

Step 7: Verify Tracking

Console surfaces: Orders, Shipping.

Customer surfaces:

• /orders.
• /orders/{orderId}.
• /{site}/track/{tracking}.

Actions:

1. Open the order shipment in console.
2. Confirm tracking number, carrier, service, and tracking URL.
3. Open the customer order detail page.
4. Open the public tracking page for the tracking number.
5. Confirm status and event timeline are understandable.

Verify:

• Wrong-workspace or unknown tracking numbers do not reveal another tenant’s shipment.
• Public tracking uses the workspace brand.
• Carrier status changes do not erase operator notes.

Failure checks:

• Tracking can stay pre-transit until the carrier accepts the package.
• Webhook delays are normal; check provider event history before declaring failure.
• Customer-visible status should match the latest saved shipment event, not an operator guess.

Step 8: Complete Order Fulfillment

Console surface: Orders.

Actions:

1. Confirm the packed item matches the order line items.
2. Print and attach the label.
3. Hand off to the carrier.
4. Record internal notes when the handoff is manual.
5. Watch for delivered, returned, or exception events.

Verify:

• Fulfillment status is honest for all items.
• Tracking status reflects carrier progress.
• Customer support can answer from the order page.
• Inventory changes match the shipping outcome.

Step 9: Test Returns And Refunds

Console surfaces: Shipping > Returns, Orders, Payments.

Actions:

1. Open the order and confirm shipment state.
2. Create a return authorization when the customer should send an item back.
3. Buy a return label only when approved.
4. Confirm return tracking appears when available.
5. Receive and inspect the returned item.
6. Decide restock, exchange, partial refund, full refund, or no refund based on policy.
7. Issue the refund through the approved payment path.
8. Record the reason and owner in order notes.

Verify:

• Return/RMA status, shipment status, order status, payment status, and inventory agree.
• Customer notification matches the operator decision.
• Refund amount and reason are visible to the team.

Failure checks:

• A return label does not automatically refund the order.
• A refund does not automatically prove the item was returned.
• Voiding an outbound label is different from refunding the customer.

Step 10: Run Launch QA

Use this before real traffic or a new shipping workflow launch.

1. Products

   Pass condition: Every shippable product has weight, dimensions, package type, inventory, tax, and visibility configured.

2. Shipping settings

   Pass condition: Origin, units, carriers, package presets, markup, free-shipping threshold, zones, and rates are approved.

3. Checkout

   Pass condition: Address entry, shipping options, tax, discounts, and totals match policy.

4. Single fulfillment

   Pass condition: One approved test order can produce a label and tracking entry.

5. Batch fulfillment

   Pass condition: Batch review catches missing data and records success or failure per row.

6. Customer pages

   Pass condition: Order history and public tracking pages show understandable status.

7. Returns

   Pass condition: RMA, return label, restock, and refund owners are known.

8. Support

   Pass condition: Operators know how to answer tracking, delay, damaged item, and refund questions.

Do not launch until every launch-critical workflow has passed, been disabled, or been deferred with owner approval.

Daily Shipping Operations

Run this each shipping day:

1. Open Shipping and review ready-to-ship orders.
2. Confirm paid orders, addresses, and inventory.
3. Buy labels for orders that are ready.
4. Batch buy only after reviewing each row.
5. Pack and hand off shipments.
6. Review in-transit exceptions.
7. Review delivered orders and customer replies.
8. Review returns and refund requests.
9. Record handoff notes for unresolved items.

Troubleshooting

Done Criteria

• Shipping configuration is saved and verified.
• Product shipping fields are complete.
• Checkout can quote shipping.
• A paid order can be fulfilled.
• Label, batch, tracking, return, and refund paths are understood.
• Customer order and tracking pages are verified.
• Operators know daily review and troubleshooting routines.