Подписант договора в CRM: контакт, должность и полномочие

Менеджер ведёт переписку с одним человеком, а договор подписывает другой, и в CRM это часто не отражено. Нужно развести роли и проверять полномочие по документу, а не по памяти.

Подписант — лицо, указанное в конкретном документе как подписывающее. В CRM его полномочие проверяют по применимому основанию: уставу, доверенности или приказу. Сведения ФНС помогают сверить организацию и руководителя, но не доказывают частное полномочие. Проверку документа и границ выполняет уполномоченный сотрудник, а CRM фиксирует основание, дату и версию договора.

В условной ситуации менеджер полдня согласовывал сделку с Иваном Петровым: тот отвечал на письма, спорил о сроках, просил скидку. Договор ушёл на подпись, а вернулся с подписью Сергея Петрова, финансового директора, о котором в переписке не было ни слова. По внешним признакам компания та же, однако сходство оформления ещё не подтверждает основание подписи. Но в CRM контактом записан Иван, и никто не может быстро ответить, кто именно и на каком основании обязал контрагента.

Подписант — это не «контактное лицо» и не «человек, который ведёт переписку». Это лицо, указанное как подписывающее конкретный документ; применимость его полномочий проверяет ответственный сотрудник по соответствующим основаниям, дате и области действия. CRM здесь полезна не тем, что «хранит контакты», а тем, что разводит четыре разные сущности: участник переговоров, должностное лицо, подписант и основание полномочия. Пока они слиты в одно поле «контакт», любая сделка держится на памяти менеджера.

Переговорщик, представитель и подписант — три разные роли в сделке

В обычной карточке контрагента есть телефон, почта и имя. Этого достаточно, чтобы позвонить, и недостаточно, чтобы понять, кто вправе закрыть сделку. Менеджер по закупкам обсуждает условия, юрист правит редакцию, генеральный директор ставит подпись — и это три разных человека с разными границами ответственности. Если CRM показывает одного «контакта», она скрывает, что решение принимает не тот, с кем идёт разговор.

Практический вывод — в карточке сделки должны сосуществовать роли, а не одно имя. У роли «переговорщик» значимо, насколько человек влияет на решение. У роли «подписант» значимо применимое основание полномочия. Возможные материалы для проверки определяет уполномоченный сотрудник: само наличие устава, приказа или другого файла ещё не доказывает достаточность основания для конкретного договора. У роли «представитель по доверенности» значимо, что доверенность имеет срок, объём и отсылку к конкретным действиям. Смешение ролей приводит к типичной ошибке: менеджер отправляет договор «контакту», а тот не имеет права подписи, и цикл согласования начинается заново.

Если участники сделки и действия агентов должны храниться в одном процессе, посмотрите возможности агентской CRM «Цифра». По ссылке доступны описание продукта и формат обсуждения задачи. Маршрут проверки подписанта и связи с документами согласуют отдельно; CRM не заменяет решение уполномоченного проверяющего.

Что именно проверяет ФНС, а что остаётся за пределами реестра

Сервис ФНС со сведениями о юридических лицах даёт опубликованные данные: наименование, адрес, руководителя, виды деятельности, статус записи. Это полезная отправная точка — сверить, что компания существует, а заявленный директор совпадает с тем, кто указан в документах. Но реестр не доказывает, что конкретный Иванов уполномочен подписать именно этот договор с именно этой суммой. Он показывает руководителя как лицо в ЕГРЮЛ, а не объём его полномочий по внутренним документам и не наличие доверенности у третьего лица.

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

Карточка полномочия: рабочий объект вместо заметки «согласовано»

Свободная заметка «директор ок» живёт до первого спора. Нужен отдельный объект или строго определённый набор полей, привязанный к сделке и к подписанту. Тогда сотрудник видит не мнение коллеги, а проверяемое основание. Ниже — форма, которую стоит обсудить при настройке; это проектные требования, а не описание готовых полей конкретного продукта.

Такая форма отвечает на вопрос «почему мы считаем, что этот человек вправе подписать» без переслушивания звонков. Она же обнажает слабое место: если поле «основание» пустое, сделка держится на предположении.

Смена подписанта посреди сделки

Условный эпизод. Компания три недели согласовывала поставку оборудования, договор ушёл на подпись генеральному директору. За день до возврата документов менеджер получает письмо: «Генеральный в отпуске, подписывать будет заместитель по доверенности». В CRM контакт прежний, статус сделки — «на подписи», и никто не заметил подмены. Если бы карточка полномочия требовала явного основания для каждого подписанта, письмо запустило бы проверку: есть ли доверенность, на какой срок, покрывает ли она сумму договора.

