PM по ИИ и автоматизации процессов

Три сотрудника отдела качества не покрывали поток ~120 звонков в день. Физически невозможно прослушивать и оценивать все разговоры по критериям. Оценка качества страдала, покрытие дырявое. Нужна была системная оценка, без выборочной прослушки.

Заказчик и спонсор: CEO. Согласование требований шло сквозь весь цикл: первичная постановка, потом поддержка контура оценки (качество, процесс, критерии).

Вёл проект end-to-end как PM/продукт: требования, правила валидации и оценки, презентации и демо, внедрение и UX для сотрудника качества. Код агентов не мой. Ownership у меня на процессе и правилах.

ИИ-агенты взяли как более дешёвый путь: сократить ресурсы качества, не раздувать штат контролёров, и параллельно закрыть полное покрытие оценки. Расширение отдела отрезали как основной сценарий. Из звонка сразу видны договорённости и summary. Распознаются следующий шаг и параметры квалификации; если есть, обновляются.

Контур: требования → правила и acceptance criteria → согласование → демо → внедрение → поддержка. После запуска ownership сопровождения передан.

Сложность: разные критерии оценки у отделов, разные типы звонков и долгое согласование типов, по которым раньше не было классификации оценки.

Сопровождение у оставшегося сотрудника отдела качества (мониторинг выполнения). После передачи мой ownership уже не основной.

Legacy CRM старше 10 лет, самописная, с кучей legacy. Масштабировать тяжело, морально устарела. «Просто доработать» не вариант. Нужна была новая воронка: понятный контур продаж без регресса функционала.

Спонсор: CEO. Главные стейкхолдеры: отдел продаж в целом.

Как PM/продукт опирался на знание текущей CRM и её болей. Анализировал, прорабатывал требования и правила так, чтобы новая воронка была удобнее и понятнее. Функционал перенести (± улучшить), без регресса, чтобы переход был ясным. Всю разработку и дизайн не приписываю.

Восемь этапов - классическая воронка продаж. LLM-валидации дают гибкую кастомизацию правил (в том числе 42 правила архивации в Markdown). На следующих воронках они нужны сильнее.

Альтернативу «чистая доработка старой CRM» отвергли из-за возраста и legacy. Сейчас в работе: архивация с ИИ, автодвижение по воронке, другие воронки для других отделов продаж.

Внедрение на ~50 сотрудников постепенно: сначала те, кто раньше почти не работал в CRM → feedback → доработки → затем остальные отделы по частям.

Риски: галлюцинации LLM - ложные или пропущенные проверки; сопротивление новой CRM («непонятно / неприятно», желание остаться на старой).

Развитие (архивация с ИИ, автодвижение, другие воронки) ещё в работе. Отдельного «день-за-днём» owner сверх этого нет.

Менеджеры писали в отдел продукта и просили справочные материалы по проекту. Ручной труд без персонализации: часто просто материалы застройщика, без «подставки» под конкретного клиента. Time-to-value: 1–2 дня.

Заказчик: CEO.

Спроектировал решение с нуля как PM/продукт по постановке. На сопровождение принял уже после разработки. Небольшие правки и доработки делаю сам (в том числе с Cursor). На всю исходную разработку не претендую.

Стек на публичном уровне: PDFMonkey; LLM через OpenRouter; генерация сторис через Orshot; деплой на Vercel. Помимо PDF появилась генерация сторис (слайды для TG/IG под проект).

После разработки принял сервис на сопровождение: мелкие доработки и развитие. Расширение на партнёров-аффилиатов: часть уже внедрена. Сами генерируют PDF/сторис и передают готовых клиентов.

Неудобство → низкий adoption; долгая генерация; устаревшая информация в подборках. Актуальность данных закрывается связкой с импортами застройщиков. Главный риск по сути: «не будут пользоваться». Если пользуются - эффект сильный.

После приёмки сопровождение у меня (мелкие доработки). Развитие под партнёров ещё в работе.

Много застройщиков, разные форматы каталогов. Сотрудник вручную создавал объекты на сайте и обновлял статусы (продажи, брони). Дорого по времени, легко отставать от реальности.

Внутренний заказчик и пользователи процесса: отдел продукта и каталога (раньше делали вручную). Партнёры-застройщики дают форматы данных.

Как PM вёл проект. Сейчас сам подключаю новых застройщиков и пишу промпты перевода их формата в наш. Регулярные доработки по запросу продукта («новый партнёр» / «добавить объём по существующему»).

Каталог = проект + юниты. Загрузка → конверт в наш формат → сотрудник проверяет распознавание и новые юниты → сохраняет. Не магия без контроля: human-in-the-loop на финале.

Регулярный контур: продукт сообщает о партнёре → промпт/маппинг формата → подключение. Отдельного спринта раз в квартал нет. Доработки идут по мере партнёров.

Риски: не покрыть всех партнёров / слишком разные форматы → много времени на подгонку промпта; галлюцинации модели → некорректные данные при сохранении; процесс займёт много времени и не ускорит работу.

Сопровождение и подключение новых у меня (промпты, форматы).