На карте
Я собрал внутри Codex демонстрационный плагин для работы с клиентами. В нём можно выбрать клиента и сделку, посмотреть встречи, документы и задачи, а из карточки — передать помощнику поручение. Отдельно мы проверили сценарий выставления счёта через API Точка Банка в тестовой среде.
Для демонстрации мы со Степаном, моим помощником в Codex, подготовили восемь вымышленных клиентов, сделки и переписку. На этом примере я проверяю идею: можно ли собрать собственное рабочее место прямо внутри ИИ-среды, которой я уже пользуюсь.
Я хочу довести этот плагин до повседневного применения. Для рабочей версии отдельно предстоит определить хранение данных, доступы и состав информации, которую получает ИИ. Здесь покажу уже собранное демо, решения по ходу разработки и то, почему считаю такой способ создания инструментов важным сдвигом.
От огромной CRM к своему инструменту внутри Codex
Для меня за этой сборкой стоит гораздо более сильная перемена. Я вижу, как меняется сам способ получать рабочее программное обеспечение.
Ещё недавно привычным решением была большая SaaS CRM с огромным количеством функций. Хороший пример — Битрикс24, вокруг которого выросла целая экосистема компаний по внедрению и настройке. Покупкой доступа дело не заканчивалось: систему нужно было приспособить под свои процессы, связать с другими сервисами и научиться в ней работать. Настройка под себя могла стоить больших денег. У меня этот подход вызывал ощущение продукта «для всех и ни для кого»: возможностей много, а нужный тебе способ работы ещё предстоит из них собрать.
Потом пришёл вайбкодинг и возможность быстро собирать собственные CRM под конкретную задачу. Но возможность написать приложение ещё не гарантирует, что с ним будет удобно работать каждый день. Свою сборку тоже нужно проверять, исправлять и поддерживать. Качество результата может быть очень разным.
А сейчас я вижу следующий переход. Я уже нахожусь в Codex, работаю здесь с ИИ и могу прямо внутри этой среды быстро собрать ровно то, что мне необходимо, в виде плагина. Мне доступны возможности Codex, а клиентские экраны, действия и правила я добавляю под свой процесс. Замечаю неудобство — объясняю его помощнику и меняю инструмент по ходу работы.
Если эта модель окажется удобной в повседневной работе, для моего сценария может отпасть потребность в отдельной CRM. Вместе с ней уйдёт часть вопросов: какую систему выбрать, как подключить к ней агентов и как перенести в неё уже сложившуюся работу с ИИ. Клиентский инструмент появляется там, где я и так работаю.
Банк, хранилище файлов и база клиентских записей при этом всё равно нужны. Плагин связывает их с разговором и интерфейсом внутри Codex. Мне интересно проверить, насколько далеко можно пройти с такой конструкцией без отдельного приложения, вокруг которого приходится строить весь рабочий день.
Я считаю это мощнейшим сдвигом. По моим ощущениям, переход от массовой сборки собственных CRM к таким инструментам внутри ИИ-среды происходит буквально за несколько месяцев. Это моя личная оценка того, куда движется рынок. Демо позволяет проверить эту мысль на конкретном процессе.
Почему я сразу захотел попробовать
Когда я впервые увидел плагины OpenAI, сразу захотел собрать свой. Я много работаю в Codex, постоянно что-то к нему подключаю и проверяю новые возможности на собственных задачах. На вебинаре в закрытом чате «Перезагрузка» я описал свою реакцию довольно точно:
«Когда я увидел вообще концепцию плагинов, меня вот прям, не знаю, прострелило».
Клиентская работа хорошо подходит для такого эксперимента. У клиента есть сделки, у сделки — исходные материалы, встречи, документы, расчёты и задачи. Между ними постоянно приходится переключаться. Хотелось собрать понятный способ видеть общую ситуацию и продолжать работу с ИИ рядом.
Здесь полезно уточнить хронологию. Плагины существовали до осеннего DevDay. А 29 сентября 2026 года OpenAI представила расширения плагинов с местом в боковой панели и интерактивными экранами. Именно этот шаг сделал идею собственного рабочего места особенно наглядной.
В коротком разборе плагинов я уже обещал показать свою сборку подробнее. На вебинаре сформулировал их смысл по-простому: «По сути, это приложение внутри кодекса». В один пакет можно собрать навыки, инструменты подключения к данным и интерфейс для конкретной работы.
Меня заинтересовала возможность сделать такой пакет под собственную последовательность действий. Объяснить помощнику, как я принимаю запрос, готовлю встречу, уточняю условия и проверяю результат. А затем посмотреть, какие части этого процесса действительно удобно собрать вместе.
В центре оказался клиент с несколькими сделками
Первая потребность очень приземлённая: быстро понять, что сейчас происходит с конкретным человеком или компанией.
Один клиент может прийти на консультацию, потом заказать внедрение, а через некоторое время вернуться за обучением команды. Если смешать всё в одной карточке, непонятно, к чему относится договор, за что предполагается оплата и какую встречу мы готовим.
Поэтому мы разделили клиента и сделку. У клиента остаются контакты и общая история отношений. У каждой сделки — свой предмет работы, сумма и следующий шаг. Документы и расчёты можно привязать к нужной сделке.
На первом экране я вижу клиентов и могу найти нужного по имени или компании. Слева находятся фильтры, в строке клиента — контакт, количество сделок и ближайшее действие. Из списка открывается отдельная карточка.
В карточке можно посмотреть все сделки клиента или выбрать одну. Это определяет, с каким контекстом продолжится работа. Мне не нужно каждый раз заново писать, о каком проекте идёт речь.
Что находится внутри плагина
В нашем случае у плагина есть несколько взаимосвязанных частей.
Навыки объясняют, как выполнять работу. Как принять запрос, подготовить консультацию, разобрать встречу, собрать коммерческое предложение или договор. Здесь живут требования к источникам, последовательность действий и признаки готового результата.
Инструменты дают доступ к данным и операциям. Для этого у плагина есть собственный MCP-сервер — программный интерфейс, через который агент обращается к предусмотренным функциям. В демонстрации интерфейса используются вымышленные записи. Банковскую интеграцию мы проверяем отдельно через API Точки в песочнице.
Интерфейс помогает ориентироваться. Он показывает состояние клиента и сделки, открывает нужный раздел и передаёт поручение в чат. Сложная работа с текстом продолжается в разговоре: там можно объяснить нюанс, уточнить условие и проверить подготовленный документ.
Это разделение оказалось удобным. Карточка отвечает на вопрос «где мы сейчас», а в чате я объясняю, что хочу сделать дальше. Когда нажимаю «Подготовить встречу» или «Договор», агент получает поручение в контексте выбранной сделки. Наличие кнопки само по себе ещё не означает, что документ уже создан или отправлен.
Для рабочей версии нужно будет настроить каждое подключение и определить, какие операции доступны помощнику. В демо можно сначала проверить логику взаимодействия: что человек выбирает на экране, какое поручение попадает в чат и какой результат он ожидает увидеть.
Один путь клиента, даже если работа идёт в разных чатах
Я строю сценарий вокруг сохранённого состояния клиента и сделки. Входящий запрос может быть текстом, файлом или скриншотом переписки. Его нужно связать с клиентом, сохранить исходные материалы и зафиксировать следующий шаг.
Дальше появляется встреча: подготовка вопросов, обсуждение, решения, открытые темы. По согласованным условиям можно переходить к предложению, договору и счёту. Каждый результат должен оставаться связанным с той же сделкой.
Мне важно, чтобы этот путь можно было продолжать в разных чатах. В одном разобрать запрос, в другом подготовить встречу, позже вернуться к договору. Для этого новый разговор должен получать актуальные записи и материалы, сохранённые после предыдущего этапа. Сам по себе новый чат всю историю клиента не знает.
В демо хорошо видна структура такого процесса: клиент, выбранная сделка, связанные встречи и задачи. Полный переход между чатами с сохранением результатов в рабочем хранилище — один из сценариев, который предстоит проверить перед повседневным использованием.
Для задач мы сохранили различие между предложением агента и подтверждённой договорённостью. Если из обсуждения следует «хорошо бы подготовить материалы», этого недостаточно, чтобы объявить конкретного человека ответственным к определённой дате.
В карточке задачи видны исполнитель, срок и подтверждение. Отсутствующие договорённости нужно уточнить. Иначе красивый список поручений будет создавать ложное ощущение порядка.
Документы и тестовый счёт через API Точка Банка
В разделе документов я хочу видеть материалы по выбранной сделке: исходный запрос, предложение, договор и приложения. У каждого документа должно быть понятное состояние и ссылка на сам файл.
Демо показывает, как это выглядит в интерфейсе. В примере есть предложение, договор на согласовании и исходные материалы команды. Это подготовленный демонстрационный набор.
Следующий этап этого сценария — выставление счёта. Для него мы подключили API Точка Банка и проверили интеграцию в банковской песочнице. API позволяет программе передать банку предусмотренный запрос и получить ответ, который затем можно связать со сделкой.
Для меня это существенная часть эксперимента. Выставление счёта — обычный шаг в работе ИП и компаний. Интересно провести его из того же контекста, где уже обсуждены задача, условия и документы. Поручение должно опираться на выбранную сделку и согласованные реквизиты.
У тестовой среды есть особенность: PDF счёта может быть фиксированным образцом на 1 234,56 ₽, даже если в демонстрационной сделке указана другая сумма. Поэтому на экране есть отдельное предупреждение. Такой PDF подтверждает работу с тестовым ответом банка; реальным счётом клиенту он не является.
В интерфейсе также показаны сумма, поступления и остаток. Важно сохранять различие между подготовленным счётом и подтверждённой оплатой. В демо поступление смоделировано. Реальную оплату нужно подтверждать банковскими данными.
На вебинаре я обсуждал и дальнейшую автоматизацию: система сама замечает поступление и помогает продолжить процесс. Это направление развития. Непрерывное автоматическое наблюдение за оплатами в этой версии я пока не называю готовой функцией.
Как мы дорабатывали демо
Самое интересное в этом опыте для меня — способ разработки. Я объяснял, что хочу видеть и делать, Степан собирал очередной вариант, а я смотрел на него как человек, которому потом с этим работать.
На вебинаре я сказал: «Можно прямо в процессе работы с клиентом дорабатывать плагин». В этой мысли для меня и заключается привлекательность подхода: инструмент можно уточнять по мере того, как становится понятна потребность.
Мы отдельно разбирались с тем, как показывать несколько сделок одного клиента. Дорабатывали переход из карточки в чат. Перестраивали экран, чтобы контакты и задачи оставались рядом с основной работой. В конце я попросил сделать фон почти белым и добавить собственную иконку плагина.
В разговоре я оценил первоначальную сборку словами «за пару часов». Здесь я бы разделил первый работающий вариант и дальнейшую доводку. После прототипа остаются проверки, обработка неудобных случаев и изменения интерфейса. Одна красивая демонстрация эту работу не отменяет.
Демонстрационный режим оказался полезен и для самой разработки. На вымышленных клиентах можно проверить разные состояния: несколько сделок, встречу в прошлом и будущем, предложенную задачу, документ на согласовании, тестовый расчёт. Так проще замечать, где интерфейс помогает, а где заставляет додумывать.
Где будет храниться результат
На вебинаре возник вопрос, что будет с работой, если потеряется чат. Мой принцип здесь давно определился:
«Я в чате веду работу, а когда у меня появляется какой-то результат, а он появляется там очень часто, я его фиксирую, он хранится отдельно».
Для клиентского процесса это особенно полезно. В разговоре мы можем перебрать несколько формулировок предложения, спорить об объёме работ и уточнять вопросы. Продолжать сделку нужно по зафиксированным решениям и актуальным документам.
Для будущей рабочей версии я рассматриваю хранение в российском регионе: базу PostgreSQL для клиентов, сделок и задач, объектное хранилище — для файлов, скриншотов и документов. Один из вариантов — Yandex Cloud. Это план следующего этапа; такое хранилище в рамках показанного демо ещё не развёрнуто.
Отдельно нужно определить, какие сведения получает облачная ИИ-модель, кому доступны материалы и как устроены подключения. Размещение базы в России само по себе не решает все вопросы обработки данных. Поэтому для этой демонстрации мы используем вымышленные записи, а переход к рабочим данным требует отдельной проверки.
Как начать похожую сборку для себя
Я бы начал с одного повторяющегося сценария. Например: подготовиться к встрече с клиентом, провести её и сохранить проверенный результат. На таком отрезке сразу видно, каких данных не хватает и какие действия приходится повторять.
Сначала стоит описать последовательность работы и желаемый результат. Затем собрать небольшой прототип на вымышленных данных. Подключение рабочих систем имеет смысл после того, как понятны нужные операции, хранение и доступы.
Вот запрос, с которого можно начать разговор с Codex.
Промпт:
Помоги мне спроектировать личный плагин Codex для одного повторяющегося рабочего процесса.
Мой процесс: [опишите, что вы регулярно делаете].
Основная трудность: [что приходится искать, повторять или переносить вручную].
Нужный результат: [что должно появиться после выполнения задачи].
Сначала используй только описание этой задачи. Кратко восстанови последовательность работы и назови существенные неизвестные.
Предложи минимальный состав плагина: необходимые навыки, инструменты доступа к данным и экраны. Для каждой части объясни, какую конкретную трудность она устраняет. Проверь актуальную официальную документацию по плагинам.
Раздели чтение, подготовку результата и внешние действия. Укажи, где требуется моё решение. Не подключай рабочие сервисы и ничего в них не меняй на этом этапе. Для банковского сценария используй только тестовую среду и явно обозначай её результаты.
Подготовь план первого прототипа на вымышленных клиентах, сделках и документах и способ проверить один полный сценарий. Отдельно предложи хранение результатов и способ продолжать работу в другом чате. Подключение реальных данных вынеси в следующий этап.Мой плагин сейчас интересен мне именно как проверка такого подхода. Уже есть демонстрационный интерфейс, связанная структура клиента и сделки, входы в рабочие сценарии и проверка банковского API в песочнице. Впереди — рабочее хранение, доступы и проверка всего пути на согласованном наборе данных.
Именно это меня зацепило в плагинах: я могу постепенно собирать инструмент вокруг своих задач, видеть промежуточный результат и обсуждать изменения с тем же помощником, с которым работаю каждый день.
Следующий шаг
Перед собственной сборкой полезно решить, какую часть чужого опыта вы хотите перенести. В статье «Почему я не предлагаю клиентам скопировать мою систему» я разбираю, как выбрать один полезный принцип и проверить его в своих условиях.
На консультации можно разобрать ваш повторяющийся процесс и выбрать небольшой сценарий для первой проверки.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov
