Антон Дегтярёвбитрикс24 для типографии: заказы, макеты, тираж
На одном из внедрений для типографии в Подмосковье выяснилось, что менеджеры теряют версию макета в 3 заявках из 10 — файл присылают в вотсапе, правки обсуждают в почте, а окончательный вариант печатник ищет по переписке за час до сдачи в цех. CRM в этой отрасли решает не «продажи», а именно это — где лежит актуальный файл и кто его утвердил.
почему обычная воронка продаж тут не работает
Стандартная воронка Битрикс24 из коробки — «первичный контакт → квалификация → предложение → сделка» — заточена под продажу услуги, а не под производство изделия с версиями файла и физическим тиражом на выходе. В типографии сделка не заканчивается, когда клиент оплатил счёт: после оплаты начинается вторая, более рискованная часть — макет, корректура, печать, постпечатная обработка, упаковка, отгрузка. Если воронку не переделать, вся эта часть живёт в головах печатников и в переписке, а не в CRM.
На аудите я обычно вижу один и тот же симптом: менеджер закрывает сделку как «оплачено» в момент прихода денег, а дальше теряет её из виду — она выпадает из его отчёта, хотя по факту работа над заказом ещё не начиналась. Через две недели клиент звонит и спрашивает, где тираж, а менеджер поднимает историю переписки заново.
Решение — не выдумывать сложную схему, а развести стадии по трём смысловым блокам: продажа (до оплаты), производство (макет → печать → постобработка), логистика (упаковка → отгрузка → закрытие). Это уже другая логика воронки, и дальше расписываю, как она выглядит в стадиях CRM.
как я развожу стадии сделки под цикл заказа
Рабочая воронка, которую я ставлю чаще всего для полиграфии: «заявка получена» → «расчёт тиража и КП» → «оплата получена» → «макет на согласовании» → «макет утверждён, в печать» → «печать» → «постобработка» (ламинация, биговка, переплёт — если есть) → «готово к отгрузке» → «отгружено/закрыто». Девять стадий вместо стандартных четырёх-пяти — это осознанное решение, а не усложнение ради усложнения.
Причина в том, что каждая из этих стадий имеет свой ответственный отдел: менеджер ведёт первые три, дизайнер или технолог — согласование макета, печатник — печать и постобработку, логист — отгрузку. Когда стадия одна на всех «в производстве», непонятно, кто именно сейчас держит мяч и на ком заказ подвис.
Отдельно ставлю правило автоматизации: переход на стадию «печать» блокируется, пока в карточке нет поля «макет утверждён = да» с датой и именем утвердившего. Это простое ограничение убирает частую ошибку — печать без финального согласования, из-за которой потом переделывают тираж за счёт типографии.
где хранить макет, чтобы его не потеряли
Файл макета я всегда привязываю к самой карточке сделки — в поле «диск», а не прикрепляю к переписке в открытой линии или к комментарию в чате. Разница принципиальная: комментарий и переписка со временем уходят вниз по ленте, а поле «диск» в карточке видно сразу при открытии сделки, независимо от того, сколько сообщений было после.
На каждую версию макета — отдельная загрузка файла с пометкой в названии: «макет_v1_на_согласовании», «макет_v2_правки_логотипа», «макет_финал_утверждён». Это выглядит примитивно, но именно так печатник за 5 секунд видит, какой файл финальный, не переспрашивая менеджера в мессенджере.
Второе правило — согласование клиентом фиксируется не устным «да, отлично», а конкретным действием в CRM: клиент подтверждает в письме или в чате открытой линии, менеджер копирует текст подтверждения в комментарий к сделке с меткой даты. При спорной ситуации («вы напечатали не то, что мы утвердили») это единственное, что реально защищает типографию — переписка внутри портала, а не память менеджера.
расчёт тиража и стоимости — где это должно жить
Частая ошибка — считать стоимость тиража в отдельном экселе, который менеджер держит на рабочем столе, а в CRM просто вписывает итоговую сумму. Проблема в том, что при пересчёте (клиент попросил другой тираж или бумагу) расчёт снова уходит из CRM, и связь между конечной ценой и параметрами заказа теряется — через месяц никто не восстановит, из чего складывалась сумма.
Я привязываю к сделке смарт-процесс «расчёт заказа» с полями: тираж, формат, тип бумаги, цветность, постобработка, срочность. По этим полям строится формула итоговой цены прямо в CRM — через товарные позиции с настроенными ценовыми правилами или через кастомное поле с формулой, в зависимости от того, насколько сложное у типографии ценообразование. Похожий принцип я разбирал в статье про автоматизацию закупок через смарт-процесс на 6 стадий — там та же логика: превратить хаотичный расчёт в структурированные поля, по которым потом можно строить отчёты.
Плюс такого подхода — при повторном заказе того же клиента менеджер не считает с нуля, а копирует смарт-процесс с прошлым набором параметров и меняет только тираж или срок. Это сокращает время на КП с 20-30 минут до 5.
срочные заказы и приоритет в очереди печати
В полиграфии почти всегда есть срочные заказы, которые нужно поставить в очередь печати впереди плановых — и без явного правила это превращается в конфликт между менеджерами за место в очереди цеха. Я ставлю поле «срочность» с тремя значениями: план (5-7 дней), ускоренный (2-3 дня, наценка), день в день (наценка выше, ограниченное количество слотов в сутки).
В карточке производственного отдела делаю отдельное представление CRM (список), отсортированное не по дате создания сделки, а по полю «срок сдачи» с фильтром по срочности — печатник открывает не общую ленту сделок, а именно очередь на сегодня и завтра. На моих проектах это снимает главный источник трений между продажами и цехом: раньше решение «что печатать первым» принималось на словах и часто менялось задним числом, теперь оно видно в системе и одинаково для всех.
Ограничение по количеству слотов «день в день» в сутки я тоже завожу как поле в CRM с автоматическим уведомлением менеджеру, если лимит на сегодня исчерпан — это защищает цех от переобещанных менеджером сроков, которые физически невозможно выполнить.
типовой кейс — заказ рекламных буклетов с правками
Опишу на реальном сценарии, часто повторяющемся на моих внедрениях. Клиент оставляет заявку на буклеты тиражом 5000 экземпляров. Менеджер переводит сделку на «расчёт тиража и КП», заполняет смарт-процесс параметрами (мелованная бумага 130 г/м², цветность 4+4, фальцовка в три сложения), система считает итоговую сумму — 34 500 рублей за тираж плюс 2 500 за срочность.
Клиент оплачивает, сделка автоматически переходит на «макет на согласовании», дизайнер получает уведомление, загружает макет в поле «диск» карточки. Клиент просит поправить логотип — вторая версия макета грузится отдельным файлом, старая не удаляется, а остаётся в истории. После утверждения менеджер ставит галочку «макет утверждён», только после этого сделка технически может перейти на стадию «печать» — раньше система просто не даст сменить статус.
Печатник видит заказ в своей очереди по сроку сдачи, после печати и фальцовки меняет стадию на «готово к отгрузке», логист формирует накладную и закрывает сделку. Весь путь заказа — от заявки до отгрузки — виден в одной карточке без единого звонка «а что там с нашим тиражом».
связка с производством, если типография не только печатает
Если типография кроме печати занимается более сложным производством — например, изготовлением упаковки с высечкой или переплётом книг в твёрдой обложке — логика стадий усложняется, но принцип остаётся тем же: каждый физический этап производства должен быть отдельной стадией сделки с ответственным лицом, а не строкой в общем поле «статус». Похожие принципы разведения этапов производственного цикла в CRM я подробно разбирал в статье про Битрикс24 для небольшого производства — там акцент на выпуск физического изделия, а не только на печать, но методика построения воронки почти идентична.
Отдельный момент для многоэтапного производства — учёт брака и пересъёма материала. Я завожу поле «причина брака» с выпадающим списком (не тот оттенок, смещение печати, дефект бумаги) прямо в карточке сделки, чтобы через квартал можно было построить отчёт: на каком этапе чаще всего теряется тираж и во сколько это обходится компании в пересъёме материала.
когда смарт-процессы избыточны, а обычной сделки хватит
Не для каждой типографии нужна вся описанная выше сложность. Если типография делает только визитки и простую полиграфию малыми тиражами без сложной постобработки, девять стадий и отдельный смарт-процесс расчёта — избыточная бюрократия, которая замедлит менеджера, а не ускорит. В такой ситуации хватит пяти стадий сделки и пары дополнительных полей (тираж, срок сдачи, ссылка на макет), без отдельного смарт-процесса.
Разницу между полноценным смарт-процессом и обычной сделкой с доп.полями я подробно разбирал в статье про смарт-процессы в Битрикс24 — что это и когда они нужны. Правило простое: если у типографии больше 3-4 производственных этапов с разными ответственными и регулярным браком на конкретных стадиях — смарт-процесс окупается отчётностью. Если этапов два-три и команда небольшая — обычной воронки со сделками достаточно, и я в таких случаях сам отговариваю клиента от лишней сложности при внедрении.