На демонстрации CRM всё складывается: ученик записался, администратор увидел оплату, тренер открыл группу. Через неделю работы выясняется, что семейный абонемент приходится вести в заметке, а отмену исправлять вручную.
До переноса всей школы проверьте несколько своих сценариев. Для этого не нужен длинный рейтинг программ: достаточно примеров, на которых ваша команда обычно спорит или тратит время.
Подготовьте условные карточки
Возьмите типичные ситуации школы, заменив реальные имена и контакты вымышленными. Не загружайте клиентскую базу в несколько пробных сервисов просто ради просмотра интерфейса. Сначала выясните порядок работы с данными и переноса.
Для проверки достаточно ученика с обычным пакетом, двух детей с одним родителем, тренера с заменой и абонемента, у которого есть будущая запись. Добавьте один спорный случай из своей практики, убрав сведения, по которым можно узнать человека.
Запишите ожидаемый итог каждого сценария до демонстрации. Тогда красивый экран не подменит ответ на рабочий вопрос.
Сценарий 1: покупка, запись и остаток
Создайте пакет на восемь занятий и одну запись. Посмотрите, в какой момент уменьшается остаток: при бронировании, отметке посещения или по другому правилу.
Проверьте будущие записи и срок действия. Сотрудник должен объяснить остаток по событиям, не складывая его заново в соседней таблице. Если ваша текущая логика отличается от логики сервиса, зафиксируйте, что изменится для школы при переходе.
Сценарий 2: отмена и исключение
Отмените запись по обычному правилу, затем разберите исключение. Уточните, кто может вернуть занятие, где сохраняется причина и как изменение отражается у ученика.
Проверьте, можно ли случайно исправить один остаток дважды. Не просите поставщика просто отметить галочку «отработки есть»: попросите показать полный путь от исходной записи до нового результата.
Сценарий 3: родитель и два ребёнка
Посмотрите карточки глазами родителя и администратора. Проверьте, чьи записи, покупки и сообщения доступны в каждом кабинете. Одного общего контакта недостаточно, чтобы считать задачу решённой.
Не используйте реальные медицинские документы при такой демонстрации. Для проверки доступа достаточно условного файла и понятного ожидаемого результата.
Сценарий 4: итог периода
Попросите показать, из каких исходных записей собрана одна сумма в отчёте. Выручка, оплаты и начисление за проведённые занятия могут считаться по разным датам.
Если нужна зарплата тренера, проверьте именно вашу схему и замену в середине периода. Фиксированная ставка, процент от продажи пакета и процент от выручки посещений — разные условия. Запишите ограничения сервиса до выбора.
Сценарий 5: начало и окончание работы
Обсудите перенос действующих остатков, сопоставление учеников и проверку результата. Уточните, кто выполняет перенос и какие ошибки школа разбирает самостоятельно.
Затем посмотрите выгрузку: какие данные доступны, в каком формате, где находятся файлы. Узнайте порядок закрытия аккаунта. Это помогает оценить зависимость от сервиса до того, как в нём появится вся история школы.
Сведите результат в одну таблицу
| Поле проверки | Что записать |
|---|---|
| Сценарий | Отмена записи |
| Ожидаемый итог | Один понятный возврат занятия |
| Показан в системе | Да / нет |
| Ограничение | Записать конкретно |
| Решение школы | Подходит / требует изменения процесса |
Заполняйте таблицу во время проверки. «Подходит» означает, что показанный путь совпадает с нужным вам результатом. Если требуется доработка, отдельно запишите, существует ли она сейчас, кто её обещал и когда школа готова вернуться к проверке.
Возможности MyAerial CRM собраны на странице продукта, подготовка перехода — в разделе начала работы. Сравнивайте фактически показанные процессы на одинаковых примерах. Для решения владельцу полезнее пять проверенных сценариев, чем длинный список одинаково звучащих функций.