Здесь важно не «автоматически переключить подписанта», а не дать сделке молча проскочить смену лица. Сотрудник, получивший письмо, фиксирует нового подписанта, прикладывает основание и отмечает, что прежняя проверка к нему не относится. Пока это не сделано, договор не считается готовым к отправке.

Доверенность с ограничением по сумме

Второй условный эпизод. Представитель контрагента присылает доверенность, где право подписи ограничено суммой, а договор превышает этот порог. Внешне всё аккуратно: документ действующий, подписант указан, печать на месте. Ограничение всплывает только при сверке суммы договора с текстом доверенности. Если в карточке полномочия есть поле «границы» и оно связано с суммой сделки, расхождение видно до отправки, а не после спора о действительности.

Такие случаи — аргумент против того, чтобы поручать проверку одному человеку «по памяти». Ограничение по сумме, по типу сделки, по сроку — каждая граница требует, чтобы кто-то сопоставил её с условиями договора. CRM может подсветить несоответствие, но решение о том, достаточно ли полномочия, принимает уполномоченный сотрудник по применимым документам.

Согласование как маршрут, а не как переписка в чате

Согласование подписанта удобно описывать как маршрут с точками решения. Кто-то фиксирует основание, кто-то проверяет границы, кто-то подтверждает, что подпись получена на утверждённой версии. В системах класса Microsoft Power Automate согласование оформляется как запрос с принятием или отклонением и записью решения — это полезный ориентир для того, как должна выглядеть фиксация, а не доказательство, что такие функции есть в конкретной CRM. Логика простая: у каждого шага есть ответственный и результат, а не безличное «вроде согласовали».

Маршрут стоит строить вокруг исключений. Обычный договор с директором по уставу проходит короткий путь. Появление доверенности, смена лица, превышение суммы — включают дополнительную проверку. Если маршрут одинаков для всех сделок, он либо слишком тяжёл для простых, либо слишком легкомыслен для сложных.

Разграничение доступа к полномочиям

Документ полномочия — чувствительная информация: доверенность, паспортные данные представителя, внутренние приказы. Не каждый менеджер должен видеть вложение целиком. В системах с ролевой моделью, как описано в документации Microsoft по ролям безопасности и полномочиям, доступ выдаётся по роли и привилегии, а не «всем, кто открыл сделку». Это ориентир для проектирования: право видеть основание полномочия и право менять статус проверки — разные привилегии.

Практический смысл в том, что менеджер видит достаточно, чтобы не отправить договор не тому лицу, но не получает лишнего доступа к персональным данным. Проверку документа проводит уполномоченный сотрудник, а в сделке остаётся результат: проверено, кем, когда, на каком основании.

Несколько организаций и один человек

Частая ситуация: одно и то же лицо подписывает за несколько связанных компаний, и в каждой у него свой объём полномочий. Директор в одной организации действует по уставу, в другой — по доверенности от материнской структуры. Если CRM привязывает подписанта к человеку, а не к паре «человек — организация», возникает путаница: полномочие из одной компании механически переносится на сделку с другой.

Решение — хранить полномочие на связке «подписант + организация + документ», а не на человеке вообще. Тогда при переходе к другой компании сделки сотрудник видит, что прежнее основание здесь не действует, и запускает проверку заново. Это же защищает от ошибки, когда менеджер копирует карточку контрагента и вместе с ней тянет чужое полномочие.

Подпись на неутверждённой версии

Отдельный риск — технический. Договор правили трижды, последняя правка не прошла согласование, а подпись вернулась на предпоследней редакции. Если в карточке нет связи между версией договора и фактом подписи, расхождение обнаруживается случайно. Поле «версия» в форме полномочия и в карточке сделки помогает сопоставить, что именно подписано и что утверждено.

Это не про юридическую силу подписи как таковой — это про управляемость процесса. Сотрудник, принимающий документ, сверяет версию и фиксирует результат. CRM подсвечивает несовпадение, но вывод о последствиях делает уполномоченный сотрудник по применимым документам и внутреннему порядку.

Что поручать агенту, а что оставлять человеку

Агентская CRM с поиском клиентов и подготовкой карточек может собрать черновик: подтянуть публичные сведения об организации, напомнить, что срок доверенности истекает, показать, каких полей не хватает. ИИ-продавец в звонках по согласованному сценарию способен зафиксировать, кто в разговоре назван подписантом, и передать задачу менеджеру. ИИ-команда для задач бизнеса со знаниями и настроенными инструментами может помочь найти нужный документ во внутренней базе. Всё это — проектные сценарии, а не заявление о готовых функциях.

