B2B-продажи с ИИ на 1С: как перестать терять заказы, когда нужного товара нет

1.    Часть 1. Пролог: звонок, который решает квартал

Представьте: менеджер открывает Заказ клиента в 1С. Нужного артикула нет — классическая точка потерь. Раньше — долгая переписка и «давайте перезвоню». Теперь — панель «Аналоги и замены»: за 0.5 секунды — совместимые позиции с пояснением «почему можно», остатками, сроками и маржой. Клиенту не приходится ждать, а вы сохраняете сделку и, нередко, повышаете маржу.

Исследовательская постановка

Вопрос: можно ли научить 1С предлагать безопасные и прибыльные замены «здесь и сейчас»?

Гипотеза: да, если объединить три источника знаний:

1.    Характеристики и паспорта изделий (что именно совместимо),

2.    Поведение B2B-покупателей (что реально заменяли),

3.    Коммерческие приоритеты (маржа, склад, сроки, политика брендов).

Критерии успеха:

●       +20–40% конверсии строк «нет на складе»,

●       +3–12% к выручке категории за счёт замен,

●       −60–80% времени подбора аналога,

●       возвраты по «плохим» заменам <1–2%.

Как это работает (человеческим языком)

1.    ИИ «понимает» карточку товара: вынимает из паспортов и описаний важные параметры (размеры, классы, допуски, сертификаты).

2.    Находит технически похожие SKU по смыслу, а затем фильтрует, оставляя только те, где критичные параметры совпадают «в ноль».

3.    Учитывает бизнес-контекст: остатки, сроки, маржу, правила брендов, договорные цены клиента.

4.    Показывает 5–10 лучших вариантов прямо в документе 1С — с прозрачным «почему именно эти».

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

Где это живёт в 1С (конкретика под УТ 11, КА 2, ERP 2, ERP УХ)

— Для УТ 11: расширяем форму ЗаказКлиента, берём номенклатуру/цены/остатки, вешаем подписки на изменение карточек.
— Для КА 2: добавляем контекст склада/производства и комплектность.
— Для ERP 2: учитываем спецификации (BOM) и согласование замен в составе изделия.
— Для ERP УХ: централизуем словари и политики для холдинга, поддерживаем межфирменные правила.

Технические детали по объектам и событиям — в Приложении A ниже (всё уже расписано).

Что делать с «таблицами соответствий» и «паспортами», если их нет

Это нормально: большинство компаний стартуют без единого репозитория. Рабочий путь:

1.    Кросс-референсы: создаём единый регистр соответствий (источник/замена/тип/критичность/доказательство).

2.    Паспорта: собираем файлы в один справочник (или DMS), вытягиваем текст, структурируем ключевые параметры.

3.    Словарь характеристик: нормализуем единицы (мм↔см), фиксируем допуски и критичность параметров по категориям.

4.    Качество данных: минимальный «контроль входа» и процесс экспертной валидации — чтобы ошибка не ушла в продажи.

Методология бизнес-правил без привязки к брендам

Принципы: безопасность (совместимость) → экономика (маржа/срок/остаток) → политика брендов → индивидуальные условия клиента.
Классы политик брендов: Нейтральный / Предпочтительный / Ограниченный / Запрещённый — бренды позже просто маппятся в эти классы.
Формула ранжирования (простыми словами): сначала — что точно подходит, потом — что быстрее поставим и выгоднее продадим, при этом учитываем «затаренность» складов и сегмент клиента (тендерный vs сервисный).

Экшн-план (2 формата внедрения)

Вариант А — с пилотом (самый безопасный и быстрый способ показать эффект)

●       Объём: 1–3 категории, до 1 000 SKU, 5–10 менеджеров.

●       4 шага: подготовка данных → прототип панели в 1С → A/B-тест → донастройка правил и запуск.

●       Результат: измеримый прирост конверсии и валовой прибыли, кейс для масштабирования.

Вариант Б — сразу в прод без пилота

●       Каскадный запуск по подразделениям/складам с фича-флагом «Разрешить замены ИИ».

●       Ограждения: 100% совпадение критичных параметров, обязательное согласование в рисковых категориях, полное логирование и быстрый откат.

Что получит бизнес (и почему это выгодно именно вам)

