Addrea · предложение TO-BE · пошаговая схема · 20.09.2026
Тот же вид, что и разбор «как есть»: стадии идут сверху вниз, на каждой стрелке подписано, чем сделка двигается (авто — процесс, вручную — человек), а по клику на блок открываются детали. Три воронки, один сквозной поток, без копий.
👆 Нажми на любой блок — что происходит, что срабатывает, что двигает дальше.
вся продукция + продажа сервиса · тип продукта = поле сделки
исполнение проекта · дочерняя к продаже, данные из пресейла
продажа сервиса · дочерняя к продаже (апселл) или отдельная
Сквозной путь: продал → сделали → обслуживаем. Пресейл считает и подтверждает цены рядом с продажей; на выигрыше рождается исполнение и/или сервис; инциденты — конкретные работы под проектом или сервисной сделкой. Одна сделка — без копий в трёх воронках.
Никто не создаёт смарт вручную и не рассылает «дозаполните». Менеджер описывает потребность один раз, дальше — автоматика. Реализовано в тестовой воронке.
Поле-таблица: что и сколько нужно, назначение (улица/помещение). Точную модель знать не обязательно — её подберёт пресейл. Ставит «Нужен пресейл = Да».
Перевод сделки на «Пресейл (расчёт)» создаёт элемент «Пресейл» (PARENT = сделка), ответственный — ведущий инженер пресейла, ему уведомление в Битрикс и на почту. Дубли не плодятся.
Инженер выбирает отдел/направление (LED, звук, POSM, логистика, закупка…) — по каждому создаётся «Расчёт» с дедлайном; ответственного подставляет справочник, человека вручную выбирать не нужно.
Как устроено на самом деле — реализовано в тестовой воронке.
Точная раскладка реализованного (воронка «Тестовая (для Камиллы)»).
| Сущность | Что это | Стадии | Ключевые поля |
|---|---|---|---|
| Сделка · воронка C5 | основная продажа, одна на проект | Подготовка → Пресейл (расчёт) → КП клиенту → Подтверждение цены → Договор и оплата → Завершить сделку | «Запрос менеджера» (таблица потребности), «Нужен пресейл» (Да/Нет), адрес объекта, тип оборудования; «Товары» = согласованный состав |
| Смарт «Пресейл» | один на сделку, агрегатор расчётов (PARENT = сделка) | Новое → На расчёте → Расчёт завершён → Согласовано / Отклонено | Руководитель, Сумма расчёта, Плановая себестоимость, Согласованные позиции; «Товары» = агрегат всех расчётов |
| Смарт «Расчёт» | по одному на направление/отдел; привязан к пресейлу и сделке | Новое → На расчёте → Расчёт завершён → Согласовано / Отклонено | Направление, связь с пресейлом/сделкой, комментарий; «Товары» = позиции этого направления |
| Справочник отделов | HL-блок «отдел → ответственный», правится в админке без разработчика | — | Код направления, Отдел/направление, Ответственный (сотрудник), Сортировка, Активно |
Печатные формы не собирают руками из кусков.
Привязан к сделке (PARENT). Свои статусы вместо «одной стадии»:
ЧерновикСогласование (юрист/РОП)СформированНа подписании (клиент/мы)ПодписанПровалОба решают одно: зафиксировать факт оплаты, чтобы он двигал сделку. Аванс оплачен → условие Выигрыша; остаток контролируется дальше, в реализации.
Когда выбирать: быстрый старт без внешних систем; финучёт остаётся в Б24.
Когда выбирать: если деньги и учёт уже в 1С (скорее всего так и есть) — избегаем рассинхрона.
Рекомендация: если 1С — основной учёт, брать вариант 2; вариант 1 — как быстрый старт или когда 1С нет. Оба подают один и тот же триггер «аванс оплачен» в стадию «Договор и оплата» → Выигрыш.
Срез клиента: из 63 проектов у 5 расходы 0,00, у 3 явно занижены. Разобрал причины по реальным сделкам — все закрываются связкой «HL-реестр + данные из 1С + план/факт».
| Случай | Почему теряется сейчас | Как ловит новая модель |
|---|---|---|
| Склад без цены#10380, #8847 | оборудование ушло со склада, но себестоимость не привязана — РП видит спецификацию с количествами, без денег | HL берёт себестоимость позиции из номенклатуры 1С — спецификация всегда с ценами |
| Расход в 1С, не в сделке#10526 (Жуков) | логистика (Жуков) ведётся в 1С отдельно и в CRM не попадает | обмен 1С→HL по ID сделки/договора тянет ВСЕ расходы, включая логистику |
| Исполнитель не подал#10629 | расход появляется, только если монтажник сам подал на оплату — не подал → «поработал бесплатно», 0 | план из сметы/ставок (смарт «Расценки монтажников») ставится сразу; факт 0 виден как недоплата, а не как отсутствие расхода |
| Оплата есть, но не привязана#10612, #10423, #10539 | платёж монтажнику существует, но связь платёж↔сделка теряется — в сделку не выводится | обязательный DEAL_ID; платёж из 1С несёт ссылку на сделку; не сматчилось → буфер «Расходы без привязки» на разбор — ничего не пропадает |
| Штатный ФОТ#10278 (настройка) | внутренние работы штатных отделов никто не заводит как расход проекта | плановый ФОТ по ставке/часам ложится на проект автоматически |
Чтобы статус было видно без раскопок внутри процессов.
Собирает крон раз в день; открыл сделку — сразу видишь актуальную картину, не листая таймлайн и не заходя в смарты.
На этом настаивают коллеги: цикл сделки длинный (посчитать могут сегодня, а продать — через 5 месяцев), поэтому цены обязательно перепроверяются перед реализацией. Это стадии 2→3→4 на схеме выше.
Шесть переходов — этого достаточно, чтобы описать весь бизнес. Всё через PARENT, без копий.
Всё, что попадает в сервис, ведётся по-разному. Тип сервиса (поле на стадии «Новая») задаёт свой флоу.
| Тип | Что это | Откуда | Как ведётся | Деньги / срок |
|---|---|---|---|---|
| Гарантия | бесплатное обязательство после сдачи проекта | Реализация (сдача, «Гарантия до») | есть всегда, но не всегда обращаются; инцидент при обращении | без суммы, срок = гарант. период |
| Абонентка | платное регулярное обслуживание | Продажи (апселл) или Сервис standalone | по действиям как инциденты — регулярные выезды/ТО + автопродление | сумма + срок, регулярная |
| Лицензия | платная лицензия/подписка (ПО, контент-платформа) | Продажи (апселл) | минимум действий — просто продлить и получить деньги | сумма + срок, регулярная |
| Контент | изготовление/обновление контента для экранов | Продажи или Сервис | задачи дизайна/креатива под конкретный экран | по проекту |
| Платный инцидент | разовое платное обращение вне гарантии | кнопка «Платный инцидент» | создаёт сделку Продажи → Сервис; работа — через инцидент | разовая сумма |
| Настройка | техработа: конфигурация, замеры, софт | часть Реализации и любых выездов сервиса | инцидент типа «Настройка», дочерний — без отдельной продажи | внутри проекта/сервиса |
Клик — что делает.
Каждый пункт закрывает конкретную боль из разбора «как есть».
Живёт на боевом портале в тестовой воронке «Тестовая (для Камиллы)».
Статус (обновлено 14.10.2026): блок пресейла реализован в тестовой воронке «Тестовая (для Камиллы)» — авто-создание смарта «Пресейл», «Запрос менеджера», «Запросить расчёт» по отделам со справочником «отдел → ответственный» (HL-блок, правится в админке), агрегация расчётов, согласованные позиции → «Товары» сделки, КП в PDF + Excel, стадия «Подтверждение цены», авто-конвертация лида в эту воронку. Блоки Реализация / Сервис / смарт-договор / оплата — план по этой же схеме, внедряем поэтапно. Пара к этой странице — разбор AS-IS: as-is.html.
Менеджер вручную создаёт сделку: клиент, контакт, тип продукта (проект / ПОСМ / панели / сервис) — это поле сделки, а не отдельная воронка.
Квалифицированные лиды автоматически конвертируются в эту воронку — не нужно выбирать её вручную.
Вручную: менеджер заполняет «Запрос менеджера», ставит «Нужен пресейл = Да» и переводит сделку на «Пресейл (расчёт)».
К сделке привязывается смарт «Пресейл» (один на сделку, агрегатор). Инженер кнопкой «Запросить расчёт» по каждому отделу/направлению (LED, звук, POSM, дизайн, МК, монтаж, логистика, закупка…) заводит отдельный смарт «Расчёт»; ответственного подставляет справочник «отдел → сотрудник». Специалисты кладут товары в свои расчёты.
Авто: товары расчётов собираются в пресейл, суммы пересчитываются; когда посчитано — сделка возвращается в продажи (на «КП клиенту»). Видно, какое направление ещё считается и кто ответственный.
Расчёт пресейла собран — менеджер продаёт клиенту.
Авто: КП генерируется из согласованных позиций пресейла (спецификация, позиции, цены) по шаблону — PDF (клиенту) и Excel (для переноса данных в свои таблицы). Менеджер только проверяет и отправляет; при изменении расчёта КП можно перегенерировать.
Вручную: договорились по цене → на подтверждение цен (пресейл перепроверяет актуальность).
Цикл сделки длинный: посчитать могли сегодня, а продать — через месяцы. Перед реализацией пресейл подтверждает, что цены поставщиков/работ не изменились.
Робот стадии ставит пресейл-группе согласование «Цены актуальны?» (дежурный/очередь) с дедлайном 1–2 дня и авто-эскалацией при просрочке — blocking. В смарте «Пресейл» переоткрываются только волатильные направления (закупка/логистика/МК) со статусом «на перепроверке» — не весь пресейл заново. Инженер сверяет с поставщиками / LED-конфигуратором и жмёт «Актуальны» или вносит новые цифры.
В отличие от «как есть» — один короткий blocking-шаг с дедлайном и эскалацией, а не бесконечный WHILE; согласующий — группа, а не тест-юзер.
Оформляем договор и получаем оплату. Договор ведёт отдельный смарт «Договор» со статусами и автогенерацией (см. карточку смарта).
Либо смарт «Счета» (штатный Б24): выставлен → частично оплачен → оплачен. Либо обмен с 1С: факт оплаты приходит из 1С. Оба подают сигнал «аванс оплачен» (см. раздел «Оплата — два варианта»).
Авто: договор «Подписан» + получен аванс → сделка сама уходит в «Выигрыш». Остаток оплаты контролируется дальше, в реализации.
Отдельный смарт-процесс «Договор», привязанный к сделке (PARENT). Вынесен из стадии, чтобы видеть, где договор реально застрял, и вести его отдельно от продажной сделки.
Черновик → Согласование (юрист/РОП) → Сформирован → На подписании (клиент/мы) → Подписан → Провал.
На статусе «Сформирован» договор собирается из полей сделки и приложений по шаблону — не руками. Подписан → сигнал в сделку, стадия «Договор и оплата» может закрываться.
Смарт-процесс «Счета» (штатный Б24), привязан к сделке (PARENT). Фиксирует факт оплаты, чтобы он двигал сделку.
Выставлен → Частично оплачен → Оплачен. Аванс и остаток — отдельными счетами.
Счёт выставляется из сделки в один клик — печатная форма и ссылка на оплату клиенту. Оплата фиксируется вручную (менеджер/бухгалтер) или авто — по эквайрингу/выписке, если подключено. Аванс оплачен — это условие Выигрыша; остаток контролируется дальше, в реализации. Альтернатива — факт оплаты из обмена с 1С (см. «Оплата — два варианта»).
Не по факту 100% оплаты. Триггер — договор в статусе «Подписан» + получен аванс (по условиям договора). Как только оба условия есть, робот сам переводит сделку в Выигрыш. Остаток оплаты контролируется уже в реализации и выигрыш не блокирует.
Робот автоматически создаёт дочерние сделки (PARENT = эта продажа), без копирования оригинала:
Пишет взаимные ссылки, фиксирует сумму/себестоимость. Проигрыш — альтернативный финал: дочерних сделок нет.
Смарт-процесс «Расчёт» — по одному на каждое выбранное направление/отдел, привязан к пресейлу и сделке. Создаётся кнопкой «Запросить расчёт».
Берётся из справочника «отдел → сотрудник» (HL-блок, правится в админке) — человека вручную не выбирают. Поменял сотрудника в справочнике — новые расчёты идут на него (устойчиво к увольнениям).
Специалист кладёт позиции (товары с ценой/количеством) в свой расчёт. Товары всех расчётов автоматически собираются в «Пресейл», сумма и себестоимость пересчитываются; отклонённые расчёты не учитываются.
Новое → На расчёте → Расчёт завершён → Согласовано / Отклонено. «Согласовано» ставится на стадии сделки «Подтверждение цены».
Заменяет монолитный БП Presale на два связанных смарта: «Пресейл» (один на сделку, агрегатор) и «Расчёт» (по одному на направление/отдел). Элемент «Расчёт» = согласование одного направления с ответственным, со своими стадиями и дедлайном.
LED, звук, POSM, дизайн, конструктор МК, ВКС, настройка, МК, логистика, закупка. Ответственный по направлению берётся из справочника «отдел → сотрудник» (HL-блок, правится в админке) — вручную человека не выбирают. Расчёт LED — в собственном LED-конфигураторе (калькулятор на базе Клода).
Специалисты кладут товары в свои «Расчёты»; они автоматически собираются в товары «Пресейла», сумма и себестоимость пересчитываются. Отмеченные «Согласованные позиции» переносятся в «Товары» сделки — из них собирается КП.
Считает и собирает сделку (стадия 2), затем подтверждает цены (стадия 4). Прозрачно: видно, где застряло и кого дёрнуть.
Пресейл подтвердил — цены не изменились. Сделка идёт в Договор и оплату, дальше в реализацию с теми же цифрами.
С момента расчёта что-то подорожало. Сделка возвращается на «КП клиенту» — пересчитываем и заново согласуем цену с клиентом. Так мы не уходим в минус на длинном цикле.
Дочерняя сделка в воронке Реализация, создаётся на выигрыше, если продан проект/ПОСМ. PARENT = сделка продаж, переносятся все поля проекта.
Это дочерняя сделка, а не копия. Оригинал продажи один, история едина.
Дополнительный путь в сервис (не основной — основной это гарантия из реализации). Дочерняя сделка в воронке Сервис, создаётся на выигрыше, только если в продаже был апселл: абонентка или лицензия. PARENT = сделка продаж.
Абонентка (регулярное обслуживание, как инциденты) и лицензия (минимум действий — продлить и получить деньги) ведутся по-разному — см. таблицу типов сервиса.
Финальная неуспешная стадия. Дочерние сделки не создаются, в реализацию и сервис ничего не уходит.
Стартует исполнение проекта. Назначается РП, подтягиваются данные из пресейла (те же характеристики и цифры).
Ведутся во вкладке сделки (HL-блок, данные из 1С) — не смарт-процесс. Согласование оплат и канбан статусов — кастомно внутри вкладки (см. карточку «Расходы»).
Вручную (после стартовых задач РП) — на «Закупку / Логистику / МК».
Расходы по проекту (оборудование, монтаж, МК, логистика, лицензии) — не смарт-процесс. Хранятся в HL-блоке (плоская таблица), а менеджер видит их в отдельной вкладке карточки сделки (приложение).
Наполняются из 1С (обмен по ID сделки/договора). 1С — источник правды по деньгам; HL в Б24 — быстрый локальный кэш для показа и фильтрации.
И согласование оплаты, и канбан статусов делаются кастомно внутри вкладки (приложение над HL): доски «ждёт / согласовано / оплачено», кнопки согласования — без тяжёлого смарта на каждую строку.
Каждая строка = план (смета/ставка/номенклатура 1С) + факт (оплата из 1С). «Пусто ≠ ноль»: если факт не пришёл, видно «план N, факт 0» и почему, а не сделка на 0,00. Платежи 1С без привязки падают в «Расходы без привязки» на разбор. См. раздел «Расходы: почему теряются деньги».
Смарт «Расходы» уже раздулся до 13 тыс.+ элементов и рос бы вечно (проекты × статьи). HL + вкладка снимают нагрузку: реестр быстрый, бэкап лёгкий, единый источник — 1С. Итоги (расходы, маржа) можно дублировать в 2–3 поля сделки для отчётов по воронке.
Закупка оборудования, логистика, металлоконструкции. Работают те же отделы, что считали пресейл, — без повторного просчёта с нуля.
Каждый трек — это блокирующая задача на ответственный отдел (закупки / логистика / МК) со сроком. «Статус трека» = статус задачи: не начато → в работе → готово. Задачи видны на карточке сделки и в ежедневном досье — сразу понятно, что готово и кого дёрнуть.
Для «тяжёлых» треков (много позиций закупки или МК) трек можно вести дочерним смарт-процессом вместо одной задачи — тогда статус = стадия этого смарта.
Авто: когда все 3 задачи закрыты — стадия сама уходит на «Настройку». Просрочена задача → эскалация ответственному.
Блокирующая задача на отдел закупок со сроком. Статус = статус задачи: не начато → в работе → готово. Пока не «готово» — стадия не уходит дальше. Если позиций много — можно вести дочерним смартом.
Блокирующая задача на логистику со сроком. Статус = статус задачи: не начато → в работе → готово. Видна на карточке сделки и в ежедневном досье.
Блокирующая задача на отдел МК со сроком. Статус: не начато → в работе → готово. Включается, только если в проекте есть металлоконструкции; иначе трек пропускается.
Предмонтажная подготовка комплекта: команда настройки конфигурирует оборудование, шьёт софт/прошивки, заливает контент, делает замеры и тест-прогон — чтобы на объекте всё сразу заработало.
Работа идёт через задачи, а не через инцидент. РП:
Инцидент «Настройка» заводят только для отдельного выезда — донастроить уже на объекте или по обращению сервиса. В рамках проекта настройка — обычная задача стадии.
Вручную: РП принял настройку → «Монтаж».
Монтаж на объекте: доставка, установка конструкций/экранов, подключение, пусконаладка, сдача бригадой.
Тоже через задачи, а не инциденты. РП:
Инциденты — это сервис/гарантия после сдачи, к монтажу отношения не имеют.
Вручную: монтаж принят (акт/фото) → «Сдача».
Сдаём проект клиенту. На этой стадии проставляется «Гарантия до».
Авто: открывается гарантийное обязательство — проект становится родителем гарантийных инцидентов.
Проект сдан и закрыт успешно.
Каждый сданный проект передаётся в сервис на гарантию — создаётся сервисная сделка типа «Гарантия» (PARENT = проект). Со слов команды: «из проектов продаж и ПОСМ — всё попадает на гарантию».
Гарантийные обращения потом ведутся инцидентами уже под этой сервисной сделкой (Сервис → Инциденты).
Дочерняя сделка в воронке Сервис типа «Гарантия» — основной способ попадания в сервис. Открывается на сдаче каждого реализованного проекта (продажи + ПОСМ): «всё попадает на гарантию».
Денег нет, срок = гарантийный период («Гарантия до»). Есть всегда, но обращаются не всегда — при обращении заводится инцидент (выезд/ремонт), дочерний к этой сервисной сделке.
Гарантийные инциденты — конкретные работы по обращению клиента в гарантийный период (выезд, ремонт). Дочерние к проекту (Реализации).
Инцидент типа «Настройка» — техработа на этапе реализации (или на любом сервисном выезде). Дочерний, без отдельной продажи.
Заводится сервисная сделка. Ключевое — тип: абонентка / лицензия / гарантия / контент / платный ремонт. Тип задаёт весь дальнейший флоу (см. таблицу типов).
Апселл из продажи (PARENT = продажа), с гарантии из реализации, кнопкой «Платный инцидент» или заведена вручную.
Сервис активен. Это платное обязательство с суммой и сроком (кроме гарантии), а не просто «карточка клиента».
Вручную — начинается обслуживание.
Идёт обслуживание. Вся конкретная работа — через дочерний смарт «Инциденты» (выезды, плановое ТО, ремонт, настройка).
Авто: по истечении срока абонентки/лицензии регулярная сделка открывает следующий период.
Смарт-процесс «Инциденты» — единица работы по сервису: выезд, ремонт, плановое ТО, настройка. Не воронка продаж, а конкретная работа с исполнителем и сроком.
Один сервис/проект порождает много работ — держим их дочерними, чтобы видеть всю историю обслуживания объекта в одном месте и не плодить сделки.
Абонентка/лицензия по истечении срока продлеваются регулярной сделкой (штатный механизм коробки) — открывается следующий период. Разовый сервис — закрывается.
Справа в карточке сделки Сервис или Реализация. Для обращения вне гарантии.
Справа сверху в карточке Реализация или Сервис.
Создаёт новую сделку в воронке Продажи с привязкой к текущей — для любой доп. продажи или платного сервиса, возникших в ходе исполнения. Дальше — обычный цикл продаж (пресейл, КП, выигрыш).