Менеджер берёт файл прошлой сделки, меняет реквизиты, забывает поменять срок и подставляет старый банковский счёт. Бухгалтерия возвращает договор. Клиент ждёт пятый день.
Параллельно скидку согласовывают письмом «Иван Петрович, добро?». Иван Петрович в отпуске, автоответчик, потом «я не видел». В длинном цикле именно из этого складываются те три недели, которые принято называть спецификой рынка.
Оба сценария закрываются одним способом: документ собирается из данных, а не из прошлого файла, а регламент выполняется системой, а не памятью сотрудников. Разберём, как это устроено — с казахстанской спецификой, которую в зарубежных CRM приходится доделывать руками.
Главное за минуту
Реквизиты в карточке
Не в тексте шаблона: сменили банк один раз — и все новые договоры и счета верны.
Спецификация сама
Строки таблицы товаров размножаются по составу заказа, пустое поле исчезает из документа.
Параллельные визы
Юрист и финансы согласуют одновременно — цикл короче на длину самой медленной цепочки.
Снимок на момент шага
Видно, какой была сделка в момент согласования, — это закрывает спор «я согласовывал другое».
Почему реквизиты нельзя держать в тексте шаблона
Главная ошибка, из которой растут все остальные: шаблон договора хранит реквизиты контрагента внутри себя. Тогда каждый новый договор — это копия предыдущего с ручной правкой, и ошибка живёт до первой проверки.
Правильно — реквизиты живут в карточке компании-контрагента, а в шаблоне стоят подстановки. Для казахстанского рынка карточка должна знать: рабочее и юридическое название, БИН/ИИН одним полем, форму собственности (ТОО, АО, ИП, ГУ), юридический и фактический адрес, банк, БИК, ИИК, Кбе, отрасль и ответственного.
Сменили банк — исправили в одном месте, и все последующие документы верны. Подстановок реквизитов тринадцать, включая сводный блок «все реквизиты сразу» — тот, который обычно набирают руками в конце договора.
И деталь, которая спасает от неловкости: незаполненное поле исчезает из документа, а не остаётся фигурной скобкой в подписанном договоре. Компанию система находит сама — по привязке к сделке или заказу, иначе по компании контактного лица.
Спецификация на сорок позиций собирается сама
Вторая по трудоёмкости часть коммерческого предложения — товарная таблица. Её обычно переносят вручную и в ней же чаще всего ошибаются.
Что должно работать без участия человека:
- шаблон в формате .docx — тот, который уже согласован с вашим юристом, а не «наш красивый бланк»;
- свыше 80 встроенных подстановок: по документу, сделке, заказу, клиенту и реквизитам компании — плюс все ваши дополнительные поля;
- позиции разворачиваются таблицей по составу заказа, 15 полей в строке: наименование, артикул, бренд, количество, единица измерения с коэффициентом, цена, сумма;
- автонумерация со своим счётчиком у каждого шаблона — сквозная нумерация договоров без журнала в Excel;
- шаблон ограничивается воронкой: менеджер оптового направления не выставит розничный договор.
Отдельно про счёт. Казахстанская форма — это не «инвойс с переведёнными подписями»: БИН, ИИК, БИК, Кбе, код назначения платежа, НДС в цене или сверху, сумма прописью в тенге, факсимиле подписи и печати. Покупатель подставляется из карточки компании, поставщик — из реквизитов вашей организации.
Состав предложения тоже можно не набирать руками: система читает переписку, звонки и письма по сделке за выбранный период, извлекает названные позиции и предлагает подходящие из каталога. Модель при этом только выбирает из реальных кандидатов — идентификатор принимается, только если он был в списке найденного, поэтому «придумать» товар она не может.
Согласование: параллельно, со сроком и заместителем
Теперь вторая половина проблемы. Согласование в почте не работает по трём причинам: нет срока, нет замены на отпуск и нет следа.
Разберём то, что даёт основной эффект.
Исполнитель — роль, а не фамилия
Согласующий задаётся как «инициатор», «руководитель отдела инициатора», «вся цепочка вышестоящих по дереву отделов», «ответственный по документу». Кадровая перестановка не ломает схему — а это главная причина, по которой самодельные регламенты умирают через полгода.
Параллельные ветки и кворум
Юрист, финансы и склад согласуют одновременно, а не гуськом. Слияние — «дождаться всех» или «первая ветка». Кворум в трёх режимах: согласуют все, все по очереди, N из списка. Уже одно это сокращает цикл согласования на длину самой медленной цепочки.
Дедлайн и ветка таймаута
У задачи согласования есть срок. Просроченные проверяются каждую минуту: сначала напоминание, потом процесс уходит по отдельной ветке — например, на руководителя. Согласование не «висит», оно движется. Таймеры считают время в выбранном часовом поясе, включая Asia/Almaty.
Отпуск
Замещение задаётся периодом, областью действия (все задачи / только согласования / только поручения) и режимом — заменить согласующего или добавить заместителя. Процесс не зависает, пока директор на море.
Снимок на момент шага
История переходов хранит снимок объекта на каждом шаге. На разборе видно, как выглядела сделка в момент согласования — сумма, этап и ответственный того дня, а не сегодняшние. Это закрывает самый неприятный тип спора: «я согласовывал другие условия».
Две защиты, которые видно только на боевой нагрузке
Мелочи, из-за которых процессные движки обычно и ломаются.
Защита от дублей. Ключ идемпотентности на триггере и режим «единственный активный экземпляр» с проверкой под блокировкой: повторная доставка события не заведёт второе согласование на ту же сделку. Без этого при любом сбое интеграции согласующие получают по три одинаковые задачи.
Правки на ходу. Запущенный процесс исполняет снимок маршрута, сделанный при старте. Значит, регламент можно улучшать в рабочее время, не обрушивая сотню идущих согласований — и не ждать выходных, чтобы поменять одно условие.
Плюс контроль: экран запущенных экземпляров с фильтрами, дашборд зависших процессов и «горячих точек» отказов, доля успеха и среднее время прохождения в аналитике.
«Кто поменял сумму сделки» — вопрос, который перестаёт быть расследованием
В длинной сделке, которую ведут несколько человек, а часть действий делают боты и автоматизации, это не риторический вопрос.
Журнал изменений фиксирует пользователя, тип сущности, конкретную запись, действие, дату, IP и пару «было → стало» по каждому изменённому полю. И отдельно — источник действия: веб-кабинет, мобильное приложение, публичный API, бот, бизнес-процесс или фоновое задание.
Последнее важнее, чем кажется: обычный лог CRM не отличает бота от человека. Когда часть работы делают автоматизации, без этого разделения разбор инцидента невозможен.
Срок хранения компания задаёт сама — от 7 до 3650 дней. Чувствительные значения маскируются. Доступ к журналу — отдельное право.
Рядом стоит вопрос, который волнует владельца ещё сильнее: «менеджер уволится и унесёт базу». Право смотреть список клиентов и право скачать этот список файлом — это разные галочки. Всего 63 флага прав по 47 разделам, «Выгрузка данных» и «Загрузка данных» вынесены отдельно, и каждая выгрузка попадает в журнал с автором и объёмом.
Документ должен собираться из данных, а регламент — выполняться системой. Всё остальное — копирование прошлого файла с ошибкой внутри.
Границы: что честно проговорить до внедрения
- PDF-версия документа собирается внешним конвертером на сервере. Без него документ формируется, но PDF недоступен — это отдельный пункт чек-листа внедрения.
- Часть реквизитов счёта — Кбе, код назначения платежа, ставка НДС, факсимиле, формат номера — задаётся на уровне установки, а не в карточке каждой компании. Перед первым счётом мы их сверяем вместе с вами, как и валюту с часовым поясом.
- Модуль «Бизнес-процессы» включается тумблером в настройках. Конструктор и работа с согласованиями живут в веб-интерфейсе: в мобильном приложении этого раздела нет, хотя карточка сделки и печать документов там есть.
- Права групп безопасности ограничивают сотрудников с ролью «Оператор», которым назначена группа. Владельца, администратора и локального администратора они не проверяют — это уровень доверия, задаваемый ролью.
- При переезде с amoCRM и Битрикс24 переносятся компании, контакты, сделки, задачи, примечания, история смены стадий и файлы. Произвольные дополнительные поля источника не переносятся: из них вытаскиваются телефоны, почты, сайт и адрес.
- AI-шаг внутри процесса работает через одного провайдера моделей, а его режим ответа по базе знаний дополнительно требует настроенного поискового индекса.
Переезд при этом идемпотентен: пробный прогон на выходных и финальный в день переключения не создают дублей. И перенос не поднимает лавину автоматизаций — пять тысяч перенесённых сделок не запустят пять тысяч процессов и не завалят менеджеров уведомлениями.
Чек-лист: что подготовить к первому созвону
- Ваш действующий шаблон договора в .docx — тот, который согласован с юристом.
- Образец счёта, который принимает ваш банк.
- Список полей, которых не хватает в стандартной карточке сделки.
- Порог суммы, выше которого сделка идёт на согласование.
- Кто согласует — по должностям, а не по фамилиям.
- Какие визы идут параллельно, а какие обязательно по очереди.
- Что должно происходить, если согласующий не ответил в срок.
- Кому нельзя выгружать клиентскую базу файлом.
Связанные материалы
- Согласования и договоры: автоматизация маршрутов, ролей и дедлайнов
- BPM и workflow в CRM: как описать и автоматизировать процесс
- Обмен CRM с 1С: протокол, дельта и операционная корзина
- Интеграции и автоматизация процессов
Пришлите свой шаблон — напечатаем документ из тестовой сделки
Вы отдаёте действующий .docx, мы расставляем подстановки и показываем готовый договор со спецификацией и счёт с вашими реквизитами. Дальше собираем ваш регламент согласования в конструкторе. Триал — 14 дней, до 5 сотрудников.