Короткий ответ такой. Если вы отгружаете товар — с позициями, остатками, частичными отменами и возвратами, — берите RetailCRM: там заказ является встроенной сущностью, а не полем в сделке. Если вы продаёте услугу, проект или дорогой товар под заказ, где сделка живёт неделями и держится на переписке и звонках, — берите amoCRM. Всё остальное сравнение существует, чтобы объяснить, почему этот критерий важнее интерфейса, цены лицензии и списка интеграций вместе взятых.
Проблема в том, что в выдаче на этот запрос отвечают интеграторы, которые внедряют одну из двух систем. Партнёр amoCRM объяснит, что товарный учёт вообще не дело CRM и его надо оставить в 1С. Партнёр RetailCRM покажет, как красиво в его системе выглядит сборка заказа. Оба будут правы наполовину, потому что разница между системами не в наборе функций, а в модели данных — и она проявляется не на демонстрации, а на восьмом месяце эксплуатации, когда клиент впервые попросит отменить одну позицию из четырёх.
Ниже — разбор по шести узлам, где системы расходятся принципиально, модельная смета владения на трёх объёмах заказов и честная цифра, во что обходится обратный переезд. Всё, что касается каналов связи, дано по состоянию на сентябрь 2026 года: этот слой меняется чаще остальных.
Один вопрос, который решает выбор
Единица работы в amoCRM — сделка. У неё есть сумма, этап воронки, ответственный и лента коммуникаций. Товары там появиться могут: есть каталог, есть возможность привязать список позиций. Но сумма сделки остаётся одним числом, а состав заказа — приложением к нему. Единица работы в RetailCRM — заказ. У него есть позиции с количеством, ценой и скидкой, статус доставки, склад отгрузки, оплата и её состояние, а сумма пересчитывается из состава автоматически.
Набор сущностей системы и связей между ними: что считается объектом, какие у него есть поля и что из чего вычисляется. Модель данных нельзя перенастроить — её можно только дополнить доработкой. Именно поэтому выбор системы фактически сводится к выбору модели данных, а не набора кнопок.
| Что | amoCRM | RetailCRM |
|---|---|---|
| Единица работы | Сделка с суммой и этапом | Заказ с позициями и статусами |
| Состав заказа | Каталог товаров как дополнение к сделке | Строки заказа: товар, количество, цена, скидка |
| Пересчёт суммы при изменении состава | Дописывается | Штатно |
| Частичная отмена позиции | Дописывается | Штатно |
| Возврат части заказа | Дописывается | Штатно |
| Остатки и резерв под заказ | Из внешней системы, через доработку | Штатно, с обменом складами |
| Несколько отгрузок по одному заказу | Ломает модель, нужны связанные сделки | Штатно |
| Длинная сделка с переговорами на 2–3 месяца | Штатно, это её профиль | Работает, но воронка беднее |
| Лента переписки и звонков в карточке | Сильная сторона | Есть, но собрана вокруг заказа |
Сравнение в две колонки. Левая подписана «amoCRM: сделка»: прямоугольник с полями «Клиент», «Сумма — одно число», «Этап воронки», под ним лента сообщений. Правая подписана «RetailCRM: заказ»: прямоугольник с таблицей из четырёх строк «товар — количество — цена», под таблицей строка «Итого вычисляется», сбоку три статуса: «оплата», «сборка», «доставка». Внизу под обеими колонками подпись: «Частичная отмена: слева доработка на 120 000 ₽, справа штатная операция». Чертёжный стиль, подписи по-русски.
Что ломается, когда товарный заказ живёт в сделке
Пока заказ едет по прямой — оформлен, оплачен, отгружен, — разницы почти не видно. Она появляется на отклонениях, а их в рознице от 8 до 20 % заказов. Клиент отказывается от одной позиции из четырёх. Товара не хватило, и часть заказа уезжает второй посылкой через три дня. Половину заказа вернули, а вторую оставили. Курьер привёз, покупатель отказался на пороге. В системе, где заказ — это сделка с одной суммой, каждая такая ситуация решается либо руками менеджера в комментарии, либо доработкой.
Когда частичная отмена оформляется текстом в карточке, сумма сделки перестаёт соответствовать отгруженному. Через полгода выручка в CRM расходится с учётной системой на 3–7 %, и никто не может объяснить, откуда взялась разница. Это ломает не только отчёт: на этих же числах считаются премии менеджеров и рентабельность товарных групп.
Товарный контур в amoCRM собирается — это обычная инженерная работа, и она стоит понятных денег. Ниже модельная смета для магазина с 3 000 заказов в месяц: восемь пользователей, четыре склада отгрузки, обмен с учётной системой уже есть.
Здесь важно не ошибиться в выводе. Эти 420 000 ₽ не означают, что amoCRM плохая система: она отлично делает то, для чего построена. Они означают, что вы платите за приведение инструмента продаж к задаче товарного учёта — и после сдачи получаете код, который придётся сопровождать при каждом обновлении. Если товарных отклонений у вас мало, а сделка длинная и сложная, эта плата оправдана. Если наоборот — вы покупаете себе постоянную статью расходов.
Каталог, остатки и обмен с учётом
Второй узел расхождения — обмен с учётной системой. Магазину нужны из учёта три вещи: номенклатура с ценами, остатки по складам и статус оплаты. Обратно уходят заказы и отгрузки. У RetailCRM обмен с МойСклад и с типовыми конфигурациями 1С реализован модулями, и работа сводится к настройке соответствия справочников. У amoCRM обмен строится через интеграционную платформу или собственную прослойку, потому что штатной сущности «остаток на складе» в системе нет — её надо куда-то положить.
| Задача обмена | amoCRM | RetailCRM |
|---|---|---|
| Номенклатура и цены из учёта | Через прослойку в каталог, с ограничениями по объёму | Штатный модуль |
| Остатки по складам | Своё хранилище остатков, доработка | Штатно, с резервом под заказ |
| Заказ обратно в учётную систему | Прослойка, сопоставление полей вручную | Штатный модуль |
| Возврат и корректировка | Отдельная доработка | Штатно |
| Смена конфигурации 1С | Переписывается прослойка | Меняется настройка модуля |
Отдельно стоит решить, где вообще у вас живёт товар. Если учёт ведётся в МойСклад или 1С:УНФ, то CRM может быть тонкой: она принимает заказ, ведёт клиента и отдаёт заказ в учёт. Мы разбирали эту развилку подробно в материале МойСклад или 1С:УНФ — там же критерии, по которым магазин перерастает облачный учёт. А механику самого обмена и типичные грабли с ценами и остатками — в статье обмен остатками и ценами с сайтом.
Карта связей систем. Четыре узла: «Витрина магазина», «CRM (amoCRM или RetailCRM)», «Учёт: 1С или МойСклад», «Кабинеты Wildberries и Ozon». Стрелки с подписями: витрина → CRM «заказ, контакт»; CRM ↔ учёт «номенклатура, остатки, отгрузка»; учёт ↔ кабинеты «остатки, цены, заказы»; кабинеты → CRM пунктиром с пометкой «только через отдельный сервис». Узел кабинетов обведён отдельной рамкой с подписью «300 000–500 000 ₽ в смете независимо от выбора CRM». Чертёжный стиль, подписи по-русски.
Маркетплейсы: третий контур, который не закрывает ни одна CRM
Частая ошибка на этапе выбора — считать, что CRM «умеет маркетплейсы». Ни amoCRM, ни RetailCRM не подменяют кабинет Wildberries или Ozon: у площадок свои правила публикации карточек, свои схемы отгрузки, свои статусы и свои возвраты. CRM в этой схеме получает заказ площадки как факт, но управление ассортиментом, ценами и поставками остаётся в отдельном контуре.
Практический вывод для сметы: строка «маркетплейсы» одинакова при любом выборе CRM — 300 000 ₽ на среднем объёме и до 500 000 ₽ при тридцати тысячах заказов в месяц. Она не должна участвовать в сравнении систем, но обязана участвовать в бюджете. Механику трёх схем работы с площадками и распределение единого остатка мы разбирали в отдельном материале про интеграцию магазина с маркетплейсами, включая лимиты по частоте обновления.
Витрина отвечает за приём заказа, CRM — за клиента и коммуникации, учётная система — за товар и деньги, кабинеты площадок — за продажи на площадках. Система, которая пытается закрыть все четыре роли, всегда делает три из них хуже отдельного инструмента. Как это раскладывается по связям и что передаётся между узлами — на странице интеграции систем.
Триггерные цепочки и каналы связи на сентябрь 2026 года
Здесь ситуация обратная предыдущим разделам. Триггерные цепочки — брошенная корзина, напоминание об оплате, запрос отзыва после доставки, реактивация через 90 дней — есть в обеих системах, и по механике они сопоставимы. RetailCRM строит их вокруг событий заказа: смена статуса, отсутствие оплаты, факт доставки. amoCRM — вокруг событий сделки и коммуникации. Для магазина первое удобнее, но это удобство, а не блокер.
Настоящее ограничение лежит не в CRM, а в каналах. По состоянию на сентябрь 2026 года картина такая: WhatsApp вместе с WhatsApp Business API заблокирован в России с февраля 2026 года и как канал для новых внедрений не рассматривается. Telegram работает с ограничениями. MAX — основной канал для новых проектов, бизнес-профиль оформляется на business.max.ru с верификацией через Госуслуги, есть Bot API, но прямых официальных интеграций ни с amoCRM, ни с RetailCRM на начало 2026 года не было — связка собирается через собственную прослойку. Остаются также email, SMS и звонок, и именно они в 2026 году оказались самым устойчивым контуром для транзакционных уведомлений магазина.
| Канал | Статус на сентябрь 2026 | Роль в цепочках магазина |
|---|---|---|
| WhatsApp и WhatsApp Business API | Заблокирован в РФ с февраля 2026 | Не использовать в новых проектах |
| MAX | Работает, есть Bot API, прямого коннектора к CRM нет | Основной канал, через свою прослойку |
| Telegram | Работает с ограничениями | Дополнительный канал, не единственный |
| Работает | Чеки, статусы заказа, реактивация | |
| SMS и звонок | Работает | Запасной контур для критичных уведомлений |
Инженерный вывод, который стоит заложить в проект независимо от выбора CRM: канал связи в 2026 году — расходуемый ресурс. Прослойка, которая прячет мессенджер за единым форматом сообщения, добавляет к смете 20 000–25 000 ₽ и неделю работы, зато следующая смена канала стоит одного адаптера, а не повторной оплаты интеграции.
Стоимость владения при 300, 3 000 и 30 000 заказов в месяц
Считаем одинаковый объём работ на горизонте 36 месяцев: приём заказов с витрины, обмен с учётной системой, триггерные цепочки, бот в мессенджере, обучение и сопровождение. Лицензии взяты как модельный ориентир на сентябрь 2026 года — 1 200 ₽ за пользователя в месяц для amoCRM и 2 000 ₽ для RetailCRM. Тарифные линейки вендоров меняются, и у RetailCRM цена дополнительно зависит от числа заказов в пакете, поэтому проверяйте прайс на день расчёта: структура сметы от этого не изменится, а числа сдвинутся.
| Объём и число пользователей | amoCRM с товарным контуром | RetailCRM | Разница за 36 мес |
|---|---|---|---|
| 300 заказов в месяц, 3 пользователя | 837 600 ₽ | 774 000 ₽ | 63 600 ₽ — 7,6 % |
| 3 000 заказов в месяц, 8 пользователей | 2 313 600 ₽ | 1 916 000 ₽ | 397 600 ₽ — 17,2 % |
| 30 000 заказов в месяц, 25 пользователей | 5 100 000 ₽ | 4 210 000 ₽ | 890 000 ₽ — 17,5 % |
Разберём средний столбец, чтобы было видно, из чего складывается разрыв в 397 600 ₽ на трёх тысячах заказов. Лицензии здесь работают против RetailCRM: 576 000 ₽ против 345 600 ₽ за три года. Всё остальное работает в обратную сторону.
Интереснее другой срез тех же чисел — цена системы в пересчёте на один заказ. За 36 месяцев магазин на 300 заказов проведёт через систему 10 800 заказов, магазин на 3 000 — 108 000, магазин на 30 000 — 1 080 000. Делим смету на количество и получаем: 78 ₽ и 72 ₽ за заказ на малом объёме, 21 ₽ и 18 ₽ на среднем, 4,7 ₽ и 3,9 ₽ на большом. Разброс в шестнадцать раз, и он объясняет, почему один и тот же совет не работает для магазина на 300 и на 30 000 заказов.
Столбчатая диаграмма из трёх пар столбцов, ось значений в рублях. Пара «300 заказов в месяц»: amoCRM 837 600 ₽ и RetailCRM 774 000 ₽, скобка «разница 63 600 ₽, 7,6 %». Пара «3 000 заказов»: 2 313 600 ₽ и 1 916 000 ₽, скобка «397 600 ₽, 17,2 %». Пара «30 000 заказов»: 5 100 000 ₽ и 4 210 000 ₽, скобка «890 000 ₽, 17,5 %». Под каждой парой мелкая подпись «цена одного заказа»: «78 и 72 ₽», «21 и 18 ₽», «4,7 и 3,9 ₽». Горизонт 36 месяцев указан в подписи к оси. Чертёжный стиль, подписи по-русски.
Сколько стоит ошибка: обратный переезд на одиннадцатом месяце
Типичный сценарий ошибки выглядит так. Магазин с 3 000 заказов в месяц выбирает amoCRM, потому что лицензии дешевле и знакомый интерфейс. Первые месяцы всё хорошо: воронка работает, менеджеры довольны. К седьмому месяцу накапливаются отклонения — частичные отмены, вторые отгрузки, возвраты. К девятому выясняется, что выручка в CRM не сходится с учётом. К одиннадцатому принимается решение переезжать.
Сопоставление этих двух чисел и есть главный практический вывод статьи. Разница в стоимости владения — 397 600 ₽ за 36 месяцев, то есть 11 044 ₽ в месяц. Переезд стоит 1 344 400 ₽, что равно этой разнице за 121 месяц, то есть за десять лет вперёд. Экономия на выборе не окупает ошибку выбора ни при каком горизонте планирования, который имеет смысл для магазина.
Два столбца разной высоты на общей оси в рублях. Низкий столбец подписан «разница в стоимости владения за 36 месяцев — 397 600 ₽». Высокий подписан «обратный переезд на 11-м месяце — 1 344 400 ₽» и разбит на сегменты с подписями: «списанная доработка 420 000 ₽», «повторное внедрение 210 000 ₽», «перенос данных 160 000 ₽», «обмены 150 000 ₽», «триггеры 90 000 ₽», «двойная работа 134 400 ₽», «просадка 180 000 ₽». Между столбцами стрелка с подписью «10 лет экономии». Чертёжный стиль, подписи по-русски.
Обратная ошибка тоже существует, но обходится дешевле. Компания с длинными сделками, купившая RetailCRM ради «правильных заказов», обнаруживает, что воронка переговоров и работа с касаниями там беднее. Переезд в этом направлении стоит примерно 600 000–700 000 ₽ на том же масштабе: списывать нечего, кроме настройки, а история сделок переносится проще, чем история отгрузок. Асимметрия в том, что дописать товар в систему продаж сложнее, чем дописать переговоры в систему заказов.
Когда выбирать не из чего: три ситуации без CRM
Отдельный сценарий, о котором не расскажет ни один интегратор: вариант «не покупать ничего». Он честно выигрывает в трёх случаях, и на малом объёме заказов выигрывает почти всегда — вспомните цену в 72–78 ₽ за один заказ.
- 1Меньше 300 заказов в месяц и один канал продаж. Витрина принимает заказ, МойСклад ведёт товар и деньги, уведомления клиенту шлёт движок магазина. CRM здесь добавляет 774 000–837 600 ₽ за три года и не добавляет ни одного нового заказа. Возвращаться к вопросу имеет смысл, когда появится второй канал или второй склад.
- 2Заказы приходят почти целиком с маркетплейсов. Если 80 % оборота идёт через кабинеты Wildberries и Ozon, то ваша реальная боль — ассортимент, цены и поставки, а не работа с клиентом: клиент в этой модели принадлежит площадке. Деньги правильнее вложить в контур площадок и в генерацию карточек товаров, а не в CRM.
- 3Ассортимент из десятка позиций и повторяющиеся клиенты. Оптовик с сорока постоянными покупателями и стабильной номенклатурой закрывает задачу учётной системой и таблицей заявок. Здесь не хватает не CRM, а регламента: кто перезванивает, в какой срок и что делает при отказе.
И последнее предупреждение, общее для обоих вариантов. CRM не наводит порядок в данных — она его наследует. Если у вас дублируются контакты, телефоны записаны в свободной форме, а половина заказов правится руками после отгрузки, то перенос этого в новую систему даст те же проблемы плюс стоимость лицензий. Сначала — сверка справочников и правила ввода, потом — выбор системы. Что именно проверить до старта, мы разобрали в материале данные перед внедрением.
Выбирают не систему, а модель данных. Кнопки перерисовываются за неделю, модель — только переездом.
