Сравнение версий предложения: какую версию согласовал клиент?

Четверг, 16:20. Менеджер пишет клиенту: «Перевожу согласованное вами предложение в договор» — и открывает папку на рабочем столе. Внутри четыре файла: kp_v2.pdf, kp_v2_final.pdf, kp_v2_final_pravki.pdf и kp_aktualnoe.pdf. В трёх разные итоговые суммы, в двух разное количество позиций, в одном отсрочка платежа 60 дней вместо 30. Письмо клиента со словами «мы согласны» пришло одиннадцать дней назад, вложения в нём нет — только фраза «утверждаем предложение во вложении». Менеджер не знает, какая версия была согласована. Бухгалтерия просит сумму для счёта, а клиент считает, что скидка из второго круга обсуждений в силе. Договор ещё не написан, а стороны уже говорят о двух разных документах.

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

Сколько раз меняется предложение до подписания?

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

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

Когда версии не отслеживаются, теряются вполне конкретные вещи:

• За что была дана каждая скидка — за отсрочку, за расширение объёма, за согласие быть референсом?
• Какую позицию клиент попросил убрать и вернулась ли она позже.
• В каком круге упала цена — и с какой точки начнётся торг при продлении.
• Курс валюты на момент выставления и реальная маржа, которая из него следует.
• Кто, когда и на каком основании согласовал отступление от правил.

Почему вопрос «какую версию вы согласовали» задают слишком поздно?

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

Дороже всего обходится не спор, а повторная работа. Финансы идут к продажам за правильной суммой, продажи — к клиенту, клиент — в собственный архив. Один и тот же документ читают трижды, и никто не создаёт ничего нового. Из-за этого этап после отправки выглядит длиннее, чем он есть: доведение отправленного предложения до сделки — измеримый процесс, и удлиняет его чаще не сомнение клиента, а неопределённость на вашей стороне.

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

Что считать новой версией, а что просто правкой?

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

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

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

В каком порядке читать различия между двумя версиями?

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

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

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

Какое изменение требует новой версии, повторной отправки и согласования?

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

Изменение	Новая версия	Повторная отправка	Согласование руководителя
Опечатка или вёрстка до отправки	Нет	Нет	Нет
Уточнение описания позиции	Да	Да	Нет
Добавление или удаление позиции	Да	Да	По порогу объёма
Изменение цены или скидки по строке	Да	Да	Да, если пробит порог маржи
Смена валюты или графика платежей	Да	Да	Да
Продление срока действия	Да	Да	Да при валютном риске

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

Какие записи фиксируют согласованную версию?

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

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

Четвёртый замок стоит на переходе к договору. В договор переводится только принятое предложение; название, сумма, валюта и стороны переносятся как есть, и одно предложение нельзя перевести дважды, создав дубль. Тогда на вопрос «какая версия была согласована» отвечает сам договор: та, из которой он произведён.

Кто, когда и на каком основании согласовал скидку?

Большинство споров о версиях — это на самом деле споры о скидке. Уступка, данная в третьем круге и оставшаяся в документе в четвёртом, когда объём уже сократился, тихо съедает маржу. Поэтому согласование скидки должно быть привязано к самому предложению, а не к отдельному разговору.

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

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

Что происходит, если клиент принимает только часть позиций?

Частичное принятие — самое надёжное место производства путаницы с версиями. Клиент говорит: «Берём лицензии и внедрение, обучение пока пропустим»; менеджер готовит новый PDF и отправляет, а клиент отвечает «согласовано» на старое письмо. В итоге два документа и одна фраза о согласии.

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

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

Какие отчёты питает история версий?

Записи о версиях не только гасят споры — сами по себе они набор данных. Аналитика предложений и выгрузка показывают, сколько предложений принято и в каком диапазоне сумм вы застреваете; данные выгружаются в CSV или Excel и переносятся в вашу модель. Добавьте к этому число версий — и станут отвечаемыми ещё четыре вопроса.

• За сколько версий в среднем закрываются выигранные сделки и на какой версии останавливаются проигранные?
• Даёт ли скидка, выданная после второй версии, реальный прирост конверсии?
• Какую позицию чаще всего убирают — дело в цене или в том, как она описана?
• Какую долю цикла съедает ожидание в очереди согласования?

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

Как выстроить дисциплину версий за тридцать дней?

Первая неделя: измерьте текущее состояние. Возьмите десять предложений, закрытых за последний квартал, и по каждому выпишите, сколько файлов было создано, где зафиксировано согласование и из какого документа взята сумма в договоре. Этот список делает масштаб проблемы неоспоримым.

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

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

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

Частые вопросы

Что делать, если клиент согласовал старую версию?

Не отклоняйте согласование — проверьте его. Откройте согласованную клиентом версию, поставьте рядом с актуальной и опишите разницу одним сообщением: какая позиция изменилась, какова разница в сумме, какая версия должна действовать. Решение оставьте за клиентом, но разницу зафиксируйте письменно. Затем отправьте согласованную версию повторно, получите новое подтверждение и только из неё формируйте договор.

Сколько версий — это уже много?

Фиксированного числа нет, но количество версий обнажает закономерность. Если после третьей версии всё ещё обсуждается объём, проблема не в цене, а в первичной квалификации. Если после четвёртой сумма продолжает падать, сделка чаще всего скатилась в ценовую войну. Сравните медианное число версий по выигранным и проигранным сделкам: ваш порог лежит где-то между этими двумя числами.

Должен ли клиент видеть историю версий?

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

Помогает ли сравнение версий при продлении?

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