Кейс · Фулфилмент

Февраль–май 2026

Как я автоматизировал обработку заказов из Яндекс Еды

Origami производила подарочные конфеты ручной работы и продавала их онлайн. Для экспресс-доставки мы использовали собственное производство и партнёрскую сеть дарксторов.

Для подарка скорость особенно важна: если он приезжает слишком поздно, можно просто упустить момент. Поэтому к приезду курьера заказ уже должен был быть полностью собран и готов к передаче.

Изначально процесс был простым. Я сам принимал заказы на производстве, собирал их и передавал курьерам. Когда появились партнёрские дарксторы, доставка стала быстрее, но сам процесс — сложнее: системы не были связаны между собой, и каждый заказ из Яндекс Еды по-прежнему проходил через меня.

Если заказ собирал партнёрский даркстор, я переносил данные в его систему. Если собственное производство — отправлял всё в рабочий Telegram-чат и ждал реакции команды. При необходимости напоминал о заказе или звонил сотрудникам.

Курьер часто приезжал примерно через 15 минут. Каждое ручное действие отнимало часть этого времени и создавало дополнительный риск ошибки.

К началу 2026 года я уже жил в другой стране, но всё ещё оставался обязательным звеном этого процесса.

Без меня процесс мог просто остановиться.

Как возникла ручная зависимость

Партнёрские точки работали через сеть «Даркстор у дома». Она позволяла хранить товары ближе к покупателям и быстрее доставлять их в Москве и других городах.

Примерно за год до запуска интеграции наши товары лежали уже в десяти точках этой сети в разных городах. Со временем мы оставили одну: для нашей логистики это оказалось эффективнее. Одновременно часть заказов по-прежнему собирало собственное производство.

Но Яндекс Еда, система «Даркстора у дома» и внутренний процесс производства по-прежнему не были связаны.

НОВЫЙ ЗАКАЗ
     │ принять
     ▼
ВЫБРАТЬ МАРШРУТ
     ├── перенести данные ───────→ СИСТЕМА ПАРТНЁРА
     │
     └── передать ──────────────→ TELEGRAM КОМАНДЫ
                                      │ проверить реакцию
                                      │ напомнить / позвонить
                                      ▼
                                 СБОРКА → КУРЬЕР

НОВЫЙ ЗАКАЗ
     │ принять
     ▼
ВЫБРАТЬ МАРШРУТ
├─ ПАРТНЁР → перенести данные
└─ КОМАНДА → TELEGRAM
                │ проверить
                │ напомнить
                │ позвонить
                ▼
          СБОРКА → КУРЬЕР

Даркстор работал семь дней в неделю. Поэтому я должен был оставаться на связи постоянно.

Эту работу можно было передать отдельному диспетчеру. Но один человек не смог бы закрывать все длинные смены. При графике 2/2 пришлось бы нанять минимум двоих.

Их работа состояла бы в том, чтобы принимать заказы, переносить данные между системами и следить, что команда вовремя начала сборку.

Я решил автоматизировать весь маршрут заказа.

Почему не подошла готовая интеграция

У «Даркстора у дома» уже была интеграция с Яндекс Едой для магазинов. Мы же были подключены как ресторан, поэтому воспользоваться готовым решением не могли.

Я спроектировал собственную интеграцию и собрал её с помощью Claude Code.

Основой стал Supabase. Заказы и статусы хранились в облачном Postgres. Серверная логика работала на TypeScript в Supabase Edge Functions.

Edge Functions принимали запросы Яндекс Еды, работали с базой, обращались к API партнёра и управляли Telegram-ботом. Позже в тот же контур я добавил Flowwow.

МАРКЕТПЛЕЙСЫ ЛОГИКА СЕРВЕРА СОСТОЯНИЕ

Яндекс Еда ───────────────→ Edge Functions ───────────→ Postgres Flowwow ───────────────→ проверить · направить заказ · статус · курьер │ ┌────────────┴────────────┐ ▼ ▼ API партнёра Telegram Bot │ │ ▼ ▼ «Даркстор у дома» производство

