Назад до проєктів

    Кейс

    Автоматизація ecom

    Рік
    2026
    Послуги
    AI Automation, Engineering

    Система автоматизації для швейного виробництва: щоденний план пошиву, закупівля матеріалів, звірка післяплат і AI-відповіді покупцям.

    Автоматизація ecom
    Supabase (PostgreSQL)ReactClaudeSitniks CRM APINova Poshta / Ukrposhta APITelegram Bot API

    Виклик

    Клієнт - швейне виробництво з власним інтернет-продажем: близько ста моделей одягу, продажі через рекламу в соцмережах, CRM Sitniks, доставка Новою Поштою та Укрпоштою, склад і цехи в Google-таблицях. Ситуація, знайома майже кожному ecom із власним виробництвом:

    • Що шити - вирішували вручну. Попит у CRM, залишки в таблиці, цехи в іншій вкладці. Щоб зрозуміти, чого не вистачає, треба було звести це головою.
    • Закупівлю матеріалів рахували на око. Наслідок: то простій, то зайві рулони на складі.
    • Гроші за післяплатами ніхто не звіряв. Реєстри переказів приходили листами, зіставити їх із замовленнями руками нереально.
    • Незрозуміло, які моделі заробляють. Реклама в двох кабінетах, собівартість в одному файлі, продажі в іншому.
    • Менеджери відповідали на «яка ціна?» вручну, включно з ночами й вихідними.

    Що ми зробили

    Систему, яка щоранку о 7:00 приносить готові рішення разом із сумами в двох валютах:

    • Планування пошиву. Система бере попит із CRM, залишки зі складу й цехів і товар, що їде назад як повернення, і видає план: яку модель, у якому кольорі й розмірі шити сьогодні. Партії округлюються до виробничих десяток.
    • Закупівля матеріалів і фінзвіт. Під план рахується тканина й фурнітура: метри зводяться до рулонів, штуки до фасовок, ціни до сум у доларах і гривнях. Список приходить у чат закупівель, розбитий по постачальниках.
    • Контроль післяплат. Кожне відправлення звіряється з реєстрами переказів пошти: гроші прийшли, прийшла інша сума, чекаємо, прострочено понад 10 днів. Реєстри забираються з поштової скриньки автоматично.
    • Облік повернень. Через API пошти видно, що фізично повернулося на склад, що ще їде, а що зависло у відділенні. Повернене одразу враховується як наявність і не шиється вдруге.
    • Аналітика й рейтинг моделей. Єдиний бал ефективності з шести показників: маржа, відсоток викупу, конверсія, вартість замовлення, вартість діалогу, складність пошиву.
    • Автовідповіді покупцям. Система визначає модель із реклами, з якої прийшов діалог, бере ціну з картки товару й відповідає за секунди, далі передає діалог менеджеру.
    • Адмінка з ролями. Фінансист бачить гроші, виробництво - план, закупівельник - матеріали.

    Результат у цифрах

    • Матеріали під план рахуються на 94% замість 45%. Частка плану, для якої система не могла порахувати закупівлю, впала з 55% до 6%. По одній лише основній тканині замовлення зросло з 5 до 17 рулонів - рівно стільки, скільки насправді було потрібно.
    • Понад чверть мільйона гривень післяплат під контролем. Контрольний прогін лише за два дні відправлень узяв під нагляд 307 посилок на 272 455 грн - із поіменним списком тих, за якими гроші не дійшли.
    • 24% цих грошей були поза видимістю взагалі. Відправлення другого перевізника технічно не потрапляли у звірку: 74 посилки з 307, майже 73 тисячі гривень. Знайшли це на живих даних, а не в тестах.
    • Відповідь покупцю за секунди замість 1,5-2 хвилин - і цілодобово. Система відповідає лише там, де ціна однозначна: зі 122 товарів це 108.
    • Рейтинг моделей побудовано на всій історії продажів - десятки тисяч замовлень зведені до показників по кожній моделі.

    Як ми працювали

    Приблизно шість тижнів від першої розмови до системи, яка працює щодня без участі розробника. Кожен блок запускався окремо й одразу приносив користь: спершу ядро розрахунку (план + закупівля), далі конектори до CRM, пошти й таблиць, потім аналітика, наприкінці автовідповіді та контроль грошей.

    Принципи, без яких таке не працює:

    • Перевірка на живих даних. Половину найдорожчих помилок знайшли, прогнавши систему на справжньому складі, а не в тестах.
    • Система мовчить замість того, щоб сказати неправду. Нульовий залишок часто означає «шиється просто зараз», тому покупцю не пишеться «немає».
    • Людська правка - джерело правди. Система ніколи не перезаписує те, що людина внесла в таблицю руками. Клієнт не відмовлявся від Google-таблиць: система читає їх такими, як є.
    • Кожне число можна простежити до рядка таблиці, з якого воно взялося.

    Стек: Supabase (PostgreSQL), React, Claude, Sitniks CRM API, API Нової Пошти та Укрпошти, Google Sheets API, Telegram Bot API.

    Що ми тут робили

    Давайте обговоримо ваш продукт та цілі росту.