Принимать CRM стоит по заранее согласованным рабочим сценариям: сотрудник выполняет действие под своей ролью, а заказчик сверяет результат с требованием и сохраняет подтверждение. Демонстрация настроек интегратором полезна, но не заменяет такую проверку. До оформления сдачи соберите результаты тестов, список отклонений и комплект передачи системы.
Ниже — технический порядок приёмки и заготовка проверок. Это не универсальная форма акта: состав сдаваемых работ, порядок оформления и сроки нужно сверять с договорённостями по конкретному проекту. Успешный тест подтверждает проверенный сценарий в указанной конфигурации, а не отсутствие любых будущих ошибок.
С чего начать приёмку
- Зафиксируйте состав сдачи. Версия требований, принятые изменения, воронки, роли, каналы, интеграции и переносимые данные. Отдельно перечислите исключённые работы.
- Назначьте принимающих. Менеджер проверяет свою ежедневную работу, руководитель — контроль и отчёты, ответственный за систему — доступы, обмен и передачу документации. Интегратор помогает воспроизвести результат и исправляет отклонения.
- Подготовьте среду. Запишите аккаунт, дату, тариф, версии подключений и используемые устройства. На время прогона согласуйте порядок изменения настроек: иначе разные тесты проверят разные состояния системы.
- Выделите контрольные данные. Учебные клиенты, адреса и номера, которыми управляет команда; понятная отметка теста и способ исключения из рабочих отчётов. Не запускайте рассылки и создание реальных финансовых документов ради проверки.
- Свяжите требования с тестами. Для каждого обязательного результата должно быть видно, каким сценарием он проверяется и кто подтверждает итог.
Если ожидаемое поведение не определено, сначала уточните его. Отсутствие договорённости нельзя превратить в успешный тест. Структура исходных требований разобрана в руководстве по ТЗ на CRM.
Набор приёмочных сценариев
Это заготовка, которую нужно адаптировать к согласованному объёму. Повторите применимые строки для каждого канала, роли и направления обмена. Если интеграции или миграции в проекте нет, отметьте «не входит в объём» с основанием, вместо формального «пройдено».
| ID и проверка | Действие | Ожидаемый результат | Подтверждение |
|---|---|---|---|
| T01 · Новая заявка | Отправить контрольное обращение из каждого канала | Сохранены нужные сведения и источник, назначены ответственный и следующий шаг по правилу | Время отправки, ID события, ссылка на карточку и задачу |
| T02 · Повтор доставки | Повторить передачу того же тестового события через согласованный инструмент | Нет лишней сделки, задачи или внешнего документа; повтор обработан по требованию | Один исходный ID и результаты обеих попыток |
| T03 · Новый запрос прежнего клиента | Передать отдельное обращение с известным контактом | Новый запрос сохранён; связь с клиентом и создание сделки соответствуют правилу | Два разных обращения и их связи в CRM |
| T04 · Передача работы | Сменить ответственного, пройти следующий этап под новой ролью | Нужные данные доступны, задачи распределены по согласованной логике | Результат из учётных записей передающего и принимающего |
| T05 · Запрет доступа | Открыть чужую контрольную карточку, попробовать запрещённое изменение и экспорт | Разрешённые действия работают, запрещённые не выполняются | Роль, этап, проверяемое действие и фактический отказ |
| T06 · Исключение в автоматизации | Выполнить переход без обязательных данных и повторно войти в этап | Система следует заданным условиям; нежелательное сообщение или задача не появляются | Начальное состояние, переход, история действий |
| T07 · Обмен и восстановление | Передать объект, затем смоделировать сбой в безопасной среде и восстановить доставку | Поля и связи верны; ошибка заметна ответственному, восстановление не создаёт дублей | ID в обеих системах, журнал ошибки и результат повторной обработки |
| T08 · Перенос данных | Сверить итоги переноса и выборку сложных записей с источником | Количество объяснимо с учётом исключений; поля, связи и согласованная история сохранены | Сводка расхождений и пары исходных и перенесённых записей |
| T09 · Отчёт | Рассчитать показатель вручную по контрольному набору и открыть отчёт | Совпадают результат, период, фильтры и правила учёта | Список карточек, контрольный расчёт, параметры отчёта |
| T10 · Самостоятельная работа | Попросить сотрудника пройти процесс по переданной инструкции без подсказок | Процесс завершён, сотрудник знает, куда сообщить о проблеме | Протокол прогона и список недостающих пояснений |
Каждой попытке добавьте дату, проверяющего, версию настройки, фактический результат и статус: «пройдено», «ошибка», «заблокировано» или «не проверено». Если не предоставлен тестовый доступ к внешней системе, это блокировка проверки, а не подтверждение работоспособности.
Почему недостаточно проверки под администратором
Администратор может видеть и выполнять то, что недоступно менеджеру. Проверяйте не только открытие карточки, но и конкретные действия: изменение поля, переход этапа, удаление, выгрузку, доступ к сообщениям. Нужен как разрешённый пример, так и пример, в котором ожидается отказ.
В amoCRM на итоговые права влияют общие настройки и права на статусы; право просмотра также может расширяться для подписчика чата сделки. Поэтому одной фотографии настроек роли недостаточно: важен фактический доступ к контрольной карточке в нужном состоянии. Официальная документация amoCRM о правах пользователей.
Включите мобильное приложение, если оно входит в рабочий процесс. Результат проверки в браузере не подтверждает автоматически удобство и доступность того же действия на другом устройстве.
Как проверять интеграции при сдаче
Для каждого направления обмена проследите один объект от исходного события до конечного результата. Сверьте не только факт появления карточки, но и значения полей, ответственного, связи, время обработки и последующее исправление данных. В двустороннем обмене отдельно проверьте, кто определяет итоговое значение при изменениях с обеих сторон.
Повтор доставки и новое обращение клиента — разные ситуации. Первая не должна порождать лишний результат, если это предусмотрено требованиями; вторая не должна исчезнуть как «дубль». Зелёный индикатор подключения ни одну из этих проверок не заменяет.
В документации вебхуков amoCRM описаны повторные попытки доставки после неудачного ответа и условия отключения хука. Следовательно, приёмка подключения должна учитывать повтор и отказ получателя; нельзя предполагать, что событие всегда приходит единожды или будет повторяться бесконечно. Это относится к описанному механизму вебхуков, а не ко всем приложениям из каталога. Правила доставки вебхуков amoCRM.
Сбой моделируйте в тестовом контуре или согласованном безопасном режиме. Не отключайте рабочий канал в разгар продаж. Если безопасный тест пока невозможен, запишите ограничение, ответственного и способ будущей проверки. Успешный ответ сервера ещё не доказывает, что заказ появился в учётной системе: нужен конечный объект и сверка данных.
Что получить вместе с готовой системой
Согласуйте комплект передачи заранее. Следующий список — практический ориентир для эксплуатации, а не утверждение об обязательном составе документов любого договора.
- Описание фактической конфигурации: воронки, поля, роли, автоматизация, зависимости и отличия от первоначального ТЗ.
- Схемы подключений: системы, направления, сопоставление полей, идентификаторы, обработка ошибок и ответственные.
- Результаты проверок: сценарии, подтверждения, замечания, повторные тесты и непроверенные ограничения.
- Инструкции: действия пользователей, типовые исключения, порядок обращения за помощью, включения и остановки автоматизации.
- Управление доступами: владельцы аккаунтов и подписок, проверенный административный доступ заказчика, перечень внешних доступов. Секреты передавайте через согласованное защищённое хранилище, отдельно от протокола.
- Материалы разработки, если она была: согласованные исходники, версии, размещение, порядок обновления и восстановления; ограничения сторонних компонентов.
- Переход в эксплуатацию: кто принимает инциденты, сроки реакции по договорённостям, границы исправлений и новых работ, период наблюдения.
Проверьте передачу действием: ответственный со стороны заказчика открывает документацию, находит нужную настройку и объясняет, как сообщить о сбое. Если систему передают новой команде, пригодится отдельный список передачи при смене интегратора.
Как фиксировать недоделки и повторную проверку
Заведите единый реестр. Для замечания нужны номер требования и теста, шаги воспроизведения, ожидаемый и фактический результат, время, роль и ссылка на пример. Добавьте влияние на работу, исполнителя, согласованный срок и критерий закрытия. Скриншот без контекста часто показывает симптом, но не позволяет повторить ошибку.
Учебный пример: «D-07, тест T02. Повторно передано событие TEST-42. Ожидалась одна задача по согласованному правилу, фактически появились две. Проверено под ролью менеджера, ссылки на обе задачи приложены. Закрытие: повторить тест после исправления и проверить T01 и T03, чтобы новая заявка не перестала создаваться». Это вымышленная запись, не клиентский кейс.
Разделяйте отклонение от согласованного требования, неясное требование и новое пожелание. У них разные следующие действия: исправить, принять решение или оценить дополнительный объём. Статус «исправлено исполнителем» означает готовность к повторному тесту; закрывает замечание принимающий после проверки.
Для технического допуска заранее определите блокирующие ситуации: например, потеря обращения, неверная отправка клиенту или доступ к закрытым данным. Для менее критичного отклонения зафиксируйте допустимый обходной порядок и срок устранения. Не прячьте нерешённое замечание в общем статусе «всё работает».
Что должно быть понятно перед оформлением сдачи
Итоговый технический протокол должен позволять ответить на четыре вопроса: какой объём проверен; что подтверждено; какие ограничения остаются; кто и когда занимается ими дальше. Приложите актуальный реестр замечаний и перечень переданных материалов. Формулировки подписываемых документов сверяйте с этим фактическим результатом и согласованным порядком сдачи.
Приёмка готовой конфигурации и наблюдение за работой команды решают разные задачи. Для проверки поведения на ограниченном реальном потоке используйте план пилота CRM. Короткий прогон не доказывает готовность к любой нагрузке или рост продаж.
В новом проекте этот набор сценариев можно использовать при согласовании внедрения amoCRM. Он поможет определить проверяемый результат, комплект передачи и порядок дальнейшей эксплуатации до начала настройки.