Workeron — разбор глазами Product Manager

Линза: ПРОДАКТ-МЕНЕДЖЕР. Атомарный разбор продукта Workeron (workeron.ai + workeron.agency) со стороны PM. Дата анализа: 30 июня 2026. Подготовлено для кандидата. Опирается на артефакты 01_company_profile_model.md, 02_roadmap_whats_next.md, 03_major_competitors.md, 04_minor_competitors.md + точечные WebSearch.

Легенда честности: [ФАКТ] — подтверждено источником (URL + дата); [МАРКЕТИНГ] — их собственное заявление, независимо не подтверждено; [ИНТЕРПРЕТАЦИЯ] — мой аналитический вывод как PM. Где данных нет — пишу «публичных данных не найдено».

Ключевая оговорка PM: Workeron — компания самой ранней стадии (founded 2026, 2–10 чел., pre-seed, нулевой публичный трекшен). Поэтому корректный продуктовый разбор — это разбор гипотез и дизайн-решений, а не разбор работающей метрик-машины. Я отделяю «что заявлено» от «что реально можно измерить».

0. TL;DR (для занятого читателя)

• Продукт — не SaaS, а productized DFY-сервис: один промпт в Telegram/WhatsApp/email → агент исполняет multi-step действия в 12+ инструментах клиента. Цена — разовый $1,900, без подписки, без lock-in. [ФАКТ — workeron.ai]
• JTBD один и сильный: «снять с founder/CEO операционную рутину, не заставляя его осваивать ещё один инструмент». Канал (мессенджер) и DFY-сетап — прямое попадание в этот JTBD. [ИНТЕРПРЕТАЦИЯ]
• Главная продуктовая дыра — не фичи, а надёжность и доверие к исполнению. Агент, который делает (не говорит), в чужом Gmail/Stripe/HubSpot — это риск необратимых ошибок. Smart-approval заявлен, но reversibility/undo/audit/error-recovery в публичных материалах не раскрыты. Это #1 продуктовый риск. [ИНТЕРПРЕТАЦИЯ]
• Метрический парадокс one-time-модели: при разовом $1,900 без подписки у продукта нет встроенного retention-сигнала (нет логина-как-обязательства, нет MRR). Активация и time-to-first-value критичны, а удержание измеряется суррогатами (частота задач, ретейнеры). [ИНТЕРПРЕТАЦИЯ]
• Discovery почти не виден: все «кейсы» — внутренние прототипы, отзывы анонимны, нет ни одного публичного клиентского сигнала. Для PM это значит: продукт строится на гипотезах, не на валидированных инсайтах. [ФАКТ + ИНТЕРПРЕТАЦИЯ]
• Фиче-гэпы против конкурентов (Cyndra, Bond, Lindy, Martin) — реальны, но вторичны. Конкуренты обгоняют по охвату каналов, по визибилити-фичам (Bond) и по self-serve-конструктору (Lindy). Workeron отыгрывается сервисом и ценой, а не продуктом.
• 5 продуктовых рекомендаций ниже приоритизированы по RICE-логике (на словах): топ-1 — observability/reversibility слой (trust), топ-2 — инструментирование activation/TTFV, топ-3 — discovery-движок (1 публичный кейс с цифрами).

1. JTBD и сегменты пользователей

1.1. Главный Job-To-Be-Done

[ИНТЕРПРЕТАЦИЯ на базе позиционирования] Слоган «Say it once. Consider it done.» и обещание «экономия 10+ часов/неделю» формулируют JTBD почти дословно:

«Когда я (founder/CEO/COO) тону в операционной рутине между десятком инструментов, я хочу делегировать многошаговые задачи одной фразой в мессенджере, чтобы вернуть себе время на стратегию — и при этом НЕ осваивать ещё один дашборд и не нанимать ассистента.»

Это разложимо на три под-job'а:

1. Functional job: исполнить задачу across-tools (триаж инбокса, апдейт CRM, постановка задач, подготовка к встрече). [МАРКЕТИНГ — workeron.ai: «Inbox-zero by 9am», «workflow chains»]
2. Emotional job: снять тревогу «что-то важное проваливается между инструментами» (memory: «never forgets a thread»). [МАРКЕТИНГ]
3. Social job: «я founder, у которого есть chief-of-staff» — статус и рычаг без найма человека. [ИНТЕРПРЕТАЦИЯ]

