Коммуникации на EdTech-маркетплейсе: почему встроенный чат проигрывает внешним и как это изменить

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

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

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

Поэтому встроенный мессенджер должен быть частью продукта, а не отдельной кнопкой «Написать». Ниже — разбор проектирования коммуникационной инфраструктуры для Course.Tours, международного EdTech-маркетплейса с 30 000+ курсами, где студенты бронируют онлайн- и офлайн-обучение, а школы и преподаватели управляют всем через единую платформу.

Почему важно удерживать коммуникацию внутри продукта

Переход в сторонние мессенджеры кажется безобидным ровно до тех пор, пока проект не начинает расти.

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

Следом уходят данные. Что студент спрашивает, на что жалуется, чем интересуется — все это ценный сигнал для персонализации и улучшения продукта. Когда общение происходит вне платформы, эти данные просто выпадают из поля зрения команды.

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

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

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

Три типа чатов и логика доступа

При проектировании мессенджера для Course.Tours у команды MWI была задача не «сделать чат», а выстроить коммуникационную инфраструктуру, которая учитывает несколько типов пользователей, разные контексты общения и необходимость привязывать переписку к конкретным объектам — курсам, урокам, заказам.

Получилось три категории.

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

Кстати, работа с детской аудиторией добавляет в коммуникационные сценарии свои ограничения и требования. О том, как мы проектировали флоу бесплатного обучения для детей, рассказали в отдельном материале.

Матрица прав: кто и с кем может говорить

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

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

Главное преимущество встроенного мессенджера — контекст

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

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

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

Чат поддержки по конкретному заказу

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

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

Пользователю не нужно объяснять, о каком заказе идет речь, а сотруднику поддержки — тратить время на уточняющие вопросы. Это позволяет быстрее перейти к решению проблемы.

Чек-лист: 6 условий, при которых встроенный мессенджер не проиграет внешнему

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

1. Чат появляется автоматически. Запись на курс или оплата запускает коммуникацию без ручного создания.

2. Привязка к объектам платформы. Курсы, уроки и заказы становятся частью переписки.

3. Доступ определяется контекстом взаимодействия. Кто с кем может говорить — определяется не ролью как таковой, а тем, есть ли между пользователями активная связь внутри платформы. 

4. Действия происходят внутри чата. Материалы, расписание и изменения доступны прямо в переписке.

5. Поддержка привязана к курсу. Контекст уже известен до начала диалога.

6. Сохранение истории при изменении статуса. Студент отчислен — он теряет доступ, но данные остаются. Это важно и для аудита, и для разрешения спорных ситуаций.

Если хотите разобраться, как выстроить коммуникационную инфраструктуру под специфику вашего продукта — напишите нам.