Как выбрать платформу для интернет-магазина под каталог, учёт и оптовые продажи

Выбирая платформу для интернет-магазина, легко увлечься витриной: красивыми карточками, фильтрами и оформлением корзины. Но первый сложный вопрос может появиться уже после покупки. Какую цену увидит оптовик? Откуда возьмётся остаток? Что произойдёт, если менеджер изменит заказ в учётной системе?

Я бы выбирал платформу на таких действиях. Берёте свой каталог и несколько рабочих ситуаций, проверяете их в кандидатах, затем сравниваете запуск и дальнейшую эксплуатацию. Получается гораздо полезнее, чем искать «лучшую платформу для интернет-магазина» без условий. Ниже — порядок этой проверки и матрица, которую можно использовать на встрече с исполнителем.

Как описать магазин до выбора платформы

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

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

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

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

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

Какие классы решений сравнивать

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

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

CMS не стоит оценивать по цене лицензии в отрыве от проекта. Сравните настройку, необходимые дополнения, интеграции и сопровождение. А у индивидуальной разработки проверьте, зачем нужны именно свои функции. Формулировка «у нас особенный бизнес» пока ничего не объясняет исполнителю.

Сравнивайте классы решений по одним и тем же требованиям компании.

Как проверять учёт и оптовые сценарии

Представим условного поставщика расходных материалов. У него розничные покупатели и компании с согласованными ценами. В качестве теста можно взять один товар в двух упаковках и заказ клиента с индивидуальными условиями. Это пример проверки, а не описание внедрения конкретного заказчика.

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

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

Следующий шаг — изменение. Например, менеджер согласовал замену позиции. Что увидит покупатель, какая система хранит итоговый состав и как предотвращается перезапись более свежих данных? До подключения 1С нужно договориться о ведущей системе для каждого значения. Список таких вопросов есть в статье о подготовке интеграции сайта с 1С.

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

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

Как оценить эксплуатацию и возможность смены решения

Выбирая платформу, вы выбираете и способ дальнейшей работы с ней. Назовите человека или команду, которые будут отвечать за обновления, доступы, резервные копии, ошибки покупки и интеграции. Если разные части ведут разные исполнители, заранее определите, кто начинает разбор общей неисправности.

Спросите, как обновляется платформа при наличии доработок. Где их проверяют до рабочего сайта, кто исправляет несовместимость и что входит в сопровождение. Ответ «у нас всё обновляется» мало полезен без описания ответственности.

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

Уточните доступность специалистов по конкретному решению и условия передачи другому подрядчику. Здесь важны не только популярность платформы, но и документация ваших доработок, доступы компании, структура обмена и возможность развернуть проверочную копию. Полную смету такого проекта удобнее собирать по статьям затрат интернет-магазина.

Как принять решение по матрице

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

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

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

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

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