●       Вы удерживаете спрос даже при дефиците — клиенту всегда есть что предложить «здесь и сейчас».

●       Растёт маржа: механизм мягко продвигает выгодные, но совместимые альтернативы.

●       Снижается операционная нагрузка: менеджер тратит секунды, а не часы на подбор.

●       Выстраивается капитал знаний: ваши решения превращаются в корпоративный «мозг» замен.

Маркетинговая составляющая под вас:

●       В презентациях и тендерах показываете, что у вас — умные замены с объяснимостью (не «угадайка», а регламентированный инструмент).

●       В коммуникации с клиентами — «мы не просто продаём, мы сохраняем ваш процесс»: подберём эквивалент под стандарты и сроки.

●       В переговорах с поставщиками — аргументируете закупки данными по фактическим заменам и спросу.

Что нужно от вас для старта

1.    Доступ к тестовой базе одной из конфигураций (УТ 11/КА 2/ERP 2/ERP УХ).

2.    1–2 категории для пилота, по которым можно быстро собрать паспорта и базовые соответствия.

3.    Определить роли: Менеджер продаж, Тех-эксперт, Куратор брендов.

KPI и отчётность (что покажем руководству)

●       Конверсия строк «нет на складе» (до/после),

●       Добавочная валовая прибыль,

●       Время ответа менеджера,

●       Ошибочные замены/рекламации,

●       Динамика «затаренности» складов.

 

2. Часть 2. Техническое исследование

Краткая суть того что здесь описано (TL;DR)

ИИ-модуль, подключённый к 1С через REST/OData или HTTP-сервисы, превращает отсутствие нужной позиции в возможность: в карточке заказа менеджер сразу видит технически совместимые аналоги и замены с прозрачными обоснованиями, остатками и маржой. На практике это добавляет 3–12% к выручке на «упущенных» заказах и сокращает время подбора на 60–80%.

1) Бизнес-контекст и зачем это B2B

Мы живём в новой реальности, когда происходит постоянное изменение бизнес-контекста:

●       Перебои поставок, частые смены артикула/партномера, закрытие фабрик.

●       Заказы «по спецификациям»: строгие допуски, совместимость, стандарты.

●       Большой каталог (10–500 тыс. SKU), где ручной поиск аналогов невозможен.

●       KPI отдела продаж: конверсия заявок, LTV, оборачиваемость затоваренных складов.

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

 

2) Архитектура решения

Слои:

1.    Источник данных 1С. Номенклатура, характеристики, остатки/цены, взаимозаменяемость, история заказов.

2.    ETL/Интеграция. REST/OData или кастомные HTTP-сервисы; выгрузка атрибутов и документов (описания, PDF-паспорта).

3.    Фьюжн-каталог. Единый словарь характеристик: единицы измерения, нормализация параметров (мм→см), синонимы ("болт", "винт") и соответствия ГОСТ/ISO.

4.    ML/Поиск по подобию. Текстовые и табличные эмбеддинги для описаний/характеристик; векторное хранилище (pgvector/Qdrant) + фильтры (категория, напряжение, резьба, посадка, диапазоны).

5.    Бизнес-правила. Маржа, наличие, приоритет брендов/линеек, уровень клиента, договорные цены.

6.    Сервис рекомендаций. API /recommend?sku=...&constraints=....

7.    UI в 1С. Панель «Аналоги и замены» в форме документа/заказа; объяснения «почему предложено» + быстрые действия (заменить в строке, добавить комплект, создать альтернативное КП).

Варианты развёртывания: on-prem (Windows/Linux, PostgreSQL) или облако. Латентность запроса < 300–700 мс в онлайне.

3) Данные и признаки (features)

●       Категорийные: группа, бренд, серия/линейка, страна, сертификация (EAC, CE и т. п.).

●       Технические: размеры, ток/напряжение, материал, класс защиты, резьба, тип соединения.

●       Коммерческие: RRP, спеццены, маржа, SLA поставки, склад/резерв.

●       Поведенческие: частота совместных покупок (market-basket), история замен в прошлых заказах.

●       Текст/документы: названия, описания, PDF-паспорта, таблицы соответствий.

Нормализация: приведение единиц, токенизация артикулов (ABC-123/ABC123), выделение ключевых параметров из текстов (NER), синонимы и морфология (RU/EN/DE).

