This is the full operational story behind the Inmotionworld case study. The headline number is 2,500-plus SKUs fully automated in four weeks. The story behind it is a set of decisions — about naming conventions, integration architecture, and routing logic — that determined whether the system would hold under real production load. Here is exactly what the situation was, what we built, and why each decision was made the way it was.
The situation before we started
Inmotionworld sells electric bikes and spare parts across the US market. Strong product demand, a loyal customer base, and growing order volume. The operations infrastructure had not kept pace with the growth. When we arrived, the situation looked like this:
- 2,500-plus SKUs with no consistent naming convention — some named by product, some by supplier code, some by a system the original team had abandoned
- Inventory tracked in spreadsheets that were updated manually and were typically one to two weeks out of date
- Every order required multiple staff members to touch it before it shipped — someone to check inventory, someone to decide which warehouse, someone to generate the label
- No stock threshold alerts — stockouts were discovered when customers complained or when staff noticed during manual checks
- Fulfilment errors were increasing as volume grew — wrong warehouse, wrong carrier, wrong tracking number sent to the customer
The decision that came before everything else: SKU structure
The instinct when looking at a broken operations system is to connect the tools first and clean up the data later. That instinct is wrong, and acting on it is how you end up rebuilding the integration six months later. Before we connected Shopify to Cin7, we renamed every SKU in the catalogue. All 2,500 of them. The naming convention we built encodes four pieces of information: product category (BIKE, PART, ACC), product identifier, variant code, and warehouse location code. Every SKU now tells the system — and any human reading it — exactly what the product is and where it lives. This sounds like a tedious administrative exercise. It is. It is also the foundation that every automated decision downstream depends on. When ShipStation routes an order to a warehouse, it is reading a SKU. When Cin7 fires a Slack alert at a stock threshold, it is referencing a SKU. When the Shopify storefront shows stock availability, it is reading from a SKU-matched inventory record. Get this wrong and every downstream automation is unreliable. Get it right and the automation is stable indefinitely.
The integration architecture
With the SKU foundation in place, we built a four-layer system. For the full technical setup of this integration, our Cin7 Shopify integration guide covers every step of the Cin7 side in detail.
- Shopify: all customer-facing orders captured here. No changes to the storefront were required — the integration operates entirely in the back end.
- Cin7: connected to Shopify via the native integration. Shopify orders arrive in Cin7 automatically. Cin7 is the source of truth for inventory levels and pushes stock updates to Shopify on a trigger basis with a buffer to prevent overselling during sync delays.
- ShipStation: connected to Cin7 for fulfilment instructions. When Cin7 assigns an order to a warehouse, ShipStation receives the instruction, selects the correct carrier based on product type and destination, generates the label, and pushes the tracking number back to Shopify to trigger the customer notification.
- Zapier: the alert and exception layer. Stock thresholds fire Slack notifications to the relevant warehouse manager when inventory on any SKU falls below a defined level. Order exceptions — failed label generation, missing tracking, payment holds — fire to a dedicated Slack channel so nothing falls through the gaps silently.
The routing logic — the decision that makes multi-warehouse work
Inmotionworld ships from multiple US warehouses. Before the integration, warehouse selection was a manual human decision on every order. The person making that decision was not always right, and the wrong decision meant a longer delivery time or a higher shipping cost. We built routing rules in ShipStation that made the decision automatically based on two inputs: the customer's delivery zip code and the product type. Bikes route to the nearest warehouse with stock. Spare parts route to the warehouse with the deepest inventory on that SKU to reduce split shipments. The rules are configured once and run on every order without human review. The staff decision that used to happen on every single order now only happens when the automated routing cannot match a rule — which is rare and handled via the exceptions Slack channel.
The alert system — replacing manual discovery with proactive visibility
Before the integration, stockouts were discovered one of two ways: a customer complained, or a staff member noticed during a manual check. Both are too late. The Zapier layer we built replaced reactive discovery with proactive thresholds. When any SKU in Cin7 falls below its defined threshold — set at two weeks of average sales velocity — a Slack notification fires to the warehouse manager for that product category, including the current stock level, the SKU, and a link to the Cin7 purchase order creation screen. The threshold is calculated from 90-day sales data and updated quarterly. This one piece of the system — which took approximately four hours to build — has a higher operational impact per hour spent than almost anything else we implemented. Stockouts do not happen by surprise anymore. They are prevented.
What the team's work changed to
The goal of an operations integration is not to reduce headcount. It is to change what the team spends its time on. Before the integration, the Inmotionworld operations team spent the majority of their time on: checking inventory manually, deciding which warehouse to use on each order, chasing tracking information, handling stockout complaints, and reconciling spreadsheet errors. After the integration, none of that is routine work anymore. The team handles exceptions — orders the system could not route, supplier delays that need renegotiation, customer service escalations that require judgement rather than data lookup. The routine work runs automatically. The judgement work is done by people. That is the correct division of labour in a modern ecommerce operation.
The numbers after four weeks
The integration was live and processing real production volume within four weeks of starting. The results at that point:
- 2,500-plus SKUs renamed, catalogued, and syncing correctly between Shopify and Cin7
- Zero manual order touches from receipt to dispatch — every order now routes automatically
- Real-time inventory visibility in Shopify reflecting Cin7 stock levels with a defined buffer
- Stock threshold alerts active on every SKU — stockouts now prevented rather than discovered
- Fulfilment errors reduced to near zero — automated routing eliminated the wrong-warehouse and wrong-carrier mistakes
The Inmotionworld system is not technically exotic. It uses four tools that are widely available: Shopify, Cin7, ShipStation, and Zapier. What makes it work is the sequence — SKU structure before integration, routing logic before go-live, alert system as the last layer — and the specificity of the configuration. The difference between an operations stack that runs cleanly and one that creates daily problems is not the tools. It is the decisions made before the tools are connected. If you are facing the same operational constraints, our Shopify operations services cover this exact type of engagement.