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

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

Битрикс24 как рабочее пространство

• На сегодня — понятное пространство, над которым работали долго; основной интерфейс менеджера.
• Битрикс не обсуждается на замену — от него не уходят.
• Предложение Аrona — интересное решение с плюсами и минусами; всё нужно тестировать параллельно.

Концепция «ядра»

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

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

Откуда данные каталога

• Сценарий 1 (MVP): карточки сделок, которые уже в работе или на определённой стадии в Битрикс24 / на сайте — когда карточка достаточно заполнена (описание, характеристики, стоимость, фото).
• Сценарий 2 (позже): парсинг внешних площадок (Китай и др.) — отдельная стадия после тестирования и запуска основного контура.
• Первоначально — рабочий материал из текущих заявок: поступила заявка → собрали информацию → карточка готова для каталога.

Установка приложения и риски

• Классический путь: сайт предлагает установить приложение (как у многих сервисов).
• Альтернатива из опыта: ссылка по SMS (пример ВТБ) — APK вне Google Play / App Store.
• Риск Google (с ~августа/сентября): ограничения на установку сторонних APK — для обычного покупателя авто это вызывает сомнения («надо ли ставить?»).
• Для партнёрского каталога (постоянные заказчики, офлайн на пару часов) — сценарий более реалистичен.
• Для массового B2C-клиента — сомнения; нужен маркетинговый «крючок» для установки.

Telegram Mini App

• Не игнорировать mini app в Telegram — те же формы/каталог, но пользователь не выходит из Telegram.
• Можно подключить как menu button в боте: форма, чат, каталог открываются внутри Telegram.

Показана текущая реализация: две воронки — «Telegram-бот → Китай» и «Заявка в Китай».

Воронка Telegram-бот

• Клиент стартует общение в боте → заявка падает в CRM.
• Вопросы задаются не классическим Telegram-ботом, а через стадии в Битрикс24: в чат приходит сообщение → клиент отвечает → стадия меняется. Простой и относительно дешёвый путь.
• Собираются: имя, марка, модель, год, пробег, бюджет, пожелания, контакты.
• На этапе сбора потребностей менеджер может не привлекаться.

Обработка заявки менеджером

• Заявка на стадии «обработка» → менеджер нажимает «заполнить поля».
• Нейросеть Битрикс анализирует чат и раскладывает данные по свойствам сделки + делает summary-комментарий.
• Менеджер проводит финальную проверку, может дополнить/исправить поля вручную, акцептует заявку.
• Может задать уточняющие вопросы клиенту в том же чате (в том канале, откуда пришла заявка).

WeChat и закупщики

• Заявка переходит дальше → робот формирует комментарий с набором свойств для отправки закупщикам в WeChat.
• Интеграции с WeChat нет — менеджер копирует комментарий и отправляет вручную.
• Форма подачи заявки (~10 пунктов) должна соответствовать свойствам в карточке сделки.

Коммерческие предложения

• Ответы из WeChat приходят «рваным» форматом: цена, потом фото, потом ещё текст — менеджер вручную компонует.
• Сейчас всё сводится в Excel-карточку расчёта с формулами (таможня, утильсбор, доставка и т.д.).
• Есть официальный сайт таможенной службы с калькулятором — каждую машину просчитывают и данные вкладывают в Excel.
• На стадии «подбор» — до трёх вариантов для клиента; сохраняется скрин расчётки.

Ключевой запрос: уйти от Excel-формы с формулами и максимально автоматизировать расчёт. Идеал — вставить сумму в юанях, остальное считается автоматически (таможня, утиль, формулы), нажать кнопку — клиенту улетает стандартизированный ответ с фото.

Почему не считать в Битрикс24

• Битрикс — CRM для коммуникации и накопления данных, не калькулятор.
• Опыт попыток вывести формулы по стадиям (в т.ч. по Корее) показал: сложно для системы и для пользователя, не целевой инструмент.
• Расчёты должны жить в системе Аrona (таблица / форма на сайте), результат — заполнение полей в Битрикс по API.

Целостность диалога