МАРКЕТПЛЕЙСЫ
Яндекс Еда / Flowwow
          ↓
    EDGE FUNCTIONS
   проверить · направить
          ↓
       POSTGRES
 заказ · статус · курьер
          ↓
   ┌──────┴──────┐
   ↓             ↓
API партнёра  Telegram Bot
   ↓             ↓
даркстор    производство

Как проходил один заказ

Когда Яндекс Еда обращалась к нашему бэкенду с новым заказом, Edge Function проверяла запрос и сохраняла данные в Postgres.

Затем заказ направлялся по одному из двух маршрутов. Если его собирал партнёрский даркстор, Edge Function передавала данные в API «Даркстора у дома». Если заказ относился к собственному производству, Edge Function формировала сообщение и отправляла его через Telegram Bot API в рабочий чат.

Производственной команде не понадобилась отдельная панель управления. Все уже пользовались Telegram, поэтому новый процесс встроился в привычный инструмент.

В сообщении были:

номер заказа;
состав;
ожидаемое время;
текущий статус;
информация о курьере;
кнопки для работы с заказом.

Сотрудник мог принять или отклонить заказ. При отмене бот предлагал указать причину. После сборки сотрудник нажимал кнопку «Собран».

Когда от Яндекса приходили данные курьера, бот обновлял то же сообщение. При передаче заказа сотрудник вводил код курьера ответом в Telegram. Это действие оставалось ручным: код подтверждал, что заказ получает нужный человек.

Каждое нажатие приходило в Edge Function через Telegram webhook. Функция обрабатывала действие и записывала новый статус в Postgres.

СОТРУДНИК ── нажимает кнопку ──→ TELEGRAM WEBHOOK
                                           │
                                           ▼
                                      EDGE FUNCTION
                                           │
                                           ▼
                                  НОВЫЙ СТАТУС В POSTGRES

СОТРУДНИК
 ↓ нажимает кнопку
TELEGRAM WEBHOOK
 ↓
EDGE FUNCTION
 ↓
СТАТУС В POSTGRES

Яндекс не получал отдельного уведомления об изменении. Вместо этого он сам снова запрашивал статус заказа. Edge Function читала актуальное значение из Postgres и возвращала его в ответе.

ЯНДЕКС ЕДА ── запрос статуса ──→ EDGE FUNCTION
     ▲                                   │
     │                                   ▼
     └────── актуальный статус ────── POSTGRES

ЯНДЕКС ЕДА
 ↓ запрос статуса
EDGE FUNCTION
 ↓ читает
POSTGRES
 ↓ актуальный статус
ЯНДЕКС ЕДА

Реконструкция по архивному production-коду

Попробуйте обработать заказ

Производство

5 марта

Реконструкция по архивному production-коду. На сайте этот путь можно пройти по шагам. Полная последовательность остаётся доступна и без интерактивного режима:

Маркетплейс отправляет запрос с заказом.
Edge Function проверяет запрос, сохраняет заказ и выбирает маршрут.
Для собственного производства бот отправляет одно Telegram-сообщение с действиями «Подтвердить» и «Отменить».
Действия команды приходят через Telegram webhook и обновляют статус в Postgres.
После сборки в сообщении появляется информация о курьере.
Сотрудник вводит код курьера — это обязательный человеческий контроль при передаче заказа.
Финальный статус сохраняется в Postgres и возвращается, когда маркетплейс снова его запрашивает.

Статус не отправлялся в маркетплейс отдельным webhook. Если команда не отвечала, работали повторное Telegram-уведомление и внутренняя телефонная эскалация. Если же интеграция не возвращала маркетплейсу подтверждение или отмену, у него был собственный независимый резерв: звонок на телефон точки и возможность открыть заказ в веб-интерфейсе площадки, чтобы подтвердить или отменить его там.

Мы могли сохранять, кто именно нажал каждую кнопку. Но намеренно не стали добавлять это в первую версию.

Команда была небольшой и опытной. Проблем с точностью сборки не было, а персональный контроль не помогал решить главную задачу. Нам было важнее быстрее запустить систему.

