Обсудить проект

Разработка интернет-магазина с CRM: как это собрано

Возненко Игорь «Ось Бизнеса» обновлено 31 августа 2026 г.

Считать, когда свой магазин выгоднее площадки, я здесь не буду — это отдельный разбор с цифрами. Здесь про то, как он устроен внутри.

Про интернет-магазин обычно спрашивают: «на чём делать». Ответ на этот вопрос почти никогда не бывает решающим — движок выбирается за час, а живёт магазин следующие несколько лет тем, как устроено всё остальное: откуда берутся остатки, куда попадают заказы, кто и где отвечает клиенту, что происходит, когда товара нет.

Здесь — разбор боевого магазина: из чего он собран, что отдали готовым решениям, что пришлось написать самим и как витрина связана с системой, в которой работают люди.

Архитектура: две системы вместо одной

Витрина — WordPress с WooCommerce: каталог, карточка товара, корзина, оформление, оплата, личный кабинет покупателя.

Всё остальное — CRM Ось Бизнеса: заказы менеджера, статусы, склад, доставка, чеки, коды маркировки, обращения клиентов. Дальше по тексту — «портал».

Что такое этот портал и почему его собирают под процессы, а не берут коробкой, — в отдельном разборе: CRM, ERP или портал.

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

Витрина и CRM Ось Бизнеса: заказы, статусы доставки, остатки, отзывы, брошенные корзины, письма

Шесть потоков между витриной и порталом. Каждый — отдельная точка отказа, и на каждую нужен ответ на вопрос «что тогда».

Что ходит между витриной и порталом

Связь — через программный интерфейс магазина, с отдельными ключами доступа. Шесть потоков:

Заказы — с сайта в портал. Портал забирает новые заказы раз в две минуты и раскладывает по своим статусам: оплачен, ждёт оплаты, отменён. Повтор исключён по номеру заказа на сайте — один и тот же заказ не заведётся дважды, даже если опрос наложится сам на себя.

⚠️ И правило, которое дороже всего остального: на склад уходят только оплаченные заказы. Неоплаченный лежит в портале лидом, менеджер его видит, но отгрузка не начнётся — иначе первый же брошенный чекаут поедет клиенту за наш счёт.

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

Остатки — со склада на витрину. Раз в двадцать минут: сколько единиц реально доступно к продаже. Продавать то, чего нет, — самый дорогой вид ошибки в рознице: он стоит не денег, а доверия.

Отзывы, брошенные корзины и письма — в портал, чтобы менеджер работал в одном окне, а не переключался между админкой сайта, почтой и мессенджерами.

Готовое или своё: где проходит граница

Спор «писать самим или брать готовое» решается не принципом, а вопросом: сколько чужого кода придётся содержать ради нужной функции.

Готовыми решениями закрыто то, что делают все и делают давно: движок магазина, тема оформления, конструктор посадочных страниц, поисковая оптимизация (разбор, что в ней работает сейчас), ускорение отдачи страниц (как мы довели свой сайт до 99 из 100), список желаний, фильтр каталога, восстановление брошенных корзин, платёжный модуль. Писать это заново — брать на себя чужую работу вместе с обновлениями и совместимостью.

Своё появляется там, где готовое либо не решает задачу, либо решает её слишком дорого. Дорого — это когда ради одной функции ставится плагин, который тянет за собой панель настроек, свою базу, свои шорткоды и десяток файлов на каждой странице.

⚠️ Практическое правило: свой плагин должен решать одну задачу и умещаться в один файл, который можно прочитать за вечер. Тогда через год его починит любой разработчик, а не только автор.

Что мы написали сами и зачем

Восемь небольших плагинов. Каждый — конкретная задача, без панели настроек «на все случаи».

Личный кабинет покупателя. Фирменное оформление плюс то, ради чего он вообще нужен: статус доставки и трек-номер, которые приезжают из портала. Заменил сторонний кастомайзер — тот умел менять цвета, но не умел показывать главное.

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

Ограничение доставки. У части товаров есть ограничения: их можно везти не всеми способами и не во все города. Запрещённые способы просто не показываются при оформлении, город проверяется до оплаты. Это тот случай, когда правильнее не дать оформить, чем потом возвращать деньги.

«Сообщить о поступлении». Вместо мёртвого бейджа «нет в наличии» — кнопка: покупатель оставляет почту, заявка уходит в портал, при поступлении товара уходит письмо. Спрос на отсутствующий товар превращается в список ожидания вместо ушедшего посетителя.

Захват корзины при уходе. Посетитель с товаром в корзине собирается закрыть вкладку — предлагаем сохранить корзину и купон за почту. Захваченный контакт попадает в «Брошенные корзины» портала.