• Если общение началось в Telegram через интеграцию Битрикс — ответ клиенту тоже в Telegram, не в другом канале.
• Нельзя «перекидывать» сессию между системами так, чтобы клиент потерял нить диалога.
• Данные из ядра должны возвращаться в тот канал, где клиент задал вопрос (Telegram ↔ Telegram, сайт ↔ чат сайта).

Ручной труд, который остаётся

• WeChat — ручное копирование заявки и вставка ответов закупщиков.
• Менеджер вручную вбивает ключевые цифры (цена в юанях, пробег и т.д.) — остальное досчитывается.
• После проверки — кнопка «расчёт готов» → поля в CRM + ответ клиенту.

Два варианта захода клиента на текущем этапе: Telegram-бот и сайт (чат и/или CRM-форма). В обоих случаях работает сбор данных; различие — куда уходит финальный ответ.

Telegram — более короткий путь

• Клиент в боте → стадии опроса → AI заполняет поля → менеджер → WeChat → расчёт → ответ в Telegram.
• Идея с формой: можно отправить ссылку на форму в чат, но есть риск выхода из Telegram (разные устройства, браузеры, возврат непредсказуем). Mini App решает это.

Сайт — сложнее

• Клиент задаёт вопрос в чате сайта — ответ должен прийти туда же, не в Telegram.
• Сайт создаёт сделку в Битрикс → получает deal_id → привязывает к карточке на сайте для синхронизации.
• Нужен webhook/интеграция: из Битрикс инициировать сообщение в чат сайта после готовности КП.
• Опционально: синхронизация чата сайта ↔ открытая линия Битрикс, чтобы менеджер видел переписку и мог уточнять у клиента на сайте.

Объединение воронок

• Сейчас: «Telegram-бот» и «Заявка в Китай» — разные воронки.
• Целевая логика: заявка с сайта / из нового решения должна попадать в «Заявка в Китай», минуя дублирующие этапы сбора через старый бот-путь.

• Каталог наполняется из воронки «Заявка», стадия «Подбор» — не из «Продажи».
• Логика: клиент получил варианты, но не купил — машина «доступна рынку» → можно показать на сайте / в офлайн-app.
• Из «Продажи» тянуть нелогично — машина уже продана.
• Выборка: deal_id + набор заполненных полей + VIN.
• При продаже / предоплате — убрать из каталога, чтобы два клиента не купили одну машину.
• Парсинг внешних площадок — следующая стадия, после MVP.

• Клиенту отправляют до трёх вариантов; нужно зафиксировать, что именно предложили.
• Сейчас — скрин Excel-расчётки; в перспективе — автогенерация PDF/DOC (Python на сервере или робот Битрикс).
• Тяжёлые фото — ссылки на диск (дешёвое хранилище), не bulk в CRM; в карточке заявки — до 3 слотов ссылок на папки.
• Таймлайн Битрикс — комментарии + файлы; поиск по VIN через поиск CRM.
• Через месяц клиент может вернуться: «мне скидывали машину с пробегом 71334» — нужно поднять архив расчётки и переписки.
• Если звонок по телефону — без простого решения в переписке; архив в CRM критичен.

Открытые вопросы (зафиксировать в ТЗ)

• Сколько вариантов КП в архитектуре: 3 или больше?
• Mini App vs форма на сайте для Telegram — финальный UX.
• Синхронизация чата сайт ↔ Битрикс: обязательна или только для менеджера?
• Автоматизация таможенного калькулятора: ручной ввод vs полуавтомат.
• Где хранить медиа: Yandex Disk / S3 + ссылки в свойствах.
• Массовое клиентское APK vs только партнёры.

1. Игорь — обсуждение с партнёрами/коллегами: сайт, приложение, бюджет; принятие решения о старте.
2. Аron — схематичная архитектурная диаграмма (идеальный образ + webhook-таблица).
3. Совместно — формализованный UX: что видит клиент и что делает менеджер на каждом шаге.
4. Декомпозиция на мелкие этапы после согласования архитектуры — чтобы не переделывать при изменении числа вариантов КП.
5. Первый шаг реализации (если «добро»): воронка «Заявка в Китай» + обработка + расчёт «бесшовно»; каталоги и приложение — последующие этапы.