Сила JTBD как PM-оценка: job реальный, болезненный, с понятной готовностью платить (рынок EA-стартапов это подтверждает — Bond, Martin, Cora, Lindy все бьют в него). Workeron выбрал самый ленивый интерфейс (мессенджер) и самый «сделано за тебя» формат (DFY) — это сильный продуктовый ход против JTBD «не хочу учиться новому инструменту».

1.2. Сегменты пользователей

[ФАКТ — заявленная ЦА: founders/CEO/COO/chief-of-staff]. Как PM я бы разложил на сегменты по силе fit:

[ИНТЕРПРЕТАЦИЯ — важный нюанс для PM: заявленная ЦА «founders/CEO/COO» звучит как один сегмент, но это три разных продукта по требованиям. Founder хочет «просто работало». COO хочет «контроль, аудит, предсказуемость». Это противоречие в требованиях к approval/observability (см. §4). Сегментная размытость — продуктовый риск: невозможно одинаково хорошо обслужить «дай мне свободу» и «дай мне контроль» одной конфигурацией.]

2. Продуктовая поверхность и реальные юзкейсы

2.1. Продуктовая поверхность (surface area)

[ФАКТ — с workeron.ai / артефакт 01]:

• Входные каналы: Telegram, WhatsApp, Gmail/Email. Нет отдельного app/дашборда — мессенджер и есть интерфейс.
• Интеграции: на лендинге 16 (Notion, Slack, Gmail, Telegram, WhatsApp, HubSpot, Linear, Calendly, Stripe, Google Drive, Airtable, Asana, ClickUp, Zapier, Trello, Intercom); в прайс-карточке лимит «Up to 12». [ФАКТ — расхождение 16 vs 12, артефакт 01 §2]
• Три продуктовых примитива:
  1. Execution engine — multi-step «workflow chains» across инструментов.
  2. Smart approval — критичные действия → one-tap approval в инбоксе; остальное закрывается в фоне.
  3. Self-learning memory — контакты, предпочтения, «never asks twice».

[ИНТЕРПРЕТАЦИЯ — PM-чтение поверхности]:

• Наличие Zapier в списке интеграций — сильный сигнал, что под капотом это оркестрация поверх готовых коннекторов, а не глубокая нативная интеграция с каждым из 16 инструментов. Это нормально для ранней стадии, но влияет на надёжность (см. §4) и на defensibility (легко копируется).
• Мессенджер-as-UI = минимум surface для онбординга (плюс), но и минимум места для контроля/прозрачности (минус). В чате нет «дашборда состояния агента», нет очевидного «лога что агент сделал», нет «отмены». Это архитектурно зашивает проблему доверия (§4).
• «16 vs 12» — мелочь, но для PM это маркер: лендинг опережает продукт, спецификация ещё не стабилизирована.

2.2. Реальные юзкейсы (declared)

[МАРКЕТИНГ — их примеры]:

• Inbox triage → «Inbox-zero by 9am».
• Calendar ops (бронирование/перепланирование).
• Workflow chains: например, «новый лид в HubSpot → создать задачу в Linear → черкнуть в Slack → запланировать follow-up».
• Critical action approval: пример на лендинге — одобрение wire-перевода на $12,400. [ФАКТ — артефакт 01 §2]

[ИНТЕРПРЕТАЦИЯ — что из этого реально, а что demo-ware]:

• Демо-цифры на лендинге («1.9 s/task», «processed 312 threads this week», «11h 42m saved») — это иллюстративный UI-мокап, не телеметрия. [ФАКТ — артефакт 01 §2 явно это фиксирует]. Для PM: ни один из юзкейсов не подтверждён публичным клиентским кейсом. Все «portfolio cases» — внутренние прототипы (Internal Dev / Pilot / Prototype). [ФАКТ — артефакт 01 §4]
• Самый показательный юзкейс — wire $12,400 approval: он одновременно демонстрирует ценность (агент трогает деньги) и обнажает риск (агент трогает деньги). Это ровно та зона, где надёжность важнее фич (§4).