4) Алгоритмы подбора аналогов

4.1 Семантический поиск

●       Эмбеддинги для названий/описаний/таблиц параметров.

●       Векторный поиск «похожих» SKU + жёсткая фильтрация по критичным свойствам (например, посадка, напряжение, разъём).

4.2 Табличное сопоставление (rule-based)

●       Правила совместимости/замены из внутренних регламентов, ГОСТ/ISO.

●       «Матрицы совместимости» (A↔B) и таблицы кросс-референсов (OEM↔замена).

4.3 Коллаборативные сигналы (B2B-поведение)

●       Часто покупали вместо; замены, принятые менеджерами ранее; «победители тендеров» по аналогам.

4.4 Итоговая оценка

score = α·semantic + β·compatibility + γ·behavior + δ·profitability + ε·availability

Вывод: в топ попадают только те аналоги, которые одновременно совместимы, есть на складе и выгодны.

5) Интерфейс в 1С (UX)

●       Панель «Аналоги и замены». Таблица с колонками: SKU, совместимость/пояснение, остаток, срок, цена, маржа, «заменить».

●       Пояснения (Explainability). «Совпали: шаг резьбы 1.25, диаметр 6 мм, класс прочности 8.8; разница: длина +5 мм». Кнопка «Показать паспорт» (PDF).

●       Горячие действия. Заменить в строке; предложить альтернативное КП; добавить комплект; закрепить выбор (feedback).

●       Контроль рисков. Плашки «требует согласования», «критичная характеристика отличается», «сертификация отсутствует».

6) Интеграция с 1С: варианты

6.1 Быстрый старт (без доработок конфигурации)

●       Публикуем стандартный REST/OData; внешний сервис подтягивает Номенклатуру, Характеристики, Цены, Остатки.

●       В 1С добавляем внешнюю обработку/расширение с формой рекомендаций, которая обращается к API рекомендаций.

6.2 Глубокая интеграция

●       HTTP-сервисы в 1С для событий «Изменение номенклатуры/Цены/Остатка» (webhook в ML-сервис).

●       Подписки на события для логирования замен и обучения модели.

●       Расширение конфигурации (УТ/КА/ERP) для хранения принятых замен, причин и ограничений.

Безопасность: отдельный пользователь/роль для REST, IP-allowlist, HTTPS/MTLS, аудит вызовов.

7) Эталонный поток данных

1.    Менеджер открывает заказ → сервис получает SKU + контекст (клиент, отрасль, ограничения).

2.    Векторный поиск кандидатов (k=50) + фильтры по характеристикам.

3.    Пересчёт цен, наличие, маржа в реальном времени из 1С.

4.    Ранжирование и объяснения.

5.    Возврат топ-5/10; менеджер выбирает → запись факта «замены» в 1С → обратная связь в обучение.

 

8) Модель данных и словарь характеристик

●       SKU (карточка): атрибуты, связи (совместимость, аналоги, комплектующие), документы.

●       Характеристика: имя (нормализовано), единицы, тип сравнения (точное/диапазонное/категорийное), критичность.

●       Словарь синонимов: «гайка»=«шестигранная гайка», M6↔6 мм резьба, AC↔переменный ток.

●       Кросс-референсы: OEM→Aftermarket; старый→новый артикула; внутренние соответствия.

9) Модели и стек

●       Эмбеддинги: многоязычные (ru/en/de) для описаний/таблиц; отдельные эмбеддинги для структурированных признаков.

●       Векторное хранилище: pgvector (PostgreSQL) или Qdrant.

●       Онлайн-сервис: Python/FastAPI/Go; ANN-поиск (HNSW/IVF-PQ).

●       Формулы совместимости: DSL правил (YAML), валидируемый доменными экспертами.

●       Объяснимость: Shapley-подобные веса по признакам, текстовое резюме.

10) Метрики успеха (до/после)

●       Конверсия строк с «нет на складе». Цель: +20–40%.

●       Доп. выручка с замен: +3–12% от оборота категории.

●       Время ответа менеджера на запрос аналога: −60–80%.

●       Доля «ошибочных» замен (возвраты/рекламации): <1–2% (с порогами по критичности).

11) Запуск по шагам (8–10 недель)

Неделя 1–2. Аудит данных 1С, выбор интеграции, выгрузка эталонного каталога, первичный словарь характеристик.

