E-commerce Operations & Fulfillment

Welcome to the workshop. This course is for Kaern founders who are running, or about to run, a real online store and who are tired of watching orders pile up faster than they can ship them. Over six modules we move from the storefront all the way to the loading dock and back again through the returns door. By the end you will be able to build a clean product catalog, take payment without breaking compliance, process orders without losing your mind, hold the right amount of stock, ship it for the right cost, and turn returns and support into a growth engine instead of a drain.

I am Otto, your tutor. I spent years in the back office of bicycle-cleaning hardware shops — yes, real machines, real pallets, real customers who emailed at 2 a.m. asking where their parcel was. I ran a live Shopify store (shop.cyclewash.com), reconciled the payouts, and packed the boxes myself when the warehouse was short-staffed. Everything here is what I wish someone had drilled into me before I learned it the expensive way. We will use a running example: a Kaern startup selling a compact washing system called the Mini Platinum and a full-size one called the Pro Platinum, plus a line of care products. Bring a notebook. I will keep asking you questions, because operations is a discipline of habits, not heroics.

Module 1 — The Store & Catalog

Learning objectives

• Structure a product catalog with correct variants, SKUs, and collections.
• Write product data (titles, descriptions, specs) that reduces support tickets.
• Configure store-level settings (currencies, markets, tax regions) before launch.
• Understand how catalog hygiene feeds every downstream operation.

Lesson 1.1 — The catalog is your warehouse map

Teaching script (Otto's voice): Picture a librarian who shelves books with no call numbers — just piles by the door. That is a store with a sloppy catalog. Every order, every pick, every stock count later in this course depends on one thing: that each item has a single, unmistakable identity. In Shopify that identity is the SKU and the variant. The Mini Platinum in blue and the Mini Platinum in yellow are not "two products" — they are one product with two variants, each with its own SKU like MINI-PLAT-BLU and MINI-PLAT-YEL. Why does this matter so much? Because when a customer orders, the warehouse reads the SKU, not the pretty title. If your blue and yellow share a SKU, you will ship the wrong colour and eat the return shipping. Get the skeleton right now and the next five modules glide. Get it wrong and you will be untangling it during your busiest week. So: how many genuinely distinct, individually-stockable things do you sell — and does each one have exactly one SKU?

Worked example: Mini Platinum sold in 2 colours and 2 voltages = 1 product, 4 variants. SKUs: MINI-PLAT-BLU-230V, MINI-PLAT-BLU-110V, MINI-PLAT-YEL-230V, MINI-PLAT-YEL-110V. Each variant carries its own barcode, weight (28 kg), and inventory count. The product title stays "Mini Platinum"; the variant options ("Colour", "Voltage") drive the storefront selector.

Hands-on exercise: Take three of your real products. In a spreadsheet, list each product, its variant options, and a unique SKU per variant using a consistent pattern (PRODUCT-OPTION1-OPTION2). Flag any place where two physically different items would share a SKU.

Common mistakes:

1. Using the same SKU across variants, making stock counts meaningless.
2. Encoding price or supplier into the SKU (these change; the SKU must not).
3. Creating a separate product for every colour, splitting reviews and inventory.

Check for understanding:

1. Why must the SKU, not the title, drive fulfillment?
2. What belongs in a variant versus a separate product?
3. Name one piece of data that should never be baked into a SKU.

Lesson 1.2 — Product data that prevents tickets

Teaching script (Otto's voice): A product page is not marketing fluff — it is your cheapest customer-service agent, working 24/7. Every fact you leave off the page becomes an email you have to answer. When I ran the cycleWASH shop, the Pro Platinum's "Does it fit a 29-inch wheel?" question came in weekly until we put the clearance dimensions in a spec table. The emails stopped overnight. Think of the description as a contract: it sets the customer's expectation, and a return is what happens when reality breaks that contract. So write the dimensions, weight, power requirements, what's in the box, and the warranty terms plainly. Add the boring numbers people actually need to decide. The fancy lifestyle photo sells the dream; the spec table prevents the refund. Which question do your customers ask most often before buying — and is the answer already on the page?

Worked example: Pro Platinum page gains a spec table: dimensions 1.8 m × 0.9 m × 2.1 m, weight 140 kg, power 230 V / 16 A, water connection 3/4", "In the box: machine, hose kit, 5 L starter detergent, mounting bolts." Pre-sales tickets for that product drop from ~8/week to ~1/week.

Hands-on exercise: Pull your three most recent pre-sale support questions. For each, locate where the answer would naturally live on the product page and draft that sentence or table row.

Common mistakes:

1. Listing features but omitting hard specs (size, weight, power).
2. Inconsistent units across products (cm here, inches there).
3. Burying "what's in the box," driving "is the hose included?" emails.

Check for understanding:

1. How does a spec table reduce operational load?
2. Why frame the description as a contract?
3. Give one fact whose absence reliably generates tickets.