3. Фиче-гэпы против конкурентов (из артефактов 03/04)

[ИНТЕРПРЕТАЦИЯ на базе фактов из 03/04] Сравниваю продуктовую поверхность, а не фандинг. Беру самых близких: Cyndra (#1 по модели), Bond (#1 по ЦА), Lindy (референс позиционирования, «Lindy-lite»), Martin (канал).

Вывод по гэпам [ИНТЕРПРЕТАЦИЯ]:

• Это НЕ гонка фич. Workeron проигрывает по широте интеграций (Cyndra 1,000+ vs 12), по проактивной визибилити (Bond), по голосу (Martin), по self-serve-гибкости (Lindy). Если он попытается догнать всех по фичам — проиграет: у конкурентов в 10–500× больше капитала (Lindy ~$50M+, Sierra ~$950M; Workeron pre-seed). [ФАКТ по фандингу — артефакт 03]
• Реальный дифференциатор Workeron — НЕ продукт, а оффер: DFY one-time без lock-in + C-suite-фокус + мессенджер. Это сервисная, а не продуктовая защита (легко копируется технологически — артефакт 04 §«главный риск»). Для PM это значит: продуктовая стратегия должна углублять то, что трудно скопировать сервисом — а именно доверие/надёжность исполнения и качество memory, а не число интеграций.

4. UX-паттерн «сообщение в мессенджере + approval» — разбор

4.1. Как устроен паттерн (declared)

[ФАКТ — workeron.ai]: «Critical actions land in your inbox for one-tap approval. The rest closes quietly in the background.» То есть бинарная классификация: критичное → human-in-the-loop one-tap; некритичное → auto-execute молча.

4.2. Сильные стороны паттерна [ИНТЕРПРЕТАЦИЯ]

• Минимальный когнитивный налог. One-tap approval в том же мессенджере, где идёт жизнь founder'а — это правильный выбор канала под JTBD «не хочу новый инструмент».
• Соответствует индустриальному best-practice 2026. Успешные agentic-деплои 2026 — это именно HITL-комбинации, где «агент исполняет, но консеквентные/необратимые действия идут на ревью». Approval-rules в индустрии строят по осям: reversibility, customer impact, legal impact, access impact, dollar exposure. [ФАКТ — getclaw / digitalapplied / Galileo, 2026, см. Источники]
• Регуляторный попутный ветер: EU AI Act Art. 14 (human oversight для high-risk систем) вступает в силу 2 августа 2026 — HITL становится не фичей, а требованием. [ФАКТ — Strata, 2026]

4.3. Дыры в паттерне — критично для PM [ИНТЕРПРЕТАЦИЯ]

1. Бинарность «критично / некритично» — это product decision, которого не видно. Кто решает, что «критично»? Если классификатор сам агентский (LLM решает, что важно) — то самая опасная ошибка (агент не спросил, когда надо было) встроена в дизайн. Публичных данных о том, как настраивается порог критичности, не найдено.
2. «Closes quietly in the background» — антипаттерн доверия для COO-сегмента. «Тихо закрылось в фоне» = нет наблюдаемости. Для founder'а «just works» — плюс; для COO «я не вижу, что агент сделал в моём Stripe» — стоп-фактор. Это прямо упирается в сегментное противоречие из §1.2.
3. Approval ≠ reversibility. One-tap одобрил wire $12,400 — деньги ушли. Approval защищает от несанкционированного действия, но не от санкционированной ошибки (одобрил, не вчитавшись). Индустрия 2026 явно различает: approval-gate и rollback/undo — это два разных слоя. [ФАКТ — digitalapplied 2026: «action is rolled back or corrected»]. У Workeron rollback публично не заявлен.
4. Мессенджер плохо держит сложный approval. One-tap в чате ок для «да/нет». Но «одобри этот email из 4 абзацев на правильный ли тон» или «проверь, в ту ли CRM-сделку я записал» — в чат-интерфейсе тяжело ревьюить. Surface ограничивает качество ревью.

5. Критическая проблема: надёжность и доверие агентного исполнения

Это, на мой взгляд PM, проблема №1 продукта — выше любой фичи. Workeron продаёт не «совет», а исполнение в боевых системах клиента (Gmail, Stripe, HubSpot). Цена ошибки — не «плохой ответ», а отправленное не тому письмо, неверный wire, удалённая задача, испорченная CRM-сделка.

5.1. Почему это особенно остро именно для Workeron [ИНТЕРПРЕТАЦИЯ]

• Действия часто необратимы или дорого-обратимы. Отправленный email не отозвать; wire не отменить; сообщение в Slack клиенту видно сразу. Reversibility — низкая.
• Нет наблюдаемого слоя. Мессенджер-as-UI = нет дашборда «что агент сделал / собирается сделать / откатить». «Closes quietly» усугубляет.
• Оркестрация поверх Zapier/коннекторов = ошибки накапливаются по цепочке (multi-step chain: ошибка на шаге 2 портит шаги 3–5). Чем длиннее chain, тем выше P(ошибка) — а chains это их killer-фича.
• Doverие — это и есть activation-барьер. Индустрия 2026: 80% компаний уже сталкивались с тем, что AI-приложения действовали вне заданных границ (39% — несанкционированный доступ, 33% — работа с запрещённой информацией); 92% считают governance необходимым, но только 44% имеют политики. [ФАКТ — masterofcode AI Agent Statistics 2026]. Покупатель-COO это знает и будет тестировать агента «на разрыв».

5.2. «Что если агент сделает не то» — чек-лист, которого не хватает в публичных материалах [ИНТЕРПРЕТАЦИЯ]

Как PM я бы потребовал ответы на:

• Prevention: dry-run / preview перед исполнением? confidence-threshold → авто-эскалация на approval? scoped permissions (read-only по умолчанию для новых интеграций)?
• Detection: видит ли пользователь в реальном времени, что агент делает? есть ли журнал действий (audit log)?
• Recovery: undo/rollback для обратимых действий? «kill switch» (стоп всему агенту)? compensating actions (если wire нельзя отменить — хотя бы немедленный алерт + чек-лист)?
• Accountability: кто несёт ответственность за ущерб от ошибочного действия? (договорный, но это product+legal вопрос). Публичных данных нет.
• Learning: каждая коррекция человека = training-signal для memory и для рекалибровки порогов. Индустрия 2026 делает именно так: «every human correction is training data… recalibrate confidence thresholds». [ФАКТ — getclaw 2026]

Вывод [ИНТЕРПРЕТАЦИЯ]: Workeron заявляет approval + memory, но observability и reversibility — белое пятно. Для продукта, который трогает деньги и письма клиентов, это не edge-case, а ядро ценностного предложения «доверь мне исполнение». Без него «Consider it done» легко превращается в «Consider it done… wrong».

6. Ключевые продуктовые метрики

6.1. Метрический парадокс one-time-модели [ИНТЕРПРЕТАЦИЯ]

При разовом $1,900 без подписки у продукта нет классических SaaS-сигналов: нет MRR, нет логина-как-обязательства, нет churn в привычном смысле. Это меняет всю метрику-рамку.

6.2. North Star Metric — гипотеза [ИНТЕРПРЕТАЦИЯ]

Я бы предложил NSM = «weekly successfully-executed, human-trusted tasks per active client» (число задач/неделю, исполненных и НЕ откаченных/не переделанных вручную). Он связывает:

• ценность (задачи реально делаются),
• доверие (их не приходится править),
• удержание (частота держится со временем).

Это лучше, чем «часов сэкономлено» (немеряемо/маркетинг) и чем «кол-во клиентов» (vanity для transactional-модели).

6.3. Бенчмарки для калибровки ожиданий [ФАКТ — 2026]

• B2B SaaS медианный месячный churn ~3.5% (топ <2%); NRR топ-перформеров >120%. [ФАКТ — ever-help / Recurly 2025–2026]. Workeron с one-time-моделью по определению не может показать NRR>100% без ретейнеров — это структурное ограничение, которое PM должен явно проговорить инвесторам.
• Gartner: 40% enterprise-приложений будут иметь task-specific AI-агентов к концу 2026 (с <5% в 2025) — рынок-попутчик, спрос растёт. [ФАКТ — strata.io 2026]

7. Пробелы в discovery

[ФАКТ + ИНТЕРПРЕТАЦИЯ] Это, пожалуй, самый тревожный для PM раздел.

• Нет ни одного публичного клиентского инсайта. Все «portfolio cases» — внутренние (Internal Dev / Pilot / Prototype). Отзывы анонимны («Founder · Fintech»). Сторонних ревью (G2/Trustpilot) нет. [ФАКТ — артефакт 01 §4]. → Продукт, вероятно, строится на интуиции основателей и на копировании Lindy/конкурентов, а не на валидированных проблемных интервью.
• Демо-метрики выдуманы (мокап). «312 threads», «11h 42m saved» — иллюстрация. [ФАКТ — артефакт 01 §2]. → Нет признаков, что команда меряет реальное поведение пользователя.
• ROI-калькулятор как discovery-суррогат. Дефолты 12 ч/нед × $200/час — это гипотеза о ценности, выданная за факт. «5.5 days payback» внутренне согласовано арифметически, но допущения аспирационные (полная экономия начинается после 7+30 дней). [ФАКТ — артефакт 01 §3.2]. → Discovery подменён маркетинговой моделью.
• Сегментная размытость (founders/CEO/COO как один сегмент) — признак, что JTBD не сегментирован через интервью. Разные сегменты = разные требования к approval/observability (§1.2, §4).
• Контент блога — «Built by Machines», пакетный SEO-засев (6 статей, март 2026). [ФАКТ — артефакт 02 §1.1]. → Это lead-gen, не источник пользовательских инсайтов.

Главный discovery-гэп [ИНТЕРПРЕТАЦИЯ]: нет петли «реальный пользователь → наблюдение → инсайт → продукт». Для pre-seed это поправимо, но именно этого не хватает, чтобы превратить хороший оффер в защищаемый продукт.

8. Продуктовые рекомендации (3–5, приоритизация по RICE-логике на словах)

RICE = Reach × Impact × Confidence / Effort. Привожу рассуждение, не псевдоточные числа.

Рекомендация 1 (ТОП) — Построить слой Observability + Reversibility («Trust Layer»)

• Что: журнал действий агента в реальном времени (что сделал/собирается), undo/rollback для обратимых действий, dry-run/preview для chains, явные scoped-permissions (read-only по умолчанию для новых интеграций), kill-switch.
• RICE: Reach — все клиенты, каждое действие. Impact — максимальный: это снимает главный барьер активации (доверие) и закрывает регуляторику (EU AI Act Art.14, авг 2026). Confidence — высокая (индустрия 2026 единодушна: reversibility + audit — foundational [getclaw/digitalapplied/Galileo]). Effort — средне-высокий (инженерно), но частично можно начать с дешёвого audit-log в чате.
• Почему №1: это превращает «Consider it done» из обещания в защищаемое преимущество (то, что сервис скопировать не может). Без него COO-сегмент недоступен.

Рекомендация 2 — Инструментировать Activation + Task-Success-Rate (NSM-телеметрия)

• Что: заменить demo-мокапы реальной телеметрией: TTFV, task success rate (исполнено без ручной правки/отмены), approval-friction, weekly tasks/client. Завести NSM (§6.2).
• RICE: Reach — все клиенты. Impact — высокий (без этого нельзя ни управлять продуктом, ни доказать ROI инвесторам/клиентам реальными цифрами вместо «5.5 days»). Confidence — высокая. Effort — низко-средний (это в основном дисциплина + лёгкий бэкенд-инструментинг).
• Почему высоко: дёшево, разблокирует всё остальное (включая доказательную базу для discovery и для следующего раунда).

Рекомендация 3 — Запустить discovery-петлю и добыть 1 публичный кейс с цифрами

• Что: 5–10 структурированных проблемных интервью с реальными клиентами .ai; один named case-study с фактическими (не мокап) метриками сэкономленного времени/исполненных задач; сегментировать JTBD (founder vs COO).
• RICE: Reach — влияет на весь roadmap (через инсайты) + на конверсию лендинга (через social proof). Impact — высокий (закрывает #1 красный флаг — нулевой трекшен). Confidence — высокая. Effort — низкий (организационный, не инженерный).
• Почему высоко: один настоящий кейс с цифрами стоит дороже десяти demo-мокапов и десяти SEO-статей.

Рекомендация 4 — Разрешить сегментное противоречие approval/control

• Что: ввести два пресета доверия — Founder mode (макс. автономность, минимум approval) и Operator/COO mode (полный audit, низкий порог approval, обязательный лог). Сделать порог критичности настраиваемым и прозрачным, не чёрным ящиком.
• RICE: Reach — расширяет доступную ЦА (открывает COO-сегмент). Impact — средне-высокий. Confidence — средняя (нужно валидировать, что COO вообще целевой). Effort — средний.
• Почему ниже топа: зависит от Рек.3 (сначала понять, COO ли это реальный сегмент), но напрямую вытекает из дыры §4.3.

Рекомендация 5 — Превратить memory в измеримый и демонстрируемый актив (anti-commodity ход)

• Что: сделать «self-learning memory» наблюдаемой и ценной для клиента: показывать, что агент запомнил; давать корректировать; мерить «% задач, не потребовавших переспроса» как метрику качества памяти. Это то, что трудно скопировать (накапливается со временем = switching cost даже без lock-in).
• RICE: Reach — все клиенты. Impact — средний-высокий (это единственный кандидат на органический moat в anti-lock-in модели). Confidence — средняя. Effort — средний.
• Почему включил: в модели «no lock-in» memory — единственный источник естественного удержания (чем дольше агент с тобой, тем он умнее именно про тебя). Это стратегически противодействует метрическому парадоксу §6.1.

Сводный приоритет (RICE-логикой): 1 (Trust Layer) → 2 (Activation-телеметрия) → 3 (Discovery + кейс) → 4 (сегментные режимы) → 5 (memory-as-moat). Топ-3 — это «нельзя управлять продуктом и продавать доверие вслепую»; 4–5 — стратегические, зависят от данных топ-3.

9. 3–5 вопросов/гипотез для проверки или для собеседования

Конкретные, проверяемые. Кандидат может принести их на интервью как PM-due-diligence.

1. Reversibility/observability (продуктовое ядро): «Что происходит, когда агент исполнил не то — есть ли undo/rollback, audit-log, dry-run, kill-switch? Кто и как определяет порог "критичности" для approval — это LLM или правило?» Гипотеза: публично этого нет → значит, либо ещё не построено (риск), либо построено, но не коммуницируется (упущение). Ответ покажет инженерную и продуктовую зрелость.

2. Реальный task-success-rate и TTFV: «Какая доля запущенных задач исполняется без ручной правки/отмены? Сколько в среднем дней от оплаты до первой реально сэкономленной задачи?» Гипотеза: реальный TTFV — недели (из-за 7+30 дней сетапа), а success-rate нигде не меряется → команда живёт на мокап-метриках.

3. Метрика удержания в one-time-модели: «Без MRR — как вы определяете "активного" клиента и как ловите момент, когда он молча перестал пользоваться? Какая доля .ai-клиентов конвертируется в retainer?» Гипотеза: реальный денежный поток держится на ретейнерах/agency-проектах, а $1,900-оффер — это lead-gen [артефакт 01 §3.3]. Если так — продуктовый focus должен быть на conversion-to-retainer, а не на $1,900-throughput.

4. Discovery-фундамент: «Сколько проблемных интервью с платящими клиентами проведено? Есть ли хоть один named-кейс с фактическими цифрами (не мокап)?» Гипотеза: discovery почти отсутствует, продукт строится по аналогии с Lindy/Cyndra → высокий риск product-market-fit вслепую.

5. Сегментное противоречие: «Founder и COO предъявляют противоположные требования к контролю/прозрачности — вы строите один продукт под обоих или фокусируетесь? Кто из них показывает лучшую активацию/retention?» Гипотеза: ЦА не сегментирована; реальный лучший сегмент — solo-founder без ops-команды, а COO будет упираться в недостаток observability (§4.3).

Источники

Артефакты (первичная фактура о Workeron):

• 01_company_profile_model.md, 02_roadmap_whats_next.md, 03_major_competitors.md, 04_minor_competitors.md (этот teardown, 30.06.2026).
• Workeron.ai (продукт, прайс, smart-approval, memory, интеграции, ROI-калькулятор): https://workeron.ai/ — просмотрено 30.06.2026.
• Workeron.agency (services/cases/process, «Digital Employees Lab»): https://workeron.agency/ , https://workeron.agency/blog.html — 30.06.2026.

Конкуренты (фичи/модель — из артефактов 03/04, первоисточники там):

• Cyndra: https://www.cyndra.ai/ ; Bond: https://www.bondapp.io/ , https://www.ycombinator.com/launches/Ncl-bond-ai-chief-of-staff-for-ceos-and-busy-execs ; Lindy: https://www.lindy.ai/pricing ; Martin: https://www.trymartin.com/pricing .

Бенчмарки и best-practice категории (WebSearch, 30.06.2026):

• Human-in-the-loop / reversibility как foundational pattern 2026: https://getclaw.sh/blog/human-in-the-loop-ai-agents-approvals-2026 ; https://www.digitalapplied.com/blog/human-in-the-loop-escalation-design-ai-agents-2026 ; https://galileo.ai/blog/human-in-the-loop-agent-oversight ; https://callsphere.ai/blog/ai-agent-human-in-the-loop-patterns-critical-decisions
• EU AI Act Art.14 (human oversight, в силе с 02.08.2026) + Gartner 40% enterprise-apps с агентами к концу 2026: https://www.strata.io/blog/agentic-identity/practicing-the-human-in-the-loop/
• Activation/TTFV для AI-платформ; «90% AI-кода закоммичено» как мера доверия: https://www.arcade.dev/blog/user-retention-in-ai-platforms-metrics/
• AI-agent статистика 2026 (80% — действия вне границ; 92% governance необходим, 44% имеют политики): https://masterofcode.com/blog/ai-agent-statistics
• SaaS retention/churn бенчмарки 2026 (месячный churn ~3.5%, NRR топ >120%): https://www.ever-help.com/blog/saas-retention-rate-benchmarks

Уверенность и пробелы

Высокая уверенность:

• Продуктовая поверхность Workeron (каналы, 3 примитива, 12–16 интеграций, smart-approval, memory) — прямо с лендинга, корроборировано артефактами 01/02.
• One-time $1,900 / no lock-in / «live in a week» — корроборировано (артефакты 01–04).
• Demo-метрики = мокап; все «кейсы» внутренние; отзывы анонимны — прямо зафиксировано в артефакте 01 §4.
• HITL + reversibility — foundational pattern категории 2026; approval ≠ rollback (≥3 независимых источника 2026).

Средняя уверенность / интерпретация:

• JTBD-формулировка, сегментация, NSM-гипотеза, RICE-приоритеты — это мой PM-вывод на базе фактов, а не заявления компании.
• Фиче-гэп-таблица: фичи конкурентов взяты из артефактов 03/04 (их первоисточники), но прямого 1:1 product-сравнения «фича в фичу» никто публично не делал.
• «Оркестрация поверх Zapier» — интерпретация по косвенному признаку (Zapier в списке интеграций), не подтверждённый тех-факт.

Пробелы / «публичных данных не найдено»:

• Реальные значения activation, TTFV, task-success-rate, retention, число платящих клиентов — публично НЕТ (только demo-мокапы и ROI-калькулятор).
• Устройство reversibility/undo/audit-log/kill-switch — публично НЕ раскрыто (ключевой пробел §5).
• Как именно классифицируется «критичность» для approval (LLM vs правило) — НЕ раскрыто.
• Доля .ai-клиентов, конвертирующихся в ретейнеры — НЕ раскрыто.
• Результаты любого пользовательского discovery (интервью, тесты) — публично НЕ найдено.