Как LLM помогает превратить разговор с клиентом в готовый бриф за 20 минут: кейс на примере веб-проектов

Команда «ИнтерЛабс» заменила классическое брифование управляемым процессом. Запись встречи очищается и размечается по ролям, данные сайта анализируются отдельно, затем LLM собирает текстовый бриф, который проверяет менеджер и переводит в структурированный JSON. В статье разберем устройство этого процесса, его ограничения и практический эффект.

Почему классическое брифование перестало работать

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

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

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

Команда «ИнтерЛабс» решила изменить эту механику: не просить клиента заполнять анкету, а получать нужную информацию во время обычного разговора. Так появился процесс, в котором после 15–20-минутной встречи менеджер получает готовый проектный бриф, проверяет его, при необходимости корректирует и направляет клиенту уже структурированный документ.

Новый подход: сначала разговор, потом бриф

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

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

Чтобы не зависеть только от опыта конкретного сотрудника, команда проанализировала 60 проектов за последние два года: готовые брифы, технические задания, коммерческие предложения и проектные материалы. На этой основе были выделены 14 обязательных блоков информации, которые нужно собрать независимо от типа веб-проекта.

«Это не сценарий разговора и не последовательный список вопросов», — подчеркивает руководитель клиентского сервиса «ИнтерЛабс» Алексей Рубель. Менеджер обсуждает проект, задачи, текущие проблемы, ожидания, ограничения, примеры, конкурентов, структуру сайта и приоритеты. При этом он понимает, какие информационные блоки должны быть закрыты.

Во время встречи менеджер:

• управляет ходом разговора;
• задает уточняющие вопросы;
• возвращается к темам при необходимости;
• отмечает вопросы, которые требуют дополнительного согласования.

Оптимальная продолжительность брифования — 15–20 минут, максимум до 30 минут. Практика показала, что этого достаточно для получения качественных исходных данных.

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

Почему это не просто «отправить текст в GPT»

На первый взгляд есть запись встречи, транскрипция и LLM в подписке за 20 долларов — можно попросить модель сделать бриф. Однако на практике такой результат нестабилен и плохо воспроизводим. Модель смешивает слова клиента и менеджера, принимает гипотезы за требования, додумывает детали, а итог остается в «чате менеджера» и плохо подходит для дальнейшего использования.

Поэтому команда отказалась от подхода «вот текст — сделай документ» и построила процесс, в котором каждый этап можно проверить, исправить и запустить повторно. Нужен был не разовый промпт, а воспроизводимый конвейер: с понятным происхождением данных, контролем изменений и возможностью использовать результат дальше.

Какие источники данных разделили

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

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

Если все объединить в неразмеченный текст, модель начинает работать с информационной «кашей». Разделение источников позволяет управлять качеством, ведь модель понимает, где требование клиента, где предложение менеджера, где факт с сайта, а где экспертное уточнение.

Как устроен процесс обработки брифа

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

Шаг 1. Подготовка транскрипции

Встреча может проходить по SIP-телефонии, в Zoom или Яндекс Телемосте. Запись сохраняется, а расшифровка выполняется в MacWhisper с использованием локальной модели Whisper Large v3 Turbo.

Полученная транскрипция сначала проходит программную обработку:

• удаляются тайм-коды;
• очищаются служебные данные;
• объединяются последовательные реплики;
• определяются роли участников;
• удаляются персональные данные;
• реплики размечаются как «Менеджер» и «Клиент».

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

Шаг 2. Анализ сайта

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

• структура сайта;
• меню и навигация;
• разделы;
• каталог;
• формы;
• контакты;
• основные CTA;
• цветовая палитра.

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

Шаг 3. Синтез текстового брифа

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

Модель получает задачу использовать только подтвержденные факты и сформировать проектный бриф фиксированной структуры. На выходе получается текстовый бриф из 14 разделов в формате plain text. Такой формат удобен для проверки: в визуальном редакторе менеджер быстро видит пропуски, спорные формулировки, ошибки и места, которые нужно уточнить.

Шаг 4. Проверка менеджером

Команда отказалась от полностью автоматической генерации итоговых документов. Каждый промежуточный результат проверяется человеком — по принципу Human in the Loop. Менеджер может:

• исправить данные анализа сайта;
• дополнить текстовый бриф;
• удалить ошибки;
• уточнить формулировки;
• добавить новую информацию после разговора.

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

Шаг 5. Перевод текстового брифа в JSON

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

После проверки текстовый бриф преобразуется в JSON с жестким контрактом. Именно JSON становится основным источником данных проекта. Он содержит:

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

В дальнейшем из JSON можно формировать визуальный бриф, PDF для клиента, КП, ТЗ, структуру прототипа, список модулей, вопросы для согласования и основу для передачи проекта в производство. Структурирование данных оказалось не менее важным, чем генерация текста, выбор модели или промпты.

Шаг 6. Формирование визуального брифа

После нормализации данных система формирует экранный визуальный бриф и PDF-документ. В нем собраны:

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

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

Организация рабочего процесса в студии

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

• запись разговора;
• транскрипция;
• анализ сайта;
• текстовый бриф;
• структурированный JSON;
• PDF;
• история изменений.

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

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

Какие эффекты дает внедрение

После внедрения нового процесса практически каждый разговор с клиентом заканчивается готовым брифом. Менеджеру больше не приходится отправлять форму и ждать, пока заказчик найдет время ее заполнить. Уже через 20–30 минут после встречи клиент получает структурированный документ, который можно проверить, уточнить и использовать в дальнейшей работе.

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

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

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