Приёмка услуг в CRM: выполненная задача ещё не принятый результат

Команда закрыла задачу, а клиент ещё проверяет результат. В CRM всё это часто смешано в одном статусе, из-за чего частичная приёмка и замечания превращаются в спор о том, кто что имел в виду.

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

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

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

Выполнение, предъявление, приёмка и закрытие — четыре события с разными доказательствами

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

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

Позиция клиента — принято, принято с замечаниями, отклонено — принадлежит конкретному человеку с конкретными полномочиями. «Клиент сказал» без имени — не позиция, а слух, который переживёт трёх менеджеров и потеряет смысл на втором. В документации Microsoft по согласованиям в Power Automate запрос на согласование описан как отдельный объект с решением и комментарием (принятие и отклонение согласований) — полезная иллюстрация того, что согласование живёт отдельно от задачи. Но наличие такого объекта в одном продукте ничего не говорит об устройстве приёмки в другом.

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

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

Условный заказ на четыре этапа: три приняты, четвёртый ушёл в замечания

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

Менеджер видит картину как «75% готово» и хочет закрыть заказ. Но 75% — арифметика, а приёмка — перечень. Внутри заказа должны существовать четыре единицы приёмки, и у каждой своя позиция: принято письмом от такого-то числа; принято устно, документально не подтверждено; предъявлено, позиция не получена; предъявлено, есть замечание с формулировкой.

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

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

Рабочий объект «предъявление»: поля, без которых приёмка превращается в переписку

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

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

Отдельно стоит решить, кто может менять записи. Исполнитель вправе создать предъявление и приложить редакцию; сотрудник, ведущий заказ, — зафиксировать позицию клиента; менеджер — инициировать оформление. Право «просто поправить статус» лучше не выдавать никому: именно оно превращает историю в удобную версию событий.

Критерий приёмки поменялся после старта: две версии, два разных разговора

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

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

Практическое правило: критерий версионируется, а предъявление ссылается на конкретную версию. Тогда «мы переделали» и «вы поменяли задание» перестают быть взаимными упрёками и становятся двумя записями с датами. У коммерческого предложения в Dynamics 365 Sales тоже есть состояния и версии (коммерческие предложения и их состояния) — как пример того, что документ живёт во времени; приёмка услуги требует такой же дисциплины, но собственной модели.

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

Замечание внутри задания и просьба за его пределами

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

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

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

Полезная привычка — закрывать замечание не словом «исправлено», а ссылкой на новую редакцию и указанием, к какому критерию оно относилось. Тогда следующее предъявление не начинается с вопроса «а мы точно про это говорили?».

Согласующий: полномочия, а не должность в подписи письма

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

Полномочия проверяются по документам: договор, регламент, доверенность, приказ. Это работа уполномоченного сотрудника, и никакая настройка не заменит чтения документа. Задача системы скромнее: хранить основание, по которому тот или иной человек считается согласующим, и не давать менять это основание молча.

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

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

Какая редакция результата лежит перед клиентом

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

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

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

Устное «в целом нормально»: состояние, которого нет

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

Устное высказывание стоит фиксировать как отдельный факт: кто сказал, когда, в каком разговоре, дословно. Но статус приёмки от этого не меняется — он остаётся «предъявлено, позиция не подтверждена». Иначе через месяц выяснится, что «нормально» означало «нормально, что вы начали», а не «результат годен».

Экран предъявления: что сотрудник должен увидеть до смены этапа

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

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

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

Восемь испытаний цепочки от результата до ответа заказчика

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

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

Практикум: частичная приёмка услуги на одном обезличенном задании

Для условного упражнения возьмём работу по подготовке четырёх инструкций. У каждой есть назначение, согласованный состав и свой проверяющий. Три инструкции приняты, в четвёртой заказчик просит добавить новый раздел, которого не было в исходном задании. Это упражнение не устанавливает юридическое значение ответа: оно помогает проверить внутреннюю прослеживаемость результата и вопроса об изменении объёма.

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

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

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

Стоимость незавершённой приёмки и полезные показатели

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

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

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

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

Соседний вопрос разобран отдельно: Передача клиента из продаж в производство: что теряется между отделами. Здесь основной предмет — предъявление результата услуги, замечания, частичная приёмка и подтверждение; не передача продажи в производство.