Неделя 3–4. Прототип: эмбеддинги + векторный поиск, первичные правила совместимости. Внешняя обработка/панель в 1С.

Неделя 5–6. Подтягиваем цены/остатки онлайн, A/B на части менеджеров. Сбор обратной связи.

Неделя 7–8. Тонкая настройка ранжирования, отчёты по прибыльности, политика брендов.

Неделя 9–10. Промышленные SLA, безопасность, документация, обучение команды.

12) Риски и как их снизить

●       Неполные характеристики. Заполняем автоматически из паспортов/прайсов, ставим «критичность» параметров.

●       Неверная замена. Два уровня подтверждения: автоматический и экспертный; пороги допуска.

●       Юридические ограничения. Для «допущенных замен» – отдельные шаблоны КП и договорные оговорки.

●       Сопротивление менеджеров. Объяснимость подборов + мотивация за подтверждённые рекомендации.

13) Как это выглядит в 1С (макет UI)

[Документ: Заказ клиента]

├─ Товары (табличная часть)

│ • 00-123 Болт М6×25 — НЕТ на складе

│

└─ Панель «Аналоги и замены»

SKU Совпадения Остаток Срок Цена Маржа Действия

00-456 резьба 1.0; 120 1 д 0.95 18% [Заменить]

диаметр 6мм

00-789 резьба 1.0; 40 3 д 0.89 21% [Заменить]

диаметр 6мм; длина +5мм

[Пояснение] «совместим по ГОСТ 7798-70; критичное отличие: длина»

 

14) Псевдокод интеграции

Вызов внешнего сервиса из 1С (клиент/сервер)

Функция ПодобратьАналоги(SKU, Контекст)

URL = СтрШаблон("https://reco.example/api/recommend?sku=%1&quot;, SKU);

Тело = Новый Структура("client_id, price_list, must_have", Контекст.Клиент, Контекст.Прайс, Контекст.Ограничения);

HTTP = Новый HTTPЗапрос(URL);

HTTP.УстановитьТелоИзСтроки(СтрокаJSON(Тело));

HTTP.Заголовки.Вставить("Content-Type","application/json");

Ответ = HTTPСоединение.Выполнить(HTTP);

Если Ответ.КодСостояния = 200 Тогда

Возврат ПрочитатьJSON(Ответ.Текст);

Иначе

Возврат Неопределено;

КонецЕсли;

КонецФункции

Эскиз API ранжирования (FastAPI)

@app.post("/recommend")

async def recommend(sku: str, ctx: Context):

q = compose_query(sku, ctx)

candidates = vector_search(q, k=50, filters=ctx.filters)

enriched = fetch_prices_stocks(candidates, ctx)

ranked = rerank(enriched, ctx)

return format_top(ranked, explain=True)

 

15) Экономический эффект

●       Снижение потерь на out-of-stock.

●       Рост среднего чека за счёт комплектов/альтернатив.

●       Вывод затоваренных остатков через «умные» аналоги.

●       Ускорение подготовки КП и тендерных замен.

 

16) Что понадобится от заказчика

●       Обратиться в нашу компанию и заключить контракт на работы.

●       Доступы к тестовой базе 1С (чтение Номенклатуры/Цен/Остатков, создание внешних обработок/расширений).

●       Экспорт эталонной матрицы соответствий (если есть), описаний/паспортов, политики брендов.

●       Назначение экспертов по трём ключевым категориям для первичного обучения.

 

17) Roadmap расширений

●       Добавить CV-модуль: поиск по фото детали/этикетки.

●       Проверка сертификации/регуляторики по артикулу.

●       Мультиканальный режим: предложения в email-КП и в личном кабинете B2B-портала.

 

18) Итоги 

Интеграция 1С с ИИ-подбором аналогов — это быстрая, экономически оправданная модернизация процесса B2B-продаж. Она минимально вмешивается в 1С, но радикально улучшает реакцию на дефицит и качество клиентского сервиса. Запускается поэтапно за 8–10 недель и масштабируется на весь ассортимент.

 

3. Часть 3. Архитектура решения и методология внедрения системы интеллектуального подбора аналогов в 1С

19) Конкретика по конфигурациям: УТ 11, КА 2, ERP 2 и ERP УХ

