AI-copilot для клиентского сервиса

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

• Администраторы не всегда успевают отвечать клиентам вовремя.
• Подготовка качественного ответа занимает много времени.
• Качество сильно зависит от каждого конкретного сотрудника.
• Стиль и уровень коммуникации у всех администраторов разный.

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

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

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

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

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

Я изучил ниши, конкурентов и их аватары. Через Keys.so, Topvisor и Wordstat собрал и кластеризовал поисковые запросы, после чего подготовил несколько версий позиционирования лендинга и запустил небольшую кампанию в Яндекс Директе.

Для этого я составил список ключевых гипотез и приоритизировал их по трём критериям. В качестве оценки использовал условные единицы от 1 до 3:

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

На рынке уже было много чат-ботов и AI-инструментов для генерации текста. Поэтому само наличие LLM не могло быть преимуществом.

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

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

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

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

Например, конфигурацию новых ассистентов я выполнял вручную через Swagger/Postman, а состояние интеграций и ошибки отслеживал через Grafana. Это увеличивало объём ручной работы внутри команды, но позволяло не тратить время разработки на административные интерфейсы до подтверждения необходимости продукта.

После определения скоуп я декомпозировал MVP на эпики и задачи и синхронизировал их с CEO и backend-разработчиком. Работу вели двухнедельными спринтами с регулярными командными синками.

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

В первой версии пользователь авторизовывался в сервисе, создавал кабинет, выбирал рабочую зону и подключал Telegram. На старте была доступна одна рабочая зона — «Клиентский сервис», внутри которой администратор мог вести переписку с клиентами и получать AI-подсказки для ответа.

Сам пользователь пока не мог самостоятельно создавать ассистента. Эту я делал вручную через Swagger на основе отдельной MD-инструкции под конкретный бизнес.

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

Формально мы сократили время на подготовку ответа, но часть этой экономии терялась на этапе проверки результата. Стало понятно, что одного качественного текста недостаточно — пользователю ещё нужно научиться доверять системе.

Чтобы понять, откуда возникает недоверие к ответу, я провёл очное юзабилити-тестирование прямо в клинике и наблюдал, как администратор работает с продуктом в обычном рабочем контексте.

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

Первая итерация подтвердила сам сценарий: AI действительно мог снять часть ручной работы с администратора. Но одновременно выявила новый класс задач — доверие к генерации, качество контекста и прозрачность поведения ассистента.

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

Вместо отдельных постановок для дизайна, frontend и backend я собирал одну расширенную спецификацию. В ней объединял пользовательский сценарий, бизнес-логику, данные, состояния интерфейса и технические ограничения.

На её основе сначала проверял основной flow, а затем вместе с Codex и Figma MCP доводил сценарий непосредственно в коде: прорабатывал состояния, реальные данные, адаптивность и компонентную логику.

Во второй итерации я перенёс основной источник UI-компонентов в код. За основу взял shadcn/ui, адаптировал компоненты под визуальный язык продукта и собрал внутреннюю песочницу со всеми состояниями.

Я пересобрал основной сценарий генерации ответа. В первой версии AI-текст выглядел почти так же, как сообщение, набранное вручную, а действие отправки было визуально неотличимо от обычных чатов. Это усиливало неуверенность пользователя перед отправкой.

В новой версии я сделал AI-ответ отдельным состоянием интерфейса и добавил явные действия: принять, отредактировать или перегенерировать ответ. Это одновременно упростило пользовательский flow и лучше соответствовало новой логике MCP-роутинга.

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

За время проекта я прошёл полный цикл создания продукта: от исследования проблемы и первых гипотез до MVP, пилотов и второй версии. Параллельно выстроил AI-first delivery-процесс, в котором дизайн, документация и работа с кодом стали частью одного процесса.

• За год прошли путь от идеи до первых платящих клиентов со средней MRR более 14 т.р.
• Сократили команду разработки в 2 раза, при этом ускорив delivery-процесс вдвое.
• Прошли в шорт-лист AltaIR Capital, инвестировавшего в Miro, Deel и другие компании.