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

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

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

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

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

Чем конфигуратор отличается от калькулятора стоимости

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

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

Два похожих интерфейса могут сильно отличаться по объему разработки, срокам и стоимости.

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

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

О том, как объем такой логики влияет на архитектуру проекта, писали в статье «Простой или сложный сайт».

Когда для товара достаточно обычного калькулятора

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

Обычно достаточно калькулятора, если:

• Результатом становится сумма, объем или другой расчетный показатель

• Параметры можно менять независимо друг от друга

• Значение одного поля не ограничивает варианты в другом

• Отдельная позиция номенклатуры после расчета не создается

• Менеджеру не нужно проверять возможность изготовления выбранного варианта

Так можно считать площадь, стоимость доставки, объем работ или цену товара с фиксированным набором доплат.

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

Когда нужен конфигуратор и где калькулятор приводит к ошибкам

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

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

Здесь система должна:

• Проверять совместимость характеристик

• Менять доступные варианты после каждого выбора

• Рассчитывать цену допустимой конфигурации

• Формировать позицию номенклатуры

• Передавать готовый состав заказа

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

Мы загрузили данные из «1С», собрали справочники и построили правила выбора: после модели покупатель видит только доступные цвета, после цвета — подходящие размеры. Пересчет удалось ускорить в 50 раз. Проект занял два года и почти 9 000 часов.

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

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

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

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

Когда нужен гибридный вариант: конфигуратор + калькулятор

Эти решения могут работать вместе.

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

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

При постановке задачи полезно разделить два вопроса:

1. Какие варианты пользователь может выбрать

2. Как рассчитывается стоимость допустимого варианта

Это разные части логики, даже если для покупателя они находятся на одном экране.

Какие данные нужны для запуска калькулятора или конфигуратора

До оценки разработки нужно описать исходные данные и правила.

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

Отдельно нужно определить, где хранятся исходные данные и кто обновляет их после запуска. Если цена приходит из одной системы, характеристики из другой, а остатки из «1С», это влияет на состав интеграций.

Путь пользователя от выбора параметров до заказа тоже стоит измерять. Какие события фиксировать на этом пути, разбирали в статье «Аналитика интернет-магазина».

Как оценить сроки и стоимость MVP конфигуратора

Срок и бюджет зависят прежде всего от логики и данных.

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

На оценку влияют:

• Количество параметров

• Количество зависимостей между ними

• Правила совместимости

• Формулы расчета цены

• Связь с номенклатурой

• Источники данных

• Состав интеграций

• Объем данных для подготовки и переноса

• Необходимость визуализации

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

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

Калькулятор или конфигуратор: что выбрать

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

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

Nineseven может разобрать сценарий выбора, данные и интеграции и оценить состав первой версии.

Обсудить разработку конфигуратора