19.1 Общие принципы для всех конфигураций

●       Источник правды по SKU: Справочник.Номенклатура + ХарактеристикиНоменклатуры (если включены размеры/параметрические признаки).

●       Цены/остатки: РегистрСведений.ЦеныНоменклатуры (или прайс-регистры конфигурации) и РегистрНакопления.ОстаткиТоваров/ОстаткиТоваровНаСкладах.

●       Документы продаж: Документ.ЗаказКлиента (УТ/КА/ERP) и Документ.ЗаказПокупателя (варианты имен в конкретном релизе).

●       Интеграция: публикация REST/OData, HTTP-сервисы, подписки на события (изменение карточки, цены, остатка).

19.2 УТ 11 (Управление торговлей)

●       Нормативно-справочная: Номенклатура, Характеристики, ВидыНоменклатуры, ЕдиницыИзмерения.

●       Коммерческие данные: Прайс-типы (виды цен), регистр скидок/наценок, соглашения с клиентами.

●       Внедрение UI: расширение формы ЗаказКлиента с панелью «Аналоги и замены» + общий модуль для вызова внешнего API.

●       События: подписки на Запись Номенклатуры/Цены для актуализации эмбеддингов/словаря.

19.3 КА 2 (Комплексная автоматизация)

●       Дополнительно к УТ: склад/производство; учитываем спецификации, комплектность.

●       Для совместимости: хранение ключевых параметров изделия в Характеристиках + регистры сведений для ГОСТ/сертификации.

●       UI: аналогично УТ 11, плюс кнопки «создать альтернативное КП/комплект».

19.4 ERP 2

●       Расширенные NPD/планирование: важно подтягивать спецификации (BOM) и маршруты для проверки доступности альтернатив в составе изделия.

●       Для «замены по спецификации»: регистр «РазрешённыеЗаменыВСпецификациях» (кастом) + процесс согласования (Документ «СогласованиеЗамены»).

●       UI: панель рекомендаций в формах ЗаказКлиента, ЗаказНаПроизводство, Спецификация (режим подсказок при редактировании состава).

19.5 ERP УХ (Управление холдингом)

●       Централизация справочников: единый каталог и межфирменные правила замены (между организациями/филиалами).

●       Модель: «глобальный словарь характеристик» (регистры сведений) + правила трансформации на дочерние компании.

●       UI: те же панели, но с учётом ролей холдинга; флаг «замена разрешена только в дочерних с подтверждением ЦФО».

 

20) Где хранить «таблицы соответствий» и «паспорта изделий» (рекомендации)

20.1 Таблицы соответствий / кросс-референсы

●       Создать РегистрСведений.КроссРеференсыНоменклатуры:

o   ИзделиеИсточник (СсылкаНоменклатура)

o   ИзделиеЗамена (СсылкаНоменклатура)

o   ТипСоответствия (ПолныйАналог/ДопустимаяЗамена/Комплект-альтернатива)

o   ИсточникДанных (OEM/Паспорт/Эксперт/ИсторияЗаказов)

o   КритичностьОтличий (Низкая/Средняя/Высокая)

o   Комментарий/СсылкаНаДокумент

o   Дата, Автор, Версия

●       Для ERP 2 добавьте измерение Спецификация/BOM для контекстных замен.

●       Подписки: блокировать «замкнутые циклы» (A→B→A) и дубликаты; автоматом формировать «обратную» запись при полном аналоге.

20.2 Технические паспорта/сертификаты

●       Создать Справочник.ТехническиеПаспорта (или использовать встроенный «Файлы/Вложения», если принят в вашей конфигурации):

o   Владелец (Номенклатура/Характеристика)

o   ТипДокумента (Паспорт/Сертификат/ЛистДанных/ПротоколИспытаний)

o   Номер/Дата/СрокДействия

o   ХранилищеФайла (встроенное/внешний DMS/S3/SharePoint)

o   Язык/Страна/Стандарт (ГОСТ/ISO/CE/EAC)

●       Индексируйте текст/таблицы паспортов (парсер PDF→текст) и сохраняйте структурированные параметры в регистре ПараметрыНоменклатуры.

●       Для безопасности: роли «Просмотр технических документов» + метки доступа по брендам/категориям.

20.3 Где хранить словарь характеристик

