Чат покупателя и оператора
Крупная продуктовая сеть попросила спроектировать чат поддержки с нуля — без существующего интерфейса. На этом этапе я был проектировщиком, дизайнером и тестировщиком: спроектировал три интерфейса (покупатель, оператор, администратор), протестировал, запустили в прод.
После запуска добавлялись новые функции — и стало заметно, что скорость проседает: при реальной нагрузке (сотни диалогов в день) загрузка интерфейса занимала около минуты. Был предложен рефакторинг на новую архитектуру — на этом этапе я подключился как фронтендер и задокументировал WebSocket-сообщения.
Цель — чтобы фронтенд и бэкенд договорились об ожиданиях до начала разработки, а не исправляли расхождения в процессе.
Покупатель, оператор и администратор находятся в принципиально разных контекстах и с разной частотой использования продукта. Объединить их в один интерфейс означало бы компромисс для всех трёх. Каждый интерфейс проектировался под конкретную роль, её задачи и рабочий ритм.
Чат на WebSocket — это контракт между фронтендом и бэкендом. Если у каждого своя модель сообщения, ошибки неизбежны. Я описал структуру и типы всех входящих и исходящих WS-сообщений до начала разработки — чтобы команда договорилась об ожиданиях на этапе проектирования, а не в процессе дебаггинга.
Интерфейс покупателя
Главная проблема чата поддержки с точки зрения покупателя — открытое поле ввода в пустом диалоге. Человек не знает что написать, не понимает что можно спросить и нередко уходит не задав вопрос. Решение: структурированный вход в диалог через быстрые подсказки.
При открытии чата в формате диалога задаётся один вопрос: «Общий вопрос» или «По заказу». Если выбран заказ — показываются кнопки с номерами активных заказов покупателя. Если общий — сразу открывается поле ввода. Это ветвление сужает контекст до того как покупатель начнёт писать, что ускоряет маршрутизацию к нужному оператору на стороне системы.
Статусы сообщений (отправляется, доставлено, прочитано, ошибка) и уведомления об отсутствии соединения с автоматическим переподключением в фоне — покупатель всегда понимает что происходит, даже если связь нестабильна.
Интерфейс оператора
Оператор работает в двух потоках одновременно: диалоги с покупателями и служебные чаты с магазинами сети. Это принципиально разные контексты — смешивать их в одном списке значит постоянно создавать путаницу при переключении. Два таба сбоку (Покупатели / Магазины) полностью меняют список диалогов и контекст интерфейса.
Статус оператора (онлайн, перерыв, недоступен) управляется вручную, но при простое выше порога — автоматически переключается в «перерыв». Это защищает покупателей от назначения на оператора который фактически отсутствует, и снижает ручную работу по управлению статусами.
Переназначение диалога на другого оператора доступно прямо внутри интерфейса. Для каждого сообщения можно установить тематическую метку из выпадающего списка — это помогает при анализе обращений и маршрутизации.
Интерфейс администратора
Администратор работает не в реальном времени диалога, а на уровне управления потоком. Два ключевых инструмента: массовое переназначение диалогов и массовая рассылка сообщений.
Массовое переназначение решает сценарий инцидента: если оператор заболел или сменился, его открытые диалоги одним действием переходят к другому. Выбор нескольких диалогов чекбоксами и назначение на одного оператора — без необходимости открывать каждый по отдельности.
Массовая рассылка — инструмент для операционных инцидентов. Если в регионе проблемы с доставкой, администратор выбирает затронутых покупателей и отправляет им уведомление с извинениями и компенсацией. Это закрывает сценарий который раньше требовал ручной работы по каждому диалогу отдельно.
Рефакторинг и документация
Когда стало ясно, что архитектура не выдерживает рост нагрузки, я подключился к рефакторингу как фронтендер: перевёл фронтенд на Vite + Vue + TypeScript в монорепо под вынос в микросервисную архитектуру. Загрузка интерфейса сократилась с 60 секунд до 3 секунд.
Задокументировал структуру и типы всех API-запросов и WebSocket-сообщений — входящих и исходящих, поля, форматы, состояния. Документ стал единым источником правды для фронтенда и бэкенда на этапе интеграции. После рефакторинга снова добавлялись новые функции — уже поверх обновлённой архитектуры.
время загрузки интерфейса после рефакторинга на Vite + Vue + TypeScript монорепо
Продукт в проде — обрабатывает поток из сотен диалогов в день.
