Amore OMS

Context

The client operates multiple storefronts and ships across different European markets. Order intake, fulfillment and carrier dispatch were split across platform-specific tools and carrier-specific workflows. As volume increased, the operational overhead grew with it. The main pain was not a missing feature, but the lack of a single operational view and predictable state handling.

Problem

The core problem was not a lack of features, but lack of control and reliability.

• Orders were ingested from storefronts without a normalized internal representation.
• Carrier dispatch required different steps per provider (labels, formats, tracking).
• Warehouse workflows (picking/packing) were hard to standardize without tooling.
• Address and phone formats varied by country, creating avoidable delivery failures.
• The operation lacked a reliable way to reconcile “stuck” orders (paid but not shipped, shipped but not tracked).

Project Goals

• Centralize order management across storefronts into one operational system.
• Create a predictable order lifecycle with explicit states and exceptions.
• Standardize warehouse flows (batching, scanning, packing) to reduce human error.
• Integrate multiple carriers with consistent dispatch and tracking behavior.
• Enable expansion to new markets/carriers without rewriting the core system.

Constraints & Challenges

• No downtime for storefront order intake.
• Multiple VAT rates and country-specific shipping rules/exceptions.
• Multiple payment types (including COD) and operational variants per market.
• Different carrier APIs, label formats and tracking identifiers.
• Legacy data and inconsistent payloads from external systems.

The solution had to coexist with the existing environment before gradually becoming the primary operational system.

Solution Overview

We designed and built a custom OMS that acts as an operational control layer between storefronts and logistics. The OMS does not replace storefronts. It orchestrates fulfillment: ingestion, normalization, state tracking, dispatch, tracking and operational workflows.

• Single source of truth for order state
• Explicit state transitions and reconciliation
• Verified inbound events (webhooks) and deterministic updates
• Clear separation between ingestion, operations, and carrier integrations

Architecture & Technical Approach

The system is implemented as a pragmatic operations web application backed by a relational database. The core of the design is the data model: orders, sites, statuses, batches, products and carrier artifacts.

• Order ingestion: verified webhooks for storefront events and order creation, with duplicate protection.
• Normalization: consistent internal representation (addresses, phone numbers, country/VAT rules, SKUs).
• State management: explicit statuses and exception handling for operational predictability.
• Operational UI: filtering, triage, batch preparation, and per-order actions for the operations team.
• Warehouse tooling: barcode scanning and batch workflows for packing/dispatch.
• Carrier layer: integrations for label generation, tracking assignment, cancellation and tracking updates.
• Background jobs: scheduled reconciliation and tracking updates to finalize “on-hold” operational states.

Each integration is isolated, allowing changes without impacting the core system. This structure supports gradual rollout and predictable extensions (new storefronts, carriers, markets).

Technology Stack

• Backend: PHP
• Database: MySQL
• UI: Server-rendered internal web UI (MDL + JS utilities)
• Background jobs: Cron-based scheduled tasks
• Integrations: Shopify webhooks + multiple carrier APIs/SDKs (DPD, GLS, Packeta, UrgentCargus, BRT), tracking exports/imports
• Documents: PDF generation for operational artifacts (labels, documents)

Technology choices prioritized stability, maintainability and team familiarity over experimental solutions.

Implementation Process

1. Business process analysis and mapping
2. Definition of order lifecycle and states
3. Incremental implementation of ingestion, internal data model, and operational UI
4. Carrier integrations added one by one with consistent abstractions and fallbacks
5. Gradual rollout of warehouse tooling (batching, scanning) and background reconciliation

Regular checkpoints with the client ensured alignment between technical decisions and operational reality.

Results & Impact

• Reduced manual order handling and fewer dispatch errors.
• Better transparency for operations and support teams (one place to see order state).
• Faster onboarding of new carriers/markets due to explicit integration boundaries.
• A stable foundation for automation and operational reporting.

The OMS became a critical part of daily operations.

Reflection

The decision to focus on orchestration instead of replacement proved crucial. It minimized risk and allowed the client to gain value early in the project. With hindsight, the most impactful investment was the detailed upfront modeling of order states and transitions, which reduced operational ambiguity throughout development and future changes.

Summary

This project demonstrates how a well-designed custom system can bring order and stability to complex e-commerce operations without disrupting existing business. It highlights a pragmatic, architecture-driven approach to solving real operational problems.