Мост брошенных корзин. Сбор корзин делает готовый плагин, а работают с ними менеджеры — в портале, а не в админке сайта. Мост отдаёт их порталу: работа с клиентом должна жить там, где вся остальная работа с клиентом.

Мост отзывов. Отзывы остаются нативными для магазина, но управляются из портала: модерация, ответы, поиск по товару. Доступ — по секрету в заголовке, а не по логину администратора сайта.

Почтовый мост. Приём и отправка почты магазина в «Клиентский сервис» портала. Живёт на сервере сайта по прозаической причине: почту принимает только его адрес.

Плюс девятый, самый скучный и самый показательный — заплатка на страницу «Спасибо» после оплаты: платёжный модуль и конструктор воронок расходились в одном символе внутри адреса возврата, и покупатель после успешной оплаты видел ошибку. Разбирал этот случай подробно в статье про приём оплаты.

Почему заплатки — отдельными плагинами

Соблазн поправить чужой код на месте велик: две строки, десять минут. Но при первом же обновлении правка исчезнет, и хорошо, если это заметят не по звонку клиента.

Поэтому каждая доработка живёт отдельной надстройкой с описанием: что делает, почему появилась и когда её можно удалить. Заплатка на страницу «Спасибо» устроена так, что после исправления в самом модуле она просто перестанет что-либо делать — снимать ей будет нечего.

Что стоит решить до начала разработки

  • Где живёт правда о заказе — на витрине, в CRM или в учётной системе. Ответ «везде» означает, что нигде.
  • Кто хозяин каждого поля: статус заказа, статус доставки, остаток, цена. У каждого — ровно один.
  • Что происходит с неоплаченным заказом и в какой момент он превращается в отгрузку.
  • Откуда берутся остатки и с какой задержкой они доезжают до витрины.
  • Где менеджер работает: одно окно или пять вкладок. Это не про удобство, а про то, сколько обращений потеряется.
  • Какие доработки вы уже знаете заранее — и почему их нельзя закрыть настройками готовых плагинов.

Магазин ломается не там, где сложная вёрстка, а там, где две системы по-разному понимают простое слово. В рознице таких слов три: «оплачен», «в наличии» и «доставлен».

Как устроены следующие звенья цепочки, разбирал отдельно: приём оплаты, отправка заказов Яндекс.Доставкой и чеки по 54-ФЗ.

Если вам нужен такой магазин

Всё описанное собрано и работает на боевом проекте: витрина, восемь точечных доработок под задачи бизнеса, связь с CRM Ось Бизнеса по шести потокам, склад, доставка и касса. Эти наработки переносятся: движок тот же, интерфейс обмена тот же, а грабли уже пройдены.

Что обычно входит в работу:

  • разбор схемы: что продаёте, откуда берутся остатки, кто исполняет заказы;
  • витрина: каталог, оформление, оплата, личный кабинет — на готовом там, где готовое справляется;
  • доработки под ваши правила: комплекты, ограничения доставки, списки ожидания, что угодно ещё;
  • связь с системой, где работают люди: заказы, статусы, остатки, обращения;
  • то, о чём вспоминают последним: что произойдёт, когда обмен сломается, и кто об этом узнает.

Что входит в разработку интернет-магазина целиком — от каталога до обмена со складом — собрано на отдельной странице. Хотите такой магазин — расскажите о задаче.

Коротко: частые вопросы

На чём делать интернет-магазин?
Движок выбирается за час и решает мало. Живёт магазин тем, как устроено остальное: откуда берутся остатки, куда попадают заказы, кто отвечает клиенту и что происходит, когда товара нет.
Когда нужны свои плагины, а когда хватит готовых?
Готовое берут там, где оно закрывает задачу целиком: движок, тема, оптимизация, платёжный модуль. Своё пишут там, где готовое либо не решает задачу, либо тянет за собой панель настроек и десяток файлов ради одной функции.
Что происходит с заказом без участия человека?
Штатный заказ проходит от оплаты до чека сам: заказы забираются с витрины, уходят в исполнение, статусы возвращаются на сайт, остатки приезжают со склада, финальный чек пробивается после доставки. Человек нужен там, где случай не описан бизнес-логикой.
Содержание
  1. Архитектура: две системы вместо одной
  2. Что ходит между витриной и порталом
  3. Готовое или своё: где проходит граница
  4. Что мы написали сами и зачем
  5. Почему заплатки — отдельными плагинами
  6. Что стоит решить до начала разработки
  7. Если вам нужен такой магазин
  8. Коротко: частые вопросы