Что происходило без ответа

Для экспресс-доставки недостаточно просто отправить сообщение. Нужно убедиться, что заказ действительно заметили.

Если производство не реагировало, система отправляла повторное Telegram-уведомление. После этого включалась телефонная эскалация.

НОВЫЙ ЗАКАЗ
     │
     ▼
TELEGRAM-УВЕДОМЛЕНИЕ
     │ нет реакции
     ▼
ПОВТОРНОЕ УВЕДОМЛЕНИЕ
     │ снова нет реакции
     ▼
ТЕЛЕФОННЫЙ ЗВОНОК

НОВЫЙ ЗАКАЗ
 ↓
TELEGRAM-УВЕДОМЛЕНИЕ
 ↓ нет реакции
ПОВТОРНОЕ УВЕДОМЛЕНИЕ
 ↓ снова нет реакции
ТЕЛЕФОННЫЙ ЗВОНОК

Оставался ещё один риск: могла перестать работать сама интеграция. В этом случае не пришло бы ни первое сообщение, ни повторное, ни звонок из нашего контура.

Поэтому существовал независимый резерв со стороны маркетплейса. Если Яндекс Еда или Flowwow не получали подтверждение или отмену заказа, они сами звонили на телефон точки. После звонка сотрудник мог открыть заказ в веб-интерфейсе площадки и подтвердить или отменить его там. Этот интерфейс оставался доступен независимо от наших Edge Functions, Postgres и Telegram-контура.

НАША СИСТЕМА РЕЗЕРВ МАРКЕТПЛЕЙСА

Telegram нет подтверждения │ или отмены заказа повторное уведомление │ │ ▼ телефонный звонок звонок на точку │ │ │ ▼ │ веб-интерфейс │ подтвердить / отменить │ │ └─────────────────┬──────────────────┘ ▼ ЗАКАЗ ОБРАБОТАН

1 · НАША СИСТЕМА
Telegram
 │ повторное уведомление
 │ телефонный звонок
 └────────────────────┐
                      │
2 · РЕЗЕРВ             │
нет подтверждения      │
 │ звонок на точку     │
 │ веб-интерфейс       │
 │ подтвердить/отменить│
 └────────────────────┤
                      ▼
ЗАКАЗ ОБРАБОТАН

Что изменилось после запуска

Мне больше не нужно было участвовать в каждом заказе.

Заказы для партнёрского даркстора автоматически передавались в систему «Даркстора у дома». Заказы собственного производства появлялись в Telegram. Команда могла принять заказ, собрать его и передать курьеру без моего участия.

Яндекс при следующем запросе получал актуальный статус из нашей базы.

Вместо отдельной диспетчерской команды мы использовали автоматическую маршрутизацию и сотрудников, которые уже находились на производстве. Благодаря этому не пришлось нанимать минимум двух человек для посменной обработки заказов.

Мы никого не сокращали. Отдельной команды для этой работы изначально не существовало — и после запуска она не понадобилась.

Сколько проработала система

Интеграция работала с февраля по май 2026 года.

В начале мая мы закрыли собственное производство. В конце месяца остановили все продажи. Интеграция продолжала работать до остановки бизнеса.

До её запуска каждый заказ мог потребовать моего участия. После запуска производство и партнёрский склад работали напрямую с системой.

Я больше не был обязательным звеном между заказом и его исполнением.

Моя роль

Я знал этот процесс не по описанию: долгое время сам выполнял его вручную. Поэтому мог увидеть не только технический разрыв между системами, но и реальные операционные риски.

В рамках проекта я:

разобрал существующий процесс;
спроектировал маршрутизацию заказов и серверную логику;
с помощью Claude Code собрал Edge Functions на TypeScript;
создал структуру данных в Postgres;
подключил Яндекс Еду, Flowwow и API «Даркстора у дома»;
встроил управление заказами в Telegram;
добавил повторные уведомления и телефонную эскалацию;
предусмотрел независимый резерв на случай полного сбоя.