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; генерация сторис через ArchShot; деплой на Vercel. Помимо PDF появилась генерация сторис (слайды для TG/IG под проект).

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

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

Ownership сопровождения после приёмки — у меня (мелкие доработки); развитие под партнёров — в работе.

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

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

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

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

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

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

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