Skip to content
← Case studies

Electronics / customer expansion / regional fulfilment

Reaching new customers through a connected marketplace

The implementation brief

A major electronics business wanted to reach a new customer segment through an additional marketplace, whilst keeping sales and fulfilment connected across its existing operations. Middleware sat at the centre of the architecture, connecting ERP, ecommerce, the marketplace and multiple warehouses across different regions. A custom API integration brought the marketplace into this wider setup, with AI supporting the build and troubleshooting.

The implementation

ERP, commerce and fulfilment connected through middleware

Implementation architecture
Connected marketplace · central middleware · regional fulfilmentCustom API integrationRegional warehouse network · representative locationsProduct + inventoryrecordsOrder + fulfilment recordsPlaces an orderProducts + inventoryOrders + order updatesShipment + tracking updatesProducts + inventoryOrders + order updatesShipment + tracking updatesOrders → fulfilmentStock + shipment updatesDispatch goodsParcel deliveredERPEnterprise Resource PlanningCustomerNew customer segmentEcommerceExisting commerce operationMiddlewareConnect · map · routeMarketplaceAdditional sales channelWarehouse / Region AWMS · pick, pack & dispatchWarehouse / Region BWMS · pick, pack & dispatchCourier networkDelivery to the customer
Module / recordConnected systemInternal workflowIntegrationPhysical movement recorded

Systems involved

Middleware · ERP · Ecommerce · Marketplace · WMS

Middleware: the central integration hub

Middleware sits at the centre of the architecture, triaging and routing data across ERP, ecommerce, the marketplace and regional warehouses. It maps information into the format each system needs and directs product, inventory, order and fulfilment updates to the right destination, keeping data and operations aligned across the business.

ERP: the consolidated business record

ERP sends product and inventory data to middleware and receives order and fulfilment records in return. This connects sales and warehouse activity with the business’s reporting and reconciliation, whilst middleware manages the exchange with the other systems.

Ecommerce: the existing commerce operation

The ecommerce platform exchanges information with the wider business through middleware. Product and availability updates reach the storefront through this connection; online orders pass back to middleware, which coordinates the relevant fulfilment and ERP records. Shipment and tracking updates return through the same hub.

Marketplace: reaching a new customer segment

The additional marketplace gave the business a way to reach customers through another sales channel. Product listings and availability passed through middleware to the marketplace, whilst orders returned through the custom API integration. Shipment and tracking updates were then sent back to the marketplace, where customers could also initiate cancellation, return and refund requests.

Regional warehouses and WMS: connected fulfilment

The business operated multiple warehouses across different regions, with WMS connections linked to middleware. These links carried fulfilment instructions and returned stock and shipment information. Warehouse teams picked, packed and dispatched the goods, with couriers completing delivery to the customer.

Handling marketplace order exceptions

Implementation architecture
Marketplace orders · request, review and outcomeCancellationReturnsParcel not receivedRequestEligible under the rulesSeller review neededFulfilment statusRequestAccepted; no return requiredReturn requiredGoods receivedConfirmedRejectedInspection rejectedRequestAcceptedRejectedBuyer requestscancellationCheck cancellationeligibilityAutomatic cancellationSeller checks warehousestatusCancel or confirm dispatchBuyer requests a returnSeller reviews requestRefund without a returnCourier returns goodsInspect returned goodsMarketplace refunds buyerRequest closed; buyer may disputeBuyer reports missingparcelSeller reviews deliveryevidenceAccept refund requestReject; buyer may dispute
Module / recordInternal workflowPhysical movement recorded

These flows cover cancellations, returns and missing parcels for orders placed on the marketplace. The marketplace’s eligibility and return rules determine which requests can be resolved automatically and which require the seller to review the order, shipment or returned goods.

How marketplace exceptions were handled

The marketplace integration went beyond publishing listings and importing orders. It accounted for what happens when a marketplace customer changes their mind, returns a product or does not receive a parcel.

Cancellation depends on the fulfilment stage

An eligible cancellation could be handled automatically; other requests required seller review. The warehouse’s picking, packing or dispatch status mattered because a request to stop an order is different from a request to recover goods that have already shipped.

Returns connect the request to the physical goods

A request could be accepted without requiring the goods back, or accepted subject to a return. Where goods were returned, receipt and inspection informed the refund decision. A rejected request or inspection outcome could lead to a buyer dispute.

Missing parcels need delivery evidence

A refund request for a parcel that had not arrived required review of the shipment and courier information. The seller could accept or reject the request, with a disputed outcome requiring further review through the marketplace.

Business impact

This tech stack supported expansion into a new customer segment whilst keeping product information, orders and regional fulfilment connected. Central middleware gave the new marketplace a place within the existing operation, with information shared across ERP, ecommerce and the warehouse network.

A new channel using existing operations

Product and inventory feeds supported the new sales channel, whilst middleware connected its orders to ERP reporting and the regional fulfilment operation. The business could reach another customer segment using its existing systems and warehouse network.

Fewer manual handovers from order to shipment

Passing orders and tracking between systems reduced the need to move those details by hand. The route also made clear where each update originated and which system needed to receive it, giving teams a practical basis for investigating missing or delayed information.

A clearer route for customer exceptions

Mapping cancellations, returns and missing parcels alongside fulfilment connected customer requests to the physical state of an order. It made the handovers between marketplace, seller, warehouse and courier explicit, instead of treating aftersales as an unrelated process.

AI in the implementation

Purpose-built internal AI troubleshooting agents, developed by the team, helped answer API questions and investigate technical issues whilst the custom marketplace integration was being built.

Further applications of AI

The client also used AI across its wider business to support inventory planning, software development and everyday document work.

How the client used AI

  • Demand forecasting

    Inventory & logistics

    A regional operation used AI demand forecasts to support stock and logistics planning, with the aim of avoiding excess inventory and unnecessary logistics costs.

  • Development assistance

    Software development

    An internal AI coding assistant supported software developers across business units and research teams.

  • Document assistance

    Internal productivity

    A conversational AI assistant helped staff summarise documents, translate content and draft emails.

Anonymous case study based on real client experience

Related case studies

Running a multi-brand business→Connecting material reuse to fulfilment→