Для мероприятий CRM должна различать человека, его регистрацию на конкретное событие и заказ с оплатой. Участник может посещать несколько мероприятий, а корпоративный заказчик — оплачивать места разных людей. Если все эти роли объединены в одну сделку, повторные регистрации и фактическая посещаемость становятся трудно проверяемыми.
Определите основные связи
Событие содержит дату, формат и согласованные категории участия. Регистрация связывает человека с событием и хранит собственный статус. Заказ описывает коммерческое обязательство, которое может охватывать одну или несколько регистраций.
Контакт плательщика не обязан совпадать с контактами участников. Отдельно обозначьте, кому направлять организационные сообщения и кому — документы по оплате. Такая модель является требованием к процессу; способы её реализации проверяют в выбранной CRM и регистрационной системе.
Разведите регистрацию и посещение
Отправленная форма показывает намерение, подтверждённая регистрация — выполнение условий участия, отметка посещения — фактическое присутствие. Эти события нельзя подменять друг другом. Иначе отчёт о гостях будет включать всех, кто когда-либо открыл заявку.
Для отмены, замены участника и переноса на другую дату задайте отдельные правила. Сохранение истории важно: удалённая регистрация исчезнет из анализа отказов и технической сверки. Коммерческие последствия отмены определяются условиями организатора и фиксируются отдельно.
Условный пример корпоративной заявки
Предположим, компания заказала пять мест и позже заменила одного участника. Один платёж покрывает весь заказ, но организационные сообщения нужны пяти конкретным людям. Если создать пять независимых сделок с полной суммой оплаты, выручка умножится.
В проектируемой схеме сумма относится к заказу, регистрации связаны с ним без повторного учёта денег. Замена меняет назначение одного места с сохранением истории. Фактическое посещение отмечается по каждой регистрации, поэтому можно отдельно показать оплаченные места и пришедших участников.
Управляйте повторной регистрацией
Человек может повторно отправить форму или приобрести участие в другом событии. Первый случай требует проверки дубля операции, второй — новой регистрации при сохранении общего контакта. Телефон или почта помогают сопоставлению, но решение должно учитывать идентификатор события и заказа.
После объединения ошибочных повторов сохраняйте ссылки на исходные отправки. Это позволяет объяснить разницу между журналом сайта и количеством регистраций. Общая логика профилактики и очистки дублей рассмотрена в статье о дублях amoCRM.
Планируйте коммуникации по статусу
Подтверждение участия, напоминание, изменение программы и запрос обратной связи относятся к разным моментам. Перед отправкой проверяйте актуальный статус регистрации и адресата. Отменённый участник не должен получать сообщение, построенное на предположении, что его место подтверждено.
Для корпоративного заказа полезен отдельный обзор у ответственного заказчика, но он не заменяет индивидуальную организационную информацию. Историю отправок и ответов связывайте с нужным объектом, чтобы сотрудник видел контекст и не повторял уже решённый вопрос.
Контрольная программа мероприятия
Протестируйте одиночную покупку, корпоративный заказ, повтор формы, замену участника, отмену и посещение без предварительной отметки. Сверьте число мест, регистраций, уникальных людей, платежей и фактических посещений отдельно.
Приёмка завершена, когда эти числа объяснимо связаны, а денежная сумма не умножается из-за количества гостей. Для каждого участника можно найти его событие и актуальную регистрацию, для каждого заказа — список мест и состояние оплаты. Такая проверка полезнее одного общего показателя «сколько лидов пришло на мероприятие».
Применить в вашей компании
Обсудим вашу задачу?
Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.