Что нужно для собственного канала продаж кроме сайта: CRM, платежи, доставка и коммуникации

Собственный интернет-магазин легко представить как сайт с каталогом и корзиной. На практике для прямых продаж нужен связанный контур: CRM, платежи, касса, доставка, склад, коммуникации, аналитика и процессы после первого заказа.

В первой статье серии я зафиксировал главный фильтр: собственный магазин особенно интересен бренду, который уже сам создаёт спрос и может направлять покупателей из Telegram, Instagram, VK, блога или своей базы.

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

товар -> корзина -> оплата -> CRM -> склад -> доставка -> коммуникация -> повторная продажа.

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

Коротко

Для типового собственного канала я бы закладывал 9 связанных блоков:

1. витрина и каталог;
2. CRM;
3. платежи и онлайн-касса;
4. склад и остатки;
5. доставка;
6. телефония и мессенджеры;
7. обработка заказов и исключений;
8. аналитика;
9. повторные продажи.

Для части брендов к этому добавляются Telegram или MAX как дополнительные точки входа.

Принцип один:

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

1. Витрина отвечает за путь до заказа

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

Для стандартизированного запуска я бы ограничивал вариативность заранее:

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

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

2. CRM становится рабочим центром после оформления заказа

Как только заказ создан, сайт перестаёт быть главным экраном для сотрудника. Нужно видеть:

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

Для этого нужна CRM.
В Битрикс24, например, карточка CRM хранит данные клиента и историю коммуникаций, а телефония и подключённые каналы общения могут сохранять взаимодействия в этой же карточке. Официальная документация отдельно описывает интеграцию Битрикс24 с интернет-магазином на «1С-Битрикс: Управление сайтом» и указывает, что интеграция доступна не на всех тарифах.

Для меня здесь важнее не конкретный бренд системы, а архитектурный принцип:

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

Письма вида «вам пришёл новый заказ» не должны быть основным способом управления продажами.

3. Платежи и касса нужно проектировать как один сценарий

Подключить эквайринг недостаточно. До запуска нужно определить:

• какие способы оплаты доступны;
• когда заказ считается оплаченным;
• что происходит при неуспешной оплате;
• как формируется чек;
• как оформляется возврат денег;
• какой статус получает заказ;
• что видит покупатель;
• что видит сотрудник.

Проверять нужно не факт наличия договора с платежным сервисом, а весь путь:

оформить заказ -> оплатить -> получить правильный статус -> сформировать чек -> увидеть оплату в CRM.

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

4. Склад и остатки должны иметь один источник правды

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

Важно не название программы, а правило:

где остаток изменяется первым и как это изменение попадает во все каналы продаж.

Это особенно критично, если бренд одновременно продаёт на Wildberries, Ozon и собственном сайте. Без понятного источника правды один и тот же остаток легко обещать нескольким покупателям.

5. Доставка - не кнопка интеграции, а отдельный процесс

Подключение СДЭК или другой службы по программному интерфейсу ещё не означает, что доставка организована. Нужно определить:

• откуда забирают товар;
• кто создаёт отправление;
• как выбирается пункт выдачи или адрес;
• кто печатает документы;
• когда заказ передаётся перевозчику;
• где хранится трек-номер;
• как статусы возвращаются в CRM;
• кто реагирует на задержку;
• что происходит с недоставленным заказом.

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

6. Телефония и мессенджеры нужны прежде всего для исключений

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

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

Поэтому сам по себе номер 8-800 не создаёт ценности. Ценность появляется, когда сотрудник открывает обращение и сразу видит клиента, заказ и историю.

7. Рабочее место сотрудника нужно проектировать отдельно

Даже хороший набор сервисов может дать плохой ежедневный процесс. Типичная картина:
сайт открыт в одной вкладке;
CRM - во второй;
доставка - в третьей;
телефония - в четвёртой;
касса - в пятой;
остатки - ещё где-то.

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

сколько систем нужно открыть сотруднику, чтобы понять состояние одного заказа и выполнить следующее действие?

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

8. Telegram и MAX лучше использовать как дополнительные точки входа

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

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

Документация MAX прямо указывает, что мини-приложения работают на стандартных веб-технологиях HTML, JavaScript и CSS и загружаются по HTTPS: документация MAX для разработчиков. Это позволяет переиспользовать значительную часть веб-контура вместо создания ещё одной отдельной торговой системы.

9. Аналитика должна различать происхождение продаж

После запуска недостаточно видеть только выручку и число заказов. Минимально я бы отслеживал:

• количество заказов;
• выручку;
• средний чек;
• конверсию;
• источники заказов;
• успешные и неуспешные оплаты;
• отмены;
• стоимость доставки;
• проблемные заказы;
• долю повторных покупателей.

Особенно важно разделять три потока:

• продажи из собственной аудитории;
• продажи из платного привлечения;
• повторные продажи.

500 заказов из Telegram-аудитории, которую бренд развивал годами, и те же 500 заказов после большого рекламного бюджета - две разные экономики.

После первого заказа начинается главное отличие собственного канала

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

Например:

• напомнить о повторной покупке;
• предложить комплект;
• сегментировать покупателей по продуктам;
• выделить постоянных клиентов;
• анализировать интервалы между заказами.

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

Как я разделяю ответственность систем

Для практического проекта полезно заранее назначить источники правды.

Витрина

Отвечает за каталог, карточки товаров, корзину и оформление заказа.

CRM

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

Учёт и склад

Отвечают за товары, остатки, резервы и движение.

Платежный контур

Отвечает за приём денег, статусы, чеки и возвраты.

Логистика

Отвечает за создание отправления, вариант доставки, трекинг и фактическую доставку.
Если эту ответственность не определить заранее, интеграция быстро превращается в спор о том, какая из систем содержит правильные данные.

Что должно работать к моменту запуска

Я бы не считал проект готовым после публикации сайта. Нужен сквозной тест:

1. Новый покупатель оформляет заказ.
2. Клиент и заказ появляются в CRM.
3. Платёж проходит.
4. Формируется корректный чек.
5. Остаток изменяется в нужной системе.
6. Создаётся отправление.
7. Трек-номер сохраняется.
8. Покупатель получает нужные уведомления.
9. Сотрудник видит состояние заказа в рабочей системе.
10. После завершения заказа клиент остаётся доступен для дальнейшей работы.

Нужны и отрицательные сценарии: не прошла оплата, товара нет, изменился адрес, доставка задержалась, заказ отменён.
Именно исключения обычно показывают, собран ли канал целиком или запущена только витрина.

Главное

Сайт - только место, где покупатель начинает заказ.
Рабочий собственный канал появляется, когда сайт связан с CRM, оплатой, кассой, остатками, доставкой, коммуникациями, аналитикой и повторными продажами.

Главный проектный вопрос поэтому звучит не «какой дизайн будет у сайта?», а:

как заказ пройдёт от клика покупателя до доставки без ручных разрывов и останется в системе для следующей продажи?

Следующий материал серии отвечает уже на вопрос стоимости: сколько стоит собрать такой контур и какие расходы нельзя смешивать с ценой разработки сайта.