Introduction

Picture a retail footprint spread across an archipelago of more than 17,000 islands. Now add several brands (Adidas, Coach, Mothercare, Havaianas, Nespresso, and more) each with its own catalog logic, customer expectations, and place in the portfolio. Then spread all of that across 300+ stores, warehouses, and a growing online business. That's Kanmo Group's starting point in Indonesia.

Before any conversation about order management systems, this is the operational reality: fulfillment processes that grew brand by brand, store by store, without a shared backbone. Shipping costs that climb when every brand routes independently. Stock sitting in one location while a customer order in another location goes unfulfilled, because there's no unified view across stores, warehouses, and brands to route it correctly. Orders shipped from the wrong islands, where shipping costs exceeded the cart value, because no system was checking which node made economic sense before it committed the fulfillment.

‍

Why implementation was the real question

When the starting point looks like this — multiple brands, island logistics, several existing systems that don't talk to each other — an obvious question is: will the rollout itself stay manageable?

That's the question worth asking before any vendor conversation, and it's the one this implementation had to answer in practice. Complexity in the starting point doesn't automatically mean complexity in the rollout, but only if the project setup and the architecture underneath it are built to absorb that complexity rather than multiply it.

‍

The starting point 

Kanmo's situation combined three layers of complexity that typically show up separately, not together:

• A multi-brand portfolio spanning international names (Adidas, Coach, Nespresso) and local ones (Mothercare, Havaianas), each with different operational needs.
• A geographic challenge: an island nation, meaning long and often costly shipping routes between stores, warehouses, and customers.
• Fragmented systems: no single, real-time view of inventory and orders across stores, warehouses, and brands, which meant decisions about where to fulfill an order were made with incomplete information.

Kanmo had run a previous OMS solution that needed to be replaced because it didn’t fit Kanmo’s needs. With Magento already in place as the shop system, the search was for something that could integrate easily rather than force a rebuild.

‍

How the implementation was set up

Two things shaped the OMS implementation:

Project setup first. Before touching configuration, Kanmo worked out internally how the project should be structured and who would own what. fulfillmenttools supported this in joint meetings, helping identify the right integration endpoints rather than assuming Kanmo's team already knew the fine details of an OMS rollout.

Get it running, then optimize. Rather than trying to perfect every configuration before go-live, the approach was pragmatic: establish a working setup, confirm it holds, and refine from there. Existing resources were allocated where they mattered most instead of spread thin across every detail at once.

The implementation ran across three parties in three time zones:

• Codilar, the implementation agency, integrated the shop system.
• Kanmo integrated inventory data and marketplace connections themselves.
• fulfillmenttools provided the OMS platform as the basis for the rollout

Three parties, three time zones, one integration to coordinate. That's the kind of setup that usually means constant sync calls and blocked work. It didn't here, because fulfillmenttools defined the API endpoints up front and Codilar and Kanmo each built against them on their own schedule, without waiting on each other or on us.

Multi-brand routing logic didn't require a separate build per brand. It's handled as configuration within the fulfillmenttools routing itself. It works as one platform, with brand-specific rules set up rather than engineered from scratch each time.

‍

What made the rollout manageable

A few structural decisions did the heavy lifting:

• One platform instead of per-brand island solutions. Every brand runs on the same OMS logic, configured rather than custom-built, which is what kept six brands from becoming six separate projects.
• Ship-from-store as a lever. With inventory visible across all locations, stores themselves become fulfillment points and directly address the shipping-cost problem that comes with archipelago logistics.
• A pragmatic rollout philosophy. Getting a working baseline live before optimizing avoided the trap of trying to design a perfect system before anyone had real usage data to design against.

‍

Results

In the first four months, Kanmo saw an increase in orders successfully routed through the system, reduced shipping costs through ship-from-store, and a more consistent customer experience thanks to a unified view of orders across brands and locations.

‍

The takeaway

A complex starting point doesn't have to mean a complex rollout. What determines that isn't the complexity itself — it's whether the architecture and the project setup are built to handle it: one platform instead of six, clear ownership from day one, and a rollout that gets something working before it tries to get everything perfect.

‍

[cg_inject-el="card"]