# Сервис регистрации участников: статусы, оплаты, билеты и документы
Редакция SGI24. Статья основана на операционном опыте CONF24; отдельные функции нужно подтверждать на границах конкретного проекта. [О бюро](/company).
Сервис регистрации на мероприятие оценивают по форме и красивому билету. Но основные сложности появляются после отправки: дубли, корпоративные участники, договоры, неоплаченные счета, замены, допуск, check-in и материалы.
Подходящий продукт должен поддерживать модель конкретного события. Бесплатному вебинару нужен короткий путь и доступ. Деловой конференции с юридическими лицами — организации, делегации, документы, оплату и фактическое участие.
Разобрать регистрацию участников
Сначала опишите типы регистрации
Составьте список сценариев:
- бесплатный участник;
- физическое лицо с онлайн-оплатой;
- сотрудник компании со счётом;
- несколько участников по одному договору;
- приглашённый гость;
- спикер;
- партнёр;
- пресса;
- онлайн-участник;
- регистрация на месте;
- лист ожидания;
- замена участника.
Если сервис уверенно показывает только первый сценарий, он может не подойти для форума с документами и делегациями.
Форма — верхушка процесса
Форма должна:
- показывать только нужные поля;
- проверять формат;
- объяснять ошибку;
- сохранять выбранный тариф;
- фиксировать отдельные согласия;
- работать на телефоне;
- выдерживать пиковую нагрузку;
- подтверждать результат на сервере.
Но после неё требуется карточка регистрации, статус, связь с человеком, событием, организацией и оплатой. Если данные просто приходят письмом, это не система учёта участников.
Модель данных
Минимум четыре сущности:
text человек ↔ организация ↓ ↓ регистрация → событие
Дополнительно появляются:
- тариф;
- договор;
- платёж;
- билет;
- сессия;
- check-in;
- документ;
- согласие;
- коммуникация.
Контакт человека не равен регистрации. Один человек может посещать разные события, а одна организация — направлять делегацию.
Дубли
Участник может заполнить форму дважды, использовать рабочую и личную почту или зарегистрироваться через представителя компании.
Проверьте, как сервис:
- нормализует телефон и почту;
- ищет совпадения;
- показывает возможный дубль оператору;
- сохраняет две разные регистрации на разные события;
- обрабатывает нескольких людей с общей корпоративной почтой;
- объединяет историю без потери документов;
- восстанавливает ошибочное слияние.
Жёсткое слияние по одному полю опасно. Предложение оператору часто надёжнее автоматической замены.
Статусы
Система должна разделять:
- форму отправили;
- заявку приняли;
- участие одобрили;
- документ сформировали;
- оплату получили;
- билет выдали;
- участник пришёл.
Пример воронки:
text заявка → проверка → ожидается документ → ожидается оплата → подтверждено → check-in
Отдельные исходы:
- лист ожидания;
- отказ;
- отмена;
- возврат;
- перенос;
- замена;
- неявка.
Статус должен иметь правило перехода. Сотрудник не выбирает «участник» до выполнения условий допуска.
Ответственный и следующий шаг
Для регистрации с ручной работой нужны: владелец; срок; следующая задача; причина задержки; история.
Сервис, который хранит статус без задач, всё равно заставит команду вести контроль в таблице. Проверьте уведомления о просрочке и передачу карточки другому сотруднику.
Физические и юридические лица
Физическое лицо может оплатить картой. Компания часто требует счёт, договор и акт.
Для корпоративного сценария нужны:
- реквизиты организации;
- проверка и нормализация;
- контакт по документам;
- плательщик;
- несколько участников;
- один договор;
- раздельные билеты;
- замена сотрудника;
- закрывающие документы.
Не заставляйте каждого делегата вводить реквизиты компании. Представитель организации управляет договорным контуром, а участники подтверждают свои данные и получают персональный доступ.
Тарифы
Тариф содержит:
- цену;
- период действия;
- состав;
- формат;
- доступ к сессиям;
- материалы;
- условия возврата;
- лимит мест;
- доступные способы оплаты;
- правила замены.
Цена на сайте, в форме, договоре, платеже и CRM берётся из одного справочника. Изменение тарифа не должно задним числом менять уже подтверждённую регистрацию.
Промокоды
Проверьте:
- период;
- число применений;
- список тарифов;
- персональность;
- минимальную сумму;
- совместимость со скидками;
- источник кампании;
- отмену;
- журнал использования.
Промокод не должен позволять получить отрицательную цену или дважды применить скидку при повторной отправке формы.
Оплата
Система поддерживает:
- онлайн-платёж;
- счёт;
- частичную оплату, если она предусмотрена;
- возврат;
- перенос;
- просрочку;
- сверку;
- отмену.
Платёж связывается с регистрацией по внутреннему идентификатору. Сервер проверяет уведомление провайдера, сумму, валюту и статус. Возврат не стирает факт исходной операции.
Оплату подтверждает платёжная или учётная система. В регистрации хранится подтверждённый статус и связь с платежом.
Документы
Сервис должен формировать или получать из документооборота:
- договор;
- счёт;
- акт;
- приглашение;
- билет;
- сертификат;
- другие документы события.
Проверьте:
- шаблоны;
- версии;
- реквизиты;
- номера;
- массовое формирование;
- электронную подпись в выбранной схеме;
- права доступа;
- архив;
- защиту от двойной отправки.
Повтор команды должен вернуть тот же документ или контролируемо создать новую версию, а не выпустить дубль с другим номером.
Билет
Билет содержит минимум сведений, необходимых для допуска. Код должен ссылаться на регистрацию, но не раскрывать в открытом виде паспорт, телефон или полный набор данных.
Проверьте:
- персональность;
- защиту от подбора;
- повторное сканирование;
- замену;
- отзыв;
- офлайн-режим;
- печать;
- кошелёк телефона, если используется;
- доступ по оплате.
Билет выдаётся после выполнения условий, а не сразу после любой формы.
Check-in
На стойке сотрудник видит:
- имя;
- организацию;
- тип участия;
- допуск;
- факт входа;
- бейдж;
- минимальную рабочую отметку.
Сервис должен выдерживать пиковый поток, поддерживать несколько стоек и предотвращать конфликт одновременной отметки.
При отсутствии сети используется заранее проверенный резервный режим. После восстановления он синхронизируется без двойных входов.
Регистрация на месте
Сценарий включает:
- проверку доступных мест;
- короткую форму;
- согласия;
- оплату;
- выпуск билета или бейджа;
- связь с основной базой;
- выдачу документов позже при необходимости.
Отдельная таблица «пришли без регистрации» разрушает итоговую статистику и создаёт неконтролируемые данные.
Замена участника
Корпоративные события часто допускают замену. Система должна:
- Сохранить исходную регистрацию и историю.
- Проверить срок и правила.
- Получить данные нового человека.
- Отозвать старый билет.
- Выпустить новый.
- Сохранить связь с договором и оплатой.
- Обновить уведомления.
Нельзя просто переписать имя в карточке: старые согласия и действия относились к другому субъекту.
Отмена и возврат
Проверьте:
- кто может отменить;
- до какого срока;
- размер возврата;
- согласование;
- уведомление бухгалтерии;
- отзыв билета;
- освобождение места;
- изменение документов;
- сохранение истории.
Автоматический возврат без проверки тарифа может нарушить договорные условия. Полностью ручной процесс, наоборот, создаёт просрочки. Нужна явная схема.
Лист ожидания
Когда места закончились, сервис:
- принимает минимальные данные;
- объясняет статус;
- фиксирует отдельную цель связи;
- хранит очередь;
- предлагает место по правилу;
- ограничивает срок ответа;
- передаёт место следующему;
- удаляет или закрывает запись после события.
Лист ожидания не означает подписку на все мероприятия организатора.
Уведомления
Сервисные события:
- заявка получена;
- нужна проверка;
- документ готов;
- приближается оплата;
- участие подтверждено;
- билет доступен;
- программа изменилась;
- событие скоро;
- опубликованы материалы.
Шаблон получает данные из карточки события. Время и адрес не вводятся вручную в каждом письме.
Рекламная коммуникация отделяется от сервисной.
Персональные данные
Проверьте у поставщика:
- оператора и обработчика;
- цели;
- поля;
- согласия;
- место баз;
- трансграничные передачи;
- подрядчиков;
- права поддержки;
- журналы;
- резервные копии;
- сроки;
- экспорт;
- удаление;
- инциденты.
Сервис может технически хранить данные в России, но пересылать полную заявку в иностранную почту или систему аналитики. Нужен полный маршрут.
Интеграции
Проверьте не наличие слова API, а операции:
- создать регистрацию;
- обновить статус;
- получить тариф;
- записать оплату;
- выпустить билет;
- отметить check-in;
- заменить участника;
- получить документы;
- выгрузить журнал;
- обработать ошибку.
Уточните лимиты, задержку, webhooks, повтор запросов, тестовый контур и версионирование.
Экспорт и расторжение
Организатор должен получить:
- контакты в разрешённом объёме;
- регистрации;
- организации;
- документы;
- платежные связи;
- check-in;
- согласия и версии;
- историю статусов;
- идентификаторы.
CSV с именем и почтой не переносит доказательства, документы и связи. Условия выгрузки проверяются до подписания договора.
Отчёты
Минимальная сводка:
- регистрации по роли и тарифу;
- подтверждённые;
- ожидающие оплаты;
- документы;
- возвраты;
- билеты;
- фактические посетители;
- неявки;
- источники;
- время обработки;
- ошибки интеграций.
Показатели имеют определения. «Зарегистрировано» нельзя использовать для оплаченных и пришедших одновременно.
Как проверить сервис на демонстрации
Дайте поставщику сценарий:
- Компания регистрирует трёх сотрудников.
- Получает договор и счёт.
- Оплачивает частично, затем полностью.
- Меняет одного участника.
- Два человека приходят, один не приходит.
- Бухгалтерия получает акт.
- Руководитель видит фактический итог.
Попросите показать интерфейс участника, оператора, бухгалтерии и check-in. Зафиксируйте ручные действия и ограничения тарифа.
Частые ошибки выбора
- Оценивают только форму.
- Контакт смешивают с регистрацией.
- Не поддерживаются делегации.
- Нет истории замены.
- Статус оплаты ручной.
- Билет выдаётся до допуска.
- Check-in не работает без сети.
- Документы создаются вне системы.
- Нет версии согласия.
- API не умеет менять статус.
- Экспорт теряет связи.
- Лист ожидания хранится бессрочно.
Как проверяется регистрационный контур
Мы проектируем модель человека, организации, события и регистрации, затем связываем формы, статусы, документы, оплату, билет, check-in и материалы. При необходимости используем готовый сервис как компонент или создаём собственный контур на базе логики CONF24.
Организатор получает доказуемый путь: от отправки формы до фактического участия, без ручного пересчёта писем и таблиц.
Разобрать регистрацию участников или обсудить регистрацию участников.
Укажите типы участников, способы оплаты и действия команды после заявки. Так обсуждение начнётся со статусов и ответственности, а не с длины формы.
Связанные материалы
Выбор сервиса зависит от ролей, договоров, оплаты, формата допуска, числа событий и существующей CRM.
Документы по персональным данным
Готовые файлы Word. Одиночный документ собирается по форме, комплект выдаётся архивом после оплаты.