●       РегистрСведений.СловарьХарактеристик: КодПараметра, Наименование, Единица, ТипСравнения (точное/диапазон), Синонимы, Язык, Критичность.

●       Автозаполнение из паспортов + ручная валидация экспертом категории (бизнес-процесс согласования).

 

21) Методология бизнес-правил по брендам и марже (без привязки к брендам)

21.1 Принципы

1.    Безопасность и совместимость первичны: замена не должна снижать класс/допуск критичных параметров.

2.    Маржинальность и доступность вторичны: среди совместимых выбираем по марже/сроку/остатку.

3.    Прозрачность: каждое предложение сопровождается «почему именно оно».

21.2 Слои правил

●       Слой совместимости (hard filters):

o   Совпадение критичных параметров = 100% (например, напряжение, посадка, интерфейс).

o   Некритичные параметры ±допуск (например, длина ±5%).

o   Сертификация: регион/отрасль обязательны (EAC/CE/пищевое, пожарная безопасность и т.п.).

●       Слой коммерции (soft ranking):

o   Приоритет по валовой прибыли (цена продажи − закупка) с поправкой на SLA поставки.

o   Если клиент «цено-чувствительный» (сегмент B2B-Tender), снижать вес маржи и повышать вес цены.

o   Учесть затаренные остатки: надбавка к рангу для складов с избытком (X дней запасов > целевого).

●       Слой брендов (policy-agnostic):

o   Типы отношений: Нейтральный, Предпочтительный, Ограниченный, Запрещённый.

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

o   Если у клиента в договоре «фиксированный бренд» — разрешать только эквиваленты внутри бренда, иначе требовать согласование.

21.3 Формула ранжирования (пример)

Score = α·Совместимость + β·Прибыльность + γ·Доступность + δ·ПриоритетКлиента + ε·Затаренность

●       Порог выдачи: Score ≥ 0.65 и Совместимость = 1.0.

●       Для «Ограниченных» брендов — множитель 0.7; для «Предпочтительных» — 1.1.

21.4 Процесс согласования

●       Автопорог: если отличие затрагивает критичный параметр → статус «Требуется согласование» (роль ТехЭксперт/Куратор бренда).

●       Логирование: кто, когда, почему утвердил; хранить связь с заказом/КП.

 

22) Сценарии внедрения: с пилотом и без пилота

22.1 С пилотом (рекомендуемый)

●       Объём: 1–3 категории (до 1 000 SKU), 5–10 менеджеров, 1–2 склада.

●       Этапы:

1.    Подготовка данных (словари/паспорта/кросс-референсы базового уровня).

2.    Прототип сервиса рекомендаций + панель в 1С.

3.    A/B-тест: доля выдачи по аналогам vs контроль.

4.    Настройка правил и весов, обучение команды.

●       Метрики успеха: конверсия строк «нет на складе», добавочная валовая прибыль, время ответа на запрос аналога, доля согласованных замен без рекламаций.

●       Выход в прод: по категориям с лучшими метриками.

22.2 Без пилота (тотальное внедрение с безопасными ограждениями)

●       Подход: каскадный запуск по подразделениям/складам, фича-флаг «Разрешить замены ИИ».

●       Ограждения:

o   Жёсткий порог Совместимость=1.0, обязательное согласование для критичных отраслей.

o   Логирование всех замен, ежедневные отчёты отклонений.

o   Кнопка отката «Вернуть исходную позицию» в документе.

●       План восстановления: если SLA/качество проседают — отключаем правило по категориям до ретюнинга модели.

 

23) Мини-ТЗ (скелет) под ваши конфигурации

●       API 1С → ИИ: /catalog/export, /stockprice/get, /recommend.

●       События: OnWrite(Номенклатура/Цена/Остаток) → шина (HTTP/очередь) → обновление эмбеддингов/индекса.

●       РегистрСведений: КроссРеференсыНоменклатуры, ПараметрыНоменклатуры, СловарьХарактеристик.

●       Справочники: ТехническиеПаспорта (или Вложения), КлассыБрендПолитик.

●       Роли: МенеджерПродаж, ТехЭксперт, КураторБренда, АдминИнтеграций.

●       Отчёты: Метрики замен, прибыльность, рекламации, A/B.

Специалист компании ООО "Кодерлайн"

Денис Макушев