Виктор Козлов01Odyssey: от аудитории до диалога
В Buro128 я собираю путь от первого интереса к дизайну или ремонту до конкретного объекта в работе. Начало этого пути — Odyssey, моя система привлечения клиентов. Здесь рядом находятся аудитории, источники, кампании, диалоги и CRM. Это позволяет разбирать не только отдельную заявку, но и то, из какого обращения она возникла.
Задача на этом этапе — найти подходящую аудиторию, подготовить обращение под её запрос и сохранить дальнейший разговор. Человеку, который ищет дизайн-проект, и человеку с уже готовым дизайном, которому нужен ремонт, нужны разные предложения. Я разделяю эти сценарии до передачи в продажи, чтобы менеджер начинал с подходящей услуги.
В CRM у сделки есть источник, объект, площадь, бюджет, ответственный и следующий шаг. Воронка Buro128 проходит через квалификацию, замер, расчёт и КП, дизайн, договор и передачу в исполнение. Когда карточка стоит на одном этапе, можно разобраться в конкретной причине: не хватает данных, не подготовлен расчёт или ждём решения клиента. Следующее действие получает своего исполнителя.
02Zoom + CRM: полная история клиента
По клиенту мы сохраняем полный контекст: от первоначального запроса до результатов коммуникации менеджера. Все звонки менеджеров пишем в Zoom. Переписка показывает, с чего начался разговор, а запись позволяет вернуться к тому, что человек действительно сказал на встрече: к ограничениям, вопросам, возражениям и договорённостям.
Дальше AI помогает превратить разговор в рабочий материал. Из расшифровки выделяем сведения об объекте, желаемый результат, бюджет, сроки, участников решения и обещанные действия. Важно отделять слова клиента от предположений менеджера. Если сумма обсуждалась как ориентир, в карточке она должна оставаться ориентиром; если вопрос не закрыт, он попадает в список уточнений.
Этот контекст нужен и перед следующим звонком, и при передаче другому специалисту. Например, если клиент уже объяснил, почему не подходит один вариант, не стоит предлагать его повторно. Менеджер видит результат предыдущей коммуникации, руководитель проекта получает исходные условия. Так сокращается повторный опрос, а подготовка начинается с уже собранной информации.
03Свой суфлёр: AI помогает прямо на звонке
Для менеджера я использую собственный софт-суфлёр. Это отдельное окно поверх конференции: система слушает собеседника, распознаёт речь и предлагает следующий ход по разговору. Менеджер получает подсказку во время звонка, когда она ещё может повлиять на его следующий вопрос или ответ.
Систему готовим на знаниях о продукте и сценарии встречи. В карточку звонка входят оффер, условия, границы услуги, термины и ответы на возражения. Благодаря этому подсказка опирается на конкретное предложение. Если клиент сомневается в составе работ, менеджеру нужен способ уточнить сомнение и объяснить соответствующую часть услуги, а не универсальная фраза из учебника продаж.
Технически суфлёр слушает звук собеседника, переводит фрагменты в текст и обращается к модели с контекстом звонка. Полную запись обеих сторон сохраняет Zoom. Это разные задачи: суфлёр помогает вести текущий разговор, запись нужна для последующего разбора и истории клиента.
Подсказку выбирает менеджер. Он может задать предложенный вопрос, изменить формулировку или не использовать её. Для меня польза такого инструмента — доступ к нужным знаниям в момент разговора: не приходится искать ответ в документах, переключая внимание с клиента на другую вкладку.
04AI + HQHub: из контекста в предложение
Перед консультацией мы собираем карточку проекта: объект, состояние ремонта, желаемый результат, бюджет, сроки и ограничения. Уже известные данные заполняем заранее. На встрече остаётся уточнить то, что влияет на предложение, вместо повторного заполнения имени и адреса.
AI помогает структурировать эти вводные, собрать черновик карточки и коммерческого предложения. Знания о продукте задают структуру документа, а клиентский контекст — его содержание. Состав работ и расчёт проверяет человек. Если исходных данных для сметы недостаточно, следующим шагом будет уточнение или замер; уверенный текст модели не заменяет отсутствующую информацию.
HQHub использую как рабочий хаб: там собраны документы, протоколы созвонов, решения и ссылки на системы проекта. Материал можно найти по своей задаче — подготовка встречи, работа с объектом, развитие продукта. Для команды это сокращает поиск нужной версии и помогает продолжать работу по зафиксированным договорённостям.
На выходе нужен материал, по которому клиент может принять решение: что предлагаем, что входит в работу, что требуется уточнить и как двигаться дальше. Я проверяю файл, ссылки и читаемость с телефона, прежде чем считать подготовку законченной.
05ERP: передача продажи в исполнение
После продажи начинается другой процесс — организация работы по объекту. В ERP Buro128 передача в исполнение сделана отдельным действием: выбираем руководителя проекта и создаём объект из данных сделки. Клиент, площадь, выбранный формат и бюджет переходят в операционную карточку без повторного ввода.
В объекте есть этапы, плановые сроки, чек-листы, коммуникации и экономика: сумма договора, расходы, поступления. Первый этап включает принятую карточку клиента, назначение выезда и подключение к приложению. Следом идут обследование и замеры. Такой переход задаёт руководителю конкретную начальную работу.
Дальше каждый этап нужно завершить по содержанию: проверить пункты, зафиксировать результат и определить, что можно начинать после него. Если работа остановилась, полезно видеть недостающий замер, согласование или материал, а не только общий статус «в процессе». Это помогает адресовать задачу тому, от кого зависит продолжение.
Клиентское приложение развиваем рядом с этим контуром: объект, бюджет и план ремонта должны быть понятны самому клиенту. Команда при этом ведёт операционные детали в ERP. Мы продолжаем связывать эти части, сохраняя один смысл проекта при переходе между интерфейсами.
06Pult: из договорённости в задачу
В Telegram идёт рабочее общение, в HQHub хранится контекст, а в Pult фиксируются действия. Для задачи мне нужны результат, ответственный, срок и критерий готовности. AI помогает извлечь такую постановку из обсуждения, но решение назначить работу и принять её остаётся за мной.
Например, после звонка может потребоваться КП. В поручение попадает, по какой карточке его собираем, что клиенту важно увидеть, какие вводные ещё проверяем и к какому контакту нужен документ. Следующий исполнитель получает содержание задачи вместе с её назначением, без отдельного объяснения всей истории.
Pult позволяет смотреть задачи списком или на доске, разделять активную работу и бэклог, видеть исполнителя, статус и срок. Я могу проверить, что сейчас двигается, что ожидает проверки и где требуется моё решение. Так обсуждение не заканчивается сообщением, которое постепенно уезжает вверх в чате.
Приёмка тоже конкретная: документ должен быть доступен получателю, опубликованная страница — показывать нужную версию, действие в приложении — сохранять результат. Это заранее входит в критерий готовности. Исполнитель понимает, что проверить, а мне проще принять работу без нового круга уточнений.
07Codex и собственный AI-слой Buro128
Когда рабочий сценарий понятен, я могу изменить инструмент под него через Codex. Описываю входные данные, действие человека и результат, который должен сохраниться. Получаю изменения в коде, проверяю сценарий и выпускаю версию через GitHub. Так своё решение можно довести до интерфейса в одном рабочем цикле.
Это важно, потому что процесс уточняется после реального использования. Может понадобиться другое поле в карточке, более понятная передача объекта или удобный просмотр материалов. Вместо ожидания большой перестройки я могу внести конкретное изменение и проверить его на том шаге, ради которого оно появилось.
Для клиентского продукта мы разрабатываем собственный AI-слой Buro128. Его задача — работать с объектом целиком: учитывать параметры помещения, пожелания клиента, бюджет и методологию ремонта, связывать визуальные варианты с дальнейшими решениями и планом действий. Я вижу развитие этого слоя как сопровождение человека от замысла до реализации, с сохранением контекста на всём пути.
Сейчас подключаем модели через OpenRouter и проверяем отдельные функции. По мере разработки хотим объединить работу с исходными данными, варианты решений и проектную логику в собственном продукте. Тогда выбранная идея сможет продолжаться в плане ремонта, а новые вводные — учитываться в следующих рекомендациях. К этому мы строим архитектуру: свой слой знаний и процессов поверх возможностей моделей.
В результате я строю систему вокруг последовательных переходов: аудитория становится диалогом, разговор — сохранённым контекстом, контекст — предложением, продажа — объектом, договорённость — задачей. На каждом переходе понятно, какие данные нужны, кто продолжает работу и что должно получиться. Именно за счёт сохранённой информации и убранных повторных действий мы быстрее доходим до следующего результата.
Проект: Buro128 · Приложение Buro128