Єдина панель керування замовленнями з усіх маркетплейсів

Менеджер витрачає до 2 годин на день на перемикання між кабінетами Ozon, Wildberries та Яндекс.Маркету. За нашими даними, ручна синхронізація призводить до втрати 15–20% замовлень і до 80% негативних відгуків через затримки. Автоматизація зводить ці ризики до нуля, а середній час обробки замовлення знижується з 5 хвилин до 30 секунд, що економить операторам до 50 000 грн на місяць. Єдина панель керування замовленнями вирішує цю проблему: збирає всі замовлення з сайту та маркетплейсів в один інтерфейс. Менеджер працює в одному вікні — бачить нові замовлення, змінює статуси, друкує етикетки, не перемикаючись між майданчиками. Окупність такого рішення — в середньому 2–3 місяці за рахунок скорочення трудозатрат відділу продажів. У нас за плечима 12+ років досвіду у веб-розробці та понад 50 успішних інтеграцій з маркетплейсами.

Навіщо потрібна єдина панель керування замовленнями?

Ручне вивантаження замовлень — оператори копіюють дані з п'яти кабінетів, помиляються в номерах, втрачають замовлення. FBS-замовлення з коротким терміном збірки (4 години на Ozon) залишаються непоміченими. Дублікати та конфлікти — одне й те саме замовлення може бути створено двічі, якщо API маркетплейсу повернуло дані повторно. Наше рішення використовує паттерн Repository для дедуплікації та Adapter для уніфікації даних з різних джерел. Це забезпечує обробку до 1000 замовлень на хвилину без втрат. Порівняйте: ручний збір вимагає 2–3 операторів, автоматизована панель справляється одна — в 10 разів швидше. Єдине вікно замовлень, що об'єднує Ozon, Wildberries, Яндекс.Маркет і сайт, дає повний контроль над усіма процесами.

Як ми синхронізуємо замовлення без втрат?

Синхронізація базується на черзі завдань Laravel Queue. Кожен маркетплейс опитується із заданою періодичністю (як правило, кожні 5–15 хвилин). Всі нові та змінені замовлення приводяться до єдиного формату і зберігаються в локальну БД. Для надійності ми логуємо кожен запуск і автоматично повторюємо при збоях. Концепція черг описана в Laravel Queues.

Ось як виглядає основний клас синхронізації:

// Періодично підтягуємо замовлення з усіх маркетплейсів
class MarketplaceOrdersSyncJob implements ShouldQueue
{
    public function handle(): void
    {
        $adapters = [
            'ozon' => app(OzonAdapter::class),
            'wb'   => app(WildberriesAdapter::class),
            'ym'   => app(YandexMarketAdapter::class),
        ];

        foreach ($adapters as $source => $adapter) {
            try {
                $lastSync = SyncLog::where('source', $source)->max('synced_at')
                    ?? now()->subHours(24);

                $orders = $adapter->getOrdersSince($lastSync);

                foreach ($orders as $rawOrder) {
                    $unified = $adapter->toUnifiedOrder($rawOrder);
                    Order::updateOrCreate(
                        ['source' => $source, 'source_order_id' => $unified->sourceOrderId],
                        $unified->toArray()
                    );
                }

                SyncLog::create(['source' => $source, 'synced_at' => now(), 'count' => count($orders)]);
            } catch (Exception $e) {
                Log::error("Sync failed for {$source}", ['error' => $e->getMessage()]);
            }
        }
    }
}

Дедуплікація замовлень усуває дублі — єдина панель керування

Без дедуплікації повторний запит до API (при збої мережі) створює дублікат замовлення. Ми використовуємо унікальний source_order_id для кожного замовлення в межах маркетплейсу, тому updateOrCreate просто оновлює існуючий запис. Це виключає задвоєння навіть при повторних викликах. Laravel React панель, побудована на цьому принципі, надійно обробляє тисячі замовлень щодня.

Функціональність панелі

Список замовлень

• Фільтрація за джерелом (сайт, Ozon, WB, Яндекс.Маркет)
• Фільтрація за статусом, датою, сумою
• Пошук за номером замовлення, ім'ям клієнта, SKU
• Індикатор терміновості (FBS-замовлення з коротким терміном збірки — червоний фон)
• Масові дії: підтвердити кілька замовлень, надрукувати етикетки

