How to Implement Multichannel Sales (Omnichannel)?
Imagine: a client orders a chair on the website, picks it up in the store an hour later, but the chair remains available online — already sold. Or a promo code works only online, not in the app. These are classic consequences of fragmented channels. We integrate multichannel sales so that the customer sees a unified picture: identical prices on website and marketplaces, order history in the personal account, and the ability to return an item from Ozon via the store. This is achieved via API, message broker (RabbitMQ), and unified profiles in PostgreSQL.
Why Is Omnichannel More Than Multiple Stores?
Many think: "Connected marketplace APIs — that's omnichannel." In reality, chaos emerges: the product is on the website but out of stock on Ozon. Or a discount applies only offline. The root issue is disparate data sources: prices, stock, orders live in different systems without a common key. We solve this through Unified Commerce Core — a microservice holding inventory, customers, and promotions in one place. All channels refer to it. This eliminates N+1 queries and conflicts. For deeper understanding, see external reference.
What Challenges Does Omnichannel Solve?
Unified Customer Profile and Data Synchronization: The customer registers on the website, buys via WB, and returns in the store — the system must recognize it's the same person. Without this, personalization and order history are impossible. We implement Customer Identity Resolution through a chain: email → phone → name+address.
View code example: CustomerIdentityResolver
class CustomerIdentityResolver { public function resolve(array $customerData, string $source): Customer { $customer = null; if (!empty($customerData['email'])) { $customer = Customer::where('email', $customerData['email'])->first(); } if (!$customer && !empty($customerData['phone'])) { $normalized = $this->normalizePhone($customerData['phone']); $customer = Customer::where('phone_normalized', $normalized)->first(); } if (!$customer) { $customer = Customer::create([ 'name' => $customerData['name'], 'email' => $customerData['email'] ?? null, 'phone_normalized' => $normalized ?? null, 'source_first' => $source, ]); } $customer->channelIds()->updateOrCreate( ['channel' => $source], ['external_id' => $customerData['id'] ?? null] ); return $customer; } } Order history merges into one table linked to customer_id. Promotion management ensures a promo code created for the website also works on the marketplace if the channel is allowed. Channel-based reservation uses fixed percentages: site 40%, ozon 30%, wb 20%, buffer 10%. This approach reduces overbooking risk by up to 60% compared to a full pool.
class OmnichannelPromotion { public function apply(string $promoCode, Order $order): void { $promo = Promotion::where('code', $promoCode)->first(); if (!in_array($order->source, $promo->applicable_channels)) { throw new PromoNotApplicableException("Promo code not valid for {$order->source}"); } $discount = $promo->calculateDiscount($order->total); $order->applyDiscount($discount, $promoCode); $promo->increment('used_count'); } } Integration Approaches and Reservation Strategies
| Approach | Implementation time | Complexity | Consistency |
|---|---|---|---|
| ETL (periodic load) | 2–4 weeks | Low | Low (delays) |
| API Gateway with synchronous requests | 4–8 weeks | Medium | Medium (timeout risk) |
| Event-driven (CDC + queues) | 6–12 weeks | High | High (real-time) |
We choose the third option — lowest latency and good scalability. Event-driven is 2–3× faster than ETL for stock sync. More about CDC: official documentation.
| Strategy | Overbooking risk | Flexibility | Complexity |
|---|---|---|---|
| Fixed percentage | Low | Low | Low |
| Dynamic based on sales | Medium | High | Medium |
| Full pool | High | Medium | High |
Work Process and What's Included
- Analysis — review architecture, channels, data volumes, business rules.
- Design — data model, API specs (OpenAPI), exchange scheme.
- Implementation — write Core, adapters, tests (unit + integration).
- Testing — end-to-end scenarios: order on website, cancel in app, return on marketplace.
- Deployment — roll-out per channel, monitoring via Grafana.
We guarantee real-time data consistency. Our engineers have over 5 years of experience in distributed systems. For a furniture store chain, we integrated 5 channels, reducing return rates by 25% through accurate stock display. Typical project cost: $15,000–$40,000 depending on number of channels and complexity. Clients save an average of $50,000 annually from reduced overstock and returns.
- Development of Unified Commerce Core (inventory, customers, orders, promotions).
- Integration with 3+ channels (website, marketplaces, mobile app).
- API documentation and data schemas.
- Load testing and optimization.
- Training for the client's team.
Timelines & Pricing
Basic system for 3 channels: 20–30 working days. For 5+ channels: up to 50 days. Pricing is individual after an audit. Get a consultation to evaluate your project.
Our Experience
We have completed 15+ omnichannel projects for e-commerce. Clients include stores with monthly turnover from $100,000. Our engineers have over 5 years of experience. Contact us — we will help determine the optimal architecture.