ТЗ на amoCRM: сделки, воронки, дубли и контроль интеграций

Начните с правил сделки

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

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

Опишите воронки и ответственность

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

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

Обсудите отпуск, увольнение и отсутствие сотрудника. Кто видит необработанные обращения, может назначить замену и отвечает за просроченные действия? Автоматическое распределение без правил исключений иногда превращает общую очередь в набор бесхозных карточек.

Свяжите контакт, компанию и потребность

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

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

Отделите дубль от повторного запроса

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

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

Задайте контракт каждой интеграции

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

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

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

Переносите историю с контрольной выборкой

Инвентаризируйте контакты, компании, сделки, примечания, задачи и вложения. Уточните, какие данные действительно доступны для переноса и какие ограничения выявило обследование. Сохранение количества строк не доказывает сохранность связей: десять сделок могут оказаться привязанными к одному неправильному контакту.

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

Принимайте результат через действия сотрудников

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

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

Передайте в оценку конкретный пакет

Готовый пакет включает схему воронок, словарь полей, матрицу ролей, карточки обменов, перечень переносимых данных и приёмочные сценарии. Неизвестные возможности выделите в обследование с конкретным вопросом и результатом. Так оценка будет зависеть от объёма и рисков, а не от общей формулировки «настроить CRM».

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