Граница проходит по решению о полномочии. Изменение этапа, суммы, ответственного, статуса «полномочие проверено» согласует сотрудник. Машина готовит материал и подсвечивает пробелы, человек подтверждает, что основание достаточно. Если переложить подтверждение на агента, ответственность за неверную проверку никуда не денется, а след потеряется.

Как проверить, что процесс держит удар

Проверку стоит строить на исключениях, а не на идеальном сценарии. Прогоните условный набор: подписант сменился после согласования; доверенность истекла за день до подписи; сумма договора выше границы доверенности; подпись вернулась на неу-approved версии; одно лицо подписывает за две организации; договор идёт через представителя по доверенности. Для каждого случая должно быть ясно, кто замечает проблему, на каком шаге и что фиксируется в сделке.

Если хотя бы один случай проходит молча, процесс не готов. Хороший признак — когда система останавливает отправку и требует явного действия, а не когда она «в целом работает».

Практикум: разбор одной сделки по шагам

Возьмите условную сделку на поставку на сумму, близкую к порогу доверенности представителя. Выпишите четыре роли: кто вёл переговоры, кто правил договор, кто подписывает, на каком основании. Сверьте публичные сведения об организации с документом полномочия. Отметьте дату проверки и границы. Затем задайте три вопроса: что изменится, если подписант сменится завтра; что будет, если доверенность истечёт до подписи; как вы узнаете, что подписана утверждённая версия. Ответы на эти вопросы и есть минимальный набор требований к карточке полномочия.

Практикум полезен тем, что вскрывает пробелы до реальной сделки. Если на вопрос «кто проверяет границы» нет имени, значит, проверки нет — есть надежда.

Трудные исключения, которые не стоит прятать

Есть случаи, которые плохо ложатся в любую форму. Подписант действует по устному указанию руководителя без документа — формально основания нет. Доверенность есть, но её текст допускает разные толкования объёма. Организация реорганизуется, и полномочия переходят в переходный период. Такие ситуации не решаются настройкой полей; их разбирает уполномоченный сотрудник по применимым документам, а CRM фиксирует, что вопрос открыт и кто его ведёт.

Честнее оставить в сделке статус «требует проверки», чем закрыть его галочкой ради красивого отчёта. Исключения — это не сбой процесса, а его граница. Процесс, который их признаёт, надёжнее того, который делает вид, что их нет.

Интерфейс для сотрудника: что видно на экране сделки

Менеджеру не нужен весь документ полномочия — ему нужен ответ на вопрос «можно ли отправлять». Поэтому на экране сделки достаточно компактного блока: подписант, основание, границы, дата проверки, статус. Если чего-то не хватает, блок показывает, чего именно, и к кому идти. Уполномоченный сотрудник открывает тот же блок в расширенном виде, видит вложение и историю проверок.

Такой интерфейс снижает соблазн «дожать сделку» в обход проверки: путь к статусу «готово к отправке» виден и короток, а обход требует явного действия, которое останется в истории. Это и есть практическая ценность — не запреты, а прозрачный маршрут.

Один шаг проверки

Вся тема сводится к одному вопросу: на каком основании мы считаем, что этот человек вправе подписать этот договор именно сейчас. Публичные сведения ФНС помогают сверить организацию и руководителя, но не заменяют документ полномочия. Согласование в системах класса Power Automate показывает, как фиксировать решения, но не решает, достаточно ли основание. Роли безопасности подсказывают, как разграничить доступ, но не подменяют проверку.

Конкретный шаг: возьмите одну текущую сделку на подписи и выпишите для неё подписанта, основание, границы и дату проверки. Если хотя бы одно поле не заполняется без звонка коллеге, у вас есть задача для настройки карточки полномочия — и её стоит обсудить до следующего договора.

Контрольный пакет для проверки подписанта до отправки договора

Для внутренней проверки подготовьте обезличенный договор с известной редакцией и карточку лица, которое собирается его подписать. В отдельном листе укажите организацию, роль человека в переговорах, заявленное основание полномочия и вопрос, который должен решить уполномоченный проверяющий. Не заполняйте пробелы предположением «обычно такие документы подписывает директор». Должность из подписи письма и проверенное полномочие остаются разными сведениями.

После настольного упражнения попросите проверяющего назвать предмет своего решения: какого человека, какую организацию и какую редакцию он проверил. Эта запись не заменяет юридический анализ и не устанавливает действительность подписи. Она помогает не потерять область выполненной проверки при подготовке следующего действия. Если область не восстанавливается, договор пока не стоит отправлять автоматически.

Соседний вопрос разобран отдельно: Реквизиты для счёта: как ИИ-продавец проверяет, кому продавать. Здесь основной предмет — маршрут проверки полномочия конкретного подписанта и применимого документа; не реквизиты плательщика.