function OrdersDashboard() {
  const [filters, setFilters] = useState({ source: 'all', status: 'all', search: '' });

  const { data, isLoading } = useQuery({
    queryKey: ['orders', filters],
    queryFn:  () => fetchOrders(filters),
    refetchInterval: 60_000,  // оновлення кожну хвилину
  });

  return (
    <div>
      <OrderFilters filters={filters} onChange={setFilters} />

      {/* Лічильники за джерелами */}
      <div className="grid grid-cols-5 gap-3 mb-6">
        {['site', 'ozon', 'wb', 'ym'].map(source => (
          <SourceCounter key={source} source={source} count={data?.counts[source] ?? 0} />
        ))}
      </div>

      <OrdersTable
        orders={data?.orders ?? []}
        loading={isLoading}
        onStatusChange={handleStatusChange}
      />
    </div>
  );
}

function SourceCounter({ source, count }: { source: string; count: number }) {
  const labels = { site: 'Сайт', ozon: 'Ozon', wb: 'WB', ym: 'Яндекс.Маркет' };
  return (
    <div className={cn('rounded-xl p-4 border', sourceColors[source])}>
      <p className="text-2xl font-bold">{count}</p>
      <p className="text-sm text-gray-600">{labels[source]}</p>
    </div>
  );
}

Картка замовлення

• Повні дані клієнта та доставки
• Список товарів з фото
• Кнопки дій залежно від статусу (підтвердити, скасувати, відправити в збірку)
• Друк етикетки / акту передачі
• Історія змін статусу з часовими мітками

Друк етикеток

Кожен маркетплейс вимагає свій формат етикетки. Ми реалізували автоматичний вибір шаблону за джерелом:

public function printLabel(Order $order): Response
{
    if ($order->source === 'ozon') {
        $label = $this->ozon->getPostingLabel($order->source_order_id);
        return response($label, 200, ['Content-Type' => 'application/pdf']);
    }

    if ($order->source === 'wb') {
        $label = $this->wb->getLabel($order->source_order_id);
        return response($label, 200, ['Content-Type' => 'application/pdf']);
    }

    // Для сайту генеруємо самі
    $pdf = PDF::loadView('labels.order', compact('order'));
    return $pdf->stream("order-{$order->number}.pdf");
}

Для масового друку можна вибрати кілька замовлень і натиснути «Друк етикеток» — система сформує єдиний PDF з усіма етикетками.

Сповіщення про нові замовлення

Real-time сповіщення через WebSocket (Laravel Echo / Pusher) — при появі нового замовлення від будь-якого маркетплейсу панель оновлюється автоматично і показує toast-сповіщення. Оператор може одразу прийняти замовлення в роботу, не оновлюючи сторінку.

Процес роботи

1. Аналітика — вивчаємо API ваших маркетплейсів, фіксуємо поля для синхронізації.
2. Проектування — проектуємо структуру БД, систему черг, схему сповіщень.
3. Реалізація — пишемо адаптери, інтерфейс, логіку синхронізації.
4. Тестування — перевіряємо на тестових замовленнях, емулюємо збої мереж, конфлікти даних.
5. Деплой — розгортаємо на вашому хостингу або нашому сервері, налаштовуємо моніторинг.

Порівняння підходів до керування замовленнями

Терміни та що входить в роботу

Панель керування замовленнями для 3 маркетплейсів з синхронізацією та друком етикеток: 20–28 робочих днів. Працюємо за фіксованою вартістю, яка розраховується індивідуально. Входить:

• Інтеграція до 4 джерел (сайт + 3 маркетплейси)
• Веб-інтерфейс зі списком замовлень, фільтрами, пошуком та лічильниками
• Друк етикеток для кожного маркетплейсу
• Система сповіщень (WebSocket + email)
• Документація з адміністрування
• Навчання операторів (1 година)
• Гарантія на синхронізацію — 6 місяців

Типові помилки при інтеграції

• Закінчення токенів — більшість маркетплейсів дають токени на 24 години. Ми автоматично оновлюємо їх через refresh-механізм.
• Різниця в часових поясах — замовлення створено о 23:59 за Москвою, а в стрічці відображається як завтрашнє. Приводимо все до UTC.
• Дуби при повторах — якщо API впав, запит повторюється, і створюється дубль. Використовуємо source_order_id для дедуплікації.

Отримайте консультацію по вашому проекту — ми допоможемо оцінити терміни та вартість. Зв'яжіться з нами, щоб отримати детальний розрахунок.

Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 1000 замовлень на день — це фінансові розбіжності, які неможливо розібрати без окремого reconciliation-процесу. Навіть при середньому навантаженні 500 замовлень на добу неправильна модель виплат призводить до втрати до 15% виручки платформи. Ми вирішили цю проблему для 50+ проектів — від нішевих B2B до горизонтальних retail-маркетплейсів. Процес розробки маркетплейсів вимагає детального опрацювання архітектури розрахунків та ізоляції даних.

Як побудувати надійну мультивендорну платформу?

Як уникнути розбіжностей у розрахунках комісій

Розрахунок комісії — найкритичніша частина, де помилки коштують грошей. Правило перше: ніколи не зберігати комісію як похідну, завжди як факт. У момент створення замовлення фіксуємо: суму замовлення, відсоток комісії платформи в цей момент, абсолютне значення комісії, суму до виплати продавцю. Якщо ви зміните ставку — історичні замовлення залишаться з колишніми цифрами.

Моделі комісій (використовуємо одну з або комбінуємо):

Ми використовуємо Stripe Connect як базовий стандарт. Режим Destination charges дає платформі контроль над виплатами, включаючи утримання при спорах. Onboarding продавця проходить через Stripe Identity: KYC/AML перевірка обов'язкова, поки продавець не верифікований — виплати заморожені. Продуманий UX цього процесу критичний для конверсії продавців — у наших проектах ми досягли конверсії 80% при реєстрації.

Чому архітектура мультиарендності критична для ізоляції даних

Перший крок — вибір архітектури мультиарендності. У shared-schema режимі всі продавці в одних таблицях з vendor_id. Ми обов'язково впроваджуємо Row Level Security на рівні PostgreSQL та глобальні scopes в ORM (Laravel, Rails, Django). Це гарантує, що продавець не побачить чужих замовлень навіть при помилці розробника. Для enterprise-проектів з жорсткими вимогами GDPR використовуємо окремі схеми PostgreSQL — ізоляція строгіша, але cross-vendor аналітика складніша.

Як реалізувати складські залишки без race condition

Два покупці одночасно додають останній товар у кошик. Хто його купить? Застосовуємо optimistic locking при створенні замовлення:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Атомарна операція — другий запит поверне 0 зачеплених рядків та отримає помилку «товар закінчився». Типова схема для високонавантажених маркетплейсів.

Який підхід до каталогу товарів обрати: unified чи per-vendor?

Порівняння підходів до каталогу товарів:

Для нішевого B2B маркетплейсу ми частіше обираємо per-vendor — швидше запускається. Для горизонтального retail з сотнями продавців — unified-каталог дає кращий UX.

Пайплайн модерації: автоматика та ручна верифікація

Маркетплейс несе відповідальність за контент продавців. Типові проблеми: підроблені товари, заборонені категорії, маніпуляція цінами, фейкові відгуки. Вибудовуємо трирівневий пайплайн:

1. Автоматичні перевірки при публікації: обов'язкові поля, відповідність категорії, стоп-лист слів, дублікати через хеш зображення.
2. AI-класифікація (Amazon Rekognition або Vertex AI Vision) — детекція забороненого контенту та визначення категорії.
3. Черга ручної перевірки для flagged товарів.

Статусна машина: draft → pending_review → active / rejected → suspended. Кожен перехід — подія з причиною та модератором. Продавець отримує сповіщення з конкретною причиною відмови, а не «порушення правил». Верифікація відгуків обов'язкова — тільки після підтвердженого замовлення. Автоматичний детектор флагує різке зростання відгуків від акаунтів з нульовою історією.

Пошук та рекомендації

Пошук по маркетплейсу з різними продавцями та сотнями тисяч товарів — це Elasticsearch або OpenSearch, не SQL LIKE. Векторний пошук для семантики, фасетна фільтрація через агрегації. Персоналізована стрічка на основі колаборативної фільтрації. A/B тестування алгоритмів ранжування обов'язкове — інтуїція тут поганий порадник.

Процес роботи

Маркетплейс — ітеративна розробка. MVP: реєстрація продавців, каталог товарів, кошик та checkout через Stripe Connect, базова модерація. Після запуску — дані про реальне використання визначають пріоритети наступних ітерацій.

Типовий порядок:

• MVP (3–4 місяці)
• Аналітика та зворотний зв'язок
• Перший розширений реліз (2–3 місяці)
• Масштабування та оптимізація

Терміни та вартість

• MVP маркетплейсу (каталог, checkout, базові профілі продавців): 3–5 місяців.
• Повнофункціональний маркетплейс з модерацією, розширеною аналітикою, мобільним додатком: 8–18 місяців.
• Додавання маркетплейс-функціональності до існуючого e-commerce: 2–5 місяців.

Вартість розробки розраховується індивідуально після аудиту вимог. Точну оцінку надамо на безкоштовному передпроектному обстеженні.

Що входить в роботу

• Проектна документація: архітектура, схеми даних, API-специфікації (OpenAPI).
• Доступи до репозиторію, CI/CD, документації з розгортання.
• Навчання команди замовника роботі з платформою.
• Технічна підтримка протягом першого місяця після запуску.

Ми гарантуємо коректність фінансових розрахунків та конфіденційність даних. Архітектурні принципи, на яких ми ґрунтуємося, підтверджені досвідом 10+ років та 50+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.