Workeron — линза PRODUCT OWNER (delivery / execution / операционка)

Разбор операционки и доставки Workeron глазами Product Owner'а (delivery/execution). Дата анализа: 30 июня 2026. Объект — очень ранняя компания (founded 2026, 2–10 чел., pre-seed от AmA Invest Capital), две сущности под одним брендом: workeron.ai (DFY AI chief-of-staff, разовый $1,900) и workeron.agency (AI transformation agency, PoC→Pilot→Scale). Легенда честности: [ФАКТ] — подтверждено источником (≥2 где возможно); [МАРКЕТИНГ] — их собственные слова, не верифицировано; [ИНТЕРПРЕТАЦИЯ] — мой аналитический вывод как PO. Важная оговорка: внутренних артефактов Workeron (бэклог, тикеты, рунбуки, SLA-документы) публично не существует — компания закрыта. Всё ниже про процессы/бэклог/SLA — это [ИНТЕРПРЕТАЦИЯ]: как это устроено по логике их же оффера и что PO здесь обязан был бы построить. Я нигде не выдаю гипотезы за факты.

0. TL;DR для PO (самое важное)

• Доставка = productized service, а не SaaS-инсталляция. «Live in a week» (7 дней сетап) + «30 days fine-tuning» — это человеко-управляемый delivery-цикл, а не self-serve онбординг. Каждый клиент = мини-проект внедрения. [ИНТЕРПРЕТАЦИЯ на базе ФАКТА — прайс/FAQ workeron.ai]
• Бутиковость сетапа = главное операционное бутылочное горлышко. При фикс-цене $1,900 и ручной настройке под каждого клиента маржа и пропускная способность ограничены человеко-часами delivery-команды, а не софтом. «14 spots left / Limited Access Q3» — это искусственный дефицит, который маскирует реальный capacity ceiling. [ИНТЕРПРЕТАЦИЯ]
• «30 дней донастройки» — это hypercare-окно, и это отраслевой стандарт DFY-агентств (single-purpose агент $1,500–$5,000 build + «30-day stabilisation window»). Workeron не изобрёл паттерн — он его перенял. [ФАКТ — thecrunch.io]
• Хэндофф «agency → product» формально провозглашён («hand you the keys, no lock-in»), но операционно дырявый: «optional retainers for ongoing tuning» + ручная интеграция = клиент по факту остаётся завязан на команду. [ФАКТ — FAQ workeron.ai] + [ИНТЕРПРЕТАЦИЯ]
• Главные delivery-риски: (1) зависимость от ручной настройки (не масштабируется линейно); (2) поддержка 12–16 сторонних интеграций (OAuth-токены протухают, API ломаются — а это исполнительные, не read-only действия); (3) инциденты исполнения (агент сделал не то — wire, письмо клиенту, обновление CRM) при заявленном «smart approval» только для «critical actions». [ИНТЕРПРЕТАЦИЯ]
• Что PO здесь реально владел бы: не «фичами SaaS», а delivery pipeline'ом (intake → build → go-live → 30-day tuning → handoff/retainer), библиотекой переиспользуемых шаблонов агентов, каталогом интеграций и incident/approval-процессом. Это PO «productized-сервиса», а не PO классического продукта.
• Delivery health здесь измеряется не product-метриками (DAU/retention), а сервисными: time-to-live, % go-live в срок (7 дней), стоимость сетапа в человеко-часах, доля сетапов в шаблоне vs кастом, tuning-нагрузка в 30-дневном окне, частота инцидентов исполнения, conversion в retainer. [ИНТЕРПРЕТАЦИЯ]

1. Как устроена DFY-доставка (7 дней + 30 дней) — реконструкция

1.1. Что заявлено дословно [ФАКТ — workeron.ai, fetched 2026-06-30]

• «We set up your AI agent end-to-end in 7 days, then hand you the keys — no per-seat fees, no caps, no platform lock-in.»
• В прайс-карточке: «custom agent под workflow; коннект к Telegram/WhatsApp/Email; up to 12 tool integrations; memory под контакты/предпочтения; 1 неделя до запуска, онбординг включён; 30 дней донастройки после запуска».
• FAQ: «We offer optional retainers if you want ongoing tuning.»
• Процесс enterprise-рукава (workeron.agency): Discovery → PoC (2–4 недели) → Pilot → Scale. [ФАКТ — articles.js JSON]

1.2. Реконструированный delivery-pipeline [ИНТЕРПРЕТАЦИЯ — как это обязано работать по их же офферу]

Логичная последовательность для $1,900-оффера (это и есть «скрытый» процесс, которым владел бы PO):

[ИНТЕРПРЕТАЦИЯ] Это классический бутиковый delivery-flow агентства, упакованный в фикс-цену. Ключевой признак: каждый этап (Discovery, Build, Tuning) требует человека, а не конфигуратора. То есть «7 дней» — это SLA на ручную работу команды, а не время self-serve активации.

1.3. Отраслевой контекст (бенчмарк) [ФАКТ]

• «Single-purpose AI agent — $1,500–$5,000 build, 30-day stabilisation window» — стандартная структура DFY-агентств 2026. Workeron ($1,900 + 30 дней) ровно в этом коридоре. [thecrunch.io/ai-agents-price]
• The Crunch использует тот же приём: «30-day stabilisation windows» = дословный аналог «30 дней донастройки» Workeron. [04_minor_competitors.md; thecrunch.io]
• Часть агентств: «working agents в staging + evals за 14 дней», «30-day hypercare». [voiceflow.com/blog/ai-agency]
• Вывод PO: «live in a week + 30 days tuning» — не уникальное преимущество, а скопированный отраслевой паттерн delivery. Дифференциация Workeron не в процессе доставки, а в цене (one-time без SaaS) и канале (мессенджер). [ИНТЕРПРЕТАЦИЯ]

2. Масштабируемость: нужен ли бутиковый сетап под каждого клиента? (центральный вопрос PO)

2.1. Гипотеза о бутылочном горлышке [ИНТЕРПРЕТАЦИЯ]

Да, по умолчанию сетап бутиковый и это и есть бутылочное горлышко. Признаки в их же материалах:

• «custom agent под ваш workflow» — кастом по определению; «memory под ваши контакты/preferences» — ручная заливка контекста. [ФАКТ — workeron.ai]
• «up to 12 tool integrations» на клиента — каждая интеграция = OAuth + маппинг полей + тест. [ФАКТ]
• Enterprise-рукав работает через Discovery→PoC→Pilot→Scale — это явный консалтинговый, не продуктовый цикл. [ФАКТ]
• Признак «склейки поверх коннекторов»: Zapier в списке интеграций → агент во многом оркестрирует чужие коннекторы, а не имеет глубокую нативную интеграцию с каждым из 16 инструментов (см. 01_company_profile, §2). [ИНТЕРПРЕТАЦИЯ]

2.2. Почему это горлышко именно операционно

[ИНТЕРПРЕТАЦИЯ]

• Линейная себестоимость. Если N клиентов требуют ~X инженеро-дней каждый, то пропускная способность = (люди × дни) / X. При команде 2–10 чел. это десятки, не сотни сетапов в квартал. «14 spots/Q3» правдоподобно отражает именно реальный capacity, а не только маркетинговый дефицит.
• Маржа разовая и сервисная. $1,900 минус человеко-часы Discovery+Build+30 дней Tuning. Если сетап + tuning съедают, скажем, 20–40 ч квалифицированного труда, валовая маржа на одном $1,900-клиенте тонкая → бизнес держится на ретейнерах/enterprise, а не на $1,900 (см. 01_company_profile, §3.3).
• Отраслевой сигнал: «большинство операторов упираются в capacity ceiling до того, как систематизируют delivery — это критическая точка перегиба». [abhyashsuchi.in; designrush] И: «78% agentic-пилотов стопорятся до прода, потому что пропускают problem-definition и сразу строят агентов». [kore.ai/blog]

2.3. Что снимает горлышко (то, что PO обязан был бы выстроить)

[ИНТЕРПРЕТАЦИЯ — это и есть продуктовая работа внутри сервиса]

1. Templatization (шаблоны агентов под ICP). Не «кастом с нуля», а 3–5 готовых playbook'ов (например: «Founder inbox+calendar ops», «COO reporting/anomaly», «Sales/CRM hygiene») с 80% преднастройки и 20% кастома. Отраслевой консенсус: «templates reduce variability, accelerate onboarding, ensure consistency». [agentcenter.cloud]
2. Каталог переиспользуемых интеграций с готовыми OAuth-флоу и маппингами (а не настройка каждой интеграции руками каждый раз).
3. Библиотека approval-матриц по типам действий (что всегда требует one-tap, что авто).
4. Self-serve части онбординга (клиент сам подключает свои аккаунты по гайду) — снимает часть инженеро-часов.
5. Eval-харнес (golden-набор задач на тип агента), чтобы go-live проходил по чеклисту, а не «на глаз».

Метрика-индикатор успеха де-бутиковизации: доля сетапов, закрытых из шаблона без кастомного кода, и сокращение инженеро-часов на сетап квартал к кварталу. Если эта доля не растёт — компания остаётся агентством, а не продуктом. [ИНТЕРПРЕТАЦИЯ]

3. Что было бы в бэклоге PO (delivery-ориентированный)

[ИНТЕРПРЕТАЦИЯ — приоритизированный бэклог, который должен существовать у delivery-PO на этой стадии]

P0 — снять бутылочное горлышко доставки (де-бутиковизация):

1. Onboarding intake-форма + scope-gate — формализовать, что входит в $1,900 (≤12 интеграций, X workflow-цепочек), чтобы убить scope creep на фикс-цене.
2. 3–5 шаблонов агентов под ICP (templated playbooks) с измеримым % преднастройки.
3. Integration-каталог (готовые коннекторы + health-чеки токенов).
4. Go-live чеклист + eval-набор (приёмочные тесты перед передачей ключей).

P0 — управление риском исполнения: 5. Approval-матрица как конфиг (классы критичных действий: деньги/внешняя коммуникация/удаление данных → обязательный one-tap). 6. Incident-рунбук исполнения (агент сделал не то: откат, нотификация клиента, post-mortem). 7. Audit-trail каждого действия агента (что сделал, когда, по чьему approval) — нужен и для доверия, и для разбора инцидентов.

P1 — хэндофф и удержание выручки: 8. Handoff-пакет (документация «как владеть агентом», доступы, лимиты) — чтобы «own the keys» был реальным, а не дырой. 9. Retainer-оффер как продукт (SLA уровни, что входит в tuning) — легитимизировать скрытый recurring. 10. Self-serve реконфигурация части настроек (клиент меняет preferences без инженера).

P1 — observability & quality: 11. Delivery-дашборд (time-to-live, on-time %, tuning-нагрузка, инциденты) — см. §7. 12. Memory-governance (как обновляется/чистится self-learning memory, защита от дрейфа).

P2 — рост ассортимента: 13. Вертикальные агенты (market research, commercial analyst, feedback) — но только после систематизации delivery первого SKU, иначе множит горлышко.

[ИНТЕРПРЕТАЦИЯ] Ключевой принцип приоритизации для этой стадии: P0 = снизить себестоимость и риск одного сетапа, потому что без этого любой рост ассортимента (вертикальные агенты, marketplaces из их же 2027-нарратива) только усугубит операционную нагрузку.

4. Процессы, SLA, саппорт, хэндофф

4.1. SLA — что заявлено и что должно быть [ФАКТ + ИНТЕРПРЕТАЦИЯ]

• Заявленный SLA доставки: «live in a week» = 7-дневный go-live SLA. [ФАКТ — workeron.ai]
• Tuning-SLA: «30 days fine-tuning» = 30-дневное hypercare-окно. [ФАКТ]
• Чего публично НЕ заявлено (пробел, который PO обязан закрыть): [ИНТЕРПРЕТАЦИЯ]
  • Uptime/доступность агента (исполнительная система 24/7 — нужен availability-SLA).
  • Время реакции на инцидент исполнения (агент сломал процесс — за сколько чинят?).
  • Время реакции на поломку интеграции (OAuth протух, API сменил схему).
  • Approval-SLA (как быстро критичное действие уходит на one-tap и сколько ждёт).
  • Эскалация после 30 дней (что входит/не входит в retainer).

4.2. Саппорт-модель [ИНТЕРПРЕТАЦИЯ]

• Роль Client Success Manager уже в вакансиях: «Own deployment and client relationships. Translate complex AI into measurable business outcomes.» [ФАКТ — workeron.agency careers]
• Это сигнал, что саппорт = high-touch human (CSM), а не тикет-система/self-serve. На ранней стадии это норм, но не масштабируется и удорожает каждого клиента.
• Пробел: канал саппорта не описан. Логично, что саппорт идёт через тот же мессенджер (Telegram/WhatsApp), что и продукт — но тогда execution-канал и support-канал смешаны, что усложняет разбор инцидентов. [ИНТЕРПРЕТАЦИЯ]

4.3. Хэндофф «agency ↔ product» [ФАКТ + ИНТЕРПРЕТАЦИЯ]

Два уровня хэндоффа, оба проблемные:

1. Внутренний (sales/agency → delivery): заявка с .ai или лид с .agency → команда внедрения. [ИНТЕРПРЕТАЦИЯ] Риск: на 2–10 чел. это одни и те же люди, формального хэндоффа нет → знание в головах, не в артефактах.
2. Внешний (Workeron → клиент, «hand you the keys»): [ФАКТ — workeron.ai] Декларируется полная передача владения. Но: «optional retainers for ongoing tuning» + кастомная интеграционная склейка означают, что реальный handoff неполный — клиент технически не сможет сам поддерживать 12 интеграций и memory. [ИНТЕРПРЕТАЦИЯ] Это противоречие оффера: «no lock-in» продаётся как преимущество, но операционно создаёт либо (а) брошенных клиентов после 30 дней, либо (б) скрытый lock-in через ретейнер. PO обязан был бы разрешить это противоречие явной handoff-политикой.

5. Операционные риски (ранжировано)

[ИНТЕРПРЕТАЦИЯ, опирается на ФАКТЫ из профиля и отрасли]

Риск 1 — Зависимость от ручной настройки (СИСТЕМНЫЙ, высокий)

• Сетап и tuning требуют квалифицированного человека на каждого клиента → линейная себестоимость, ограниченный throughput, тонкая маржа на $1,900.
• Усиливается крошечной командой (2–10). Bus-factor: 1–2 инженера держат всю delivery.
• Отраслевое подтверждение: capacity ceiling до систематизации delivery — типовая точка смерти DFY-операторов. [abhyashsuchi.in]

Риск 2 — Поддержка интеграций (ВЫСОКИЙ, недооценённый)

• 12–16 сторонних API (Notion, Gmail, HubSpot, Stripe, Slack, Linear…). Это исполнительные интеграции (пишут/действуют), а не read-only.
• OAuth-токены протухают, API меняют схемы/лимиты, rate-limits. Каждая поломка = инцидент у клиента, у которого «AI перестал работать».
• При N клиентах × 12 интеграций поверхность поддержки растёт мультипликативно. Без health-мониторинга токенов это тихо ломается.
• Отраслевой сигнал: «agent initiatives не проектировались под масштаб и разваливаются на security/identity/integration с enterprise-системами». [kore.ai]

Риск 3 — Инциденты исполнения (ВЫСОКИЙ по тяжести)

• Агент действует в боевых системах клиента: отправляет письма, обновляет CRM, инициирует Stripe-операции. Ошибка = не «неудобство», а реальный бизнес-ущерб (отправлено не то письмо клиенту, испорчены данные в HubSpot, неверный wire).
• «Smart approval» покрывает только «critical actions» (пример — wire $12,400). [ФАКТ] Граница «critical vs non-critical» — субъективна и опасна: многие «некритичные» действия (письмо инвестору, обновление сделки) при ошибке дорого стоят. [ИНТЕРПРЕТАЦИЯ]
• Нужны: audit-trail, undo/rollback, чёткая approval-матрица, incident-рунбук. Публично об этом ничего — пробел.

Риск 4 — Скоуп-крип на фикс-цене (СРЕДНИЙ, экономический)

• $1,900 фикс + «custom workflow» + «30 дней донастройки» = классический капкан агентства: клиент дотягивает скоуп в tuning-окне, маржа тает. Без жёсткого scope-gate каждый клиент может стать убыточным. [ИНТЕРПРЕТАЦИЯ]

Риск 5 — Безопасность/доверие (СРЕДНИЙ-ВЫСОКИЙ репутационный)

• «SOC2-grade infra» — не сертификация (см. 01_company_profile §2). [ФАКТ — формулировка] Агент с записывающим доступом к Gmail/Stripe/CRM founder'а = огромная зона доверия. Инцидент безопасности на ранней стадии = экзистенциальный.
• «Isolated agents per client» заявлено [МАРКЕТИНГ] — но изоляция инфраструктуры на клиента ещё и удорожает операционку (см. Cyndra — «dedicated isolated infrastructure per client» в 04_minor).

Риск 6 — Знание в головах, нет артефактов (СРЕДНИЙ, организационный)

• На 2–10 чел. без формальных рунбуков/чеклистов уход 1 инженера обрушивает delivery. PO-артефакты (см. §6) — это и есть страховка от этого.

6. Чем владел бы PO и какие артефакты нужны

6.1. Зона владения [ИНТЕРПРЕТАЦИЯ]

PO здесь — это PO delivery/execution productized-сервиса, не PO классического SaaS. Владел бы:

• Delivery pipeline (intake → build → go-live → tuning → handoff) как «продуктом».
• Библиотека шаблонов агентов и каталог интеграций (переиспользуемые активы).
• Approval/incident/audit-процессы исполнения.
• Retainer-оффер и handoff-политика.
• Delivery-метрики и их дашборд.
• НЕ владел бы (вероятно): глубоким core-агент-движком (это AI Engineer) и sales-воронкой (это CEO/Sales) — но был бы их главным стейкхолдером на стыке.

6.2. Конкретные артефакты — с примерами user stories и acceptance criteria

[ИНТЕРПРЕТАЦИЯ — это образцы того, что PO здесь обязан писать]

Артефакт А — Onboarding/Scope intake

• User story: «Как Client Success Manager, я хочу при заявке зафиксировать tool-stack клиента и его топ-3 workflow, чтобы определить, влезает ли он в $1,900-скоуп до старта build.»
• Acceptance criteria:
  • Форма собирает: список инструментов (≤12), 3 целевых workflow, success-метрику («сэкономить N ч/нед»).
  • Если интеграций >12 или есть инструмент вне каталога → авто-флаг «нужен enterprise/retainer scope».
  • Discovery brief генерируется и привязывается к delivery-тикету.

Артефакт B — Шаблон агента (templated playbook)

• User story: «Как Automation Engineer, я хочу собрать агента «Founder inbox+calendar» из шаблона, чтобы 80% настройки было преднастроено, а я кастомизировал только 20%.»
• Acceptance criteria:
  • Шаблон включает: дефолтные approval-правила, набор интеграций (Gmail+Calendar+Slack), типовые workflow-цепочки, eval-набор.
  • Сетап из шаблона проходит go-live чеклист за ≤3 инженеро-дня.
  • Доля кастомного кода вне шаблона измеряется и репортится.

Артефакт C — Approval-матрица

• User story: «Как клиент, я хочу, чтобы любое действие с деньгами или внешней коммуникацией уходило мне на one-tap approval, чтобы агент не нанёс ущерба.»
• Acceptance criteria:
  • Классы действий: money / external_comms / data_deletion → всегда approval; internal_read / internal_update → авто (конфигурируемо).
  • Approval-запрос приходит в тот же канал (Telegram/WhatsApp) с контекстом действия.
  • Каждое одобренное/отклонённое действие пишется в audit-trail.

Артефакт D — Go-live чеклист (Definition of Done доставки)

• Acceptance criteria: все ≤12 интеграций авторизованы и прошли health-чек; approval-матрица подтверждена клиентом; eval-набор зелёный; handoff-доступы переданы; success-метрика зафиксирована как baseline.

Артефакт E — Incident-рунбук исполнения

• User story: «Как CSM, при ошибочном действии агента я хочу за SLA-время уведомить клиента, откатить/смягчить последствие и завести post-mortem.»
• Acceptance criteria: severity-уровни; время реакции по severity; шаги отката; шаблон post-mortem; обновление approval-матрицы по итогам.

Артефакт F — Handoff-пакет

• Acceptance criteria: документ «как владеть агентом»; список доступов/токенов на стороне клиента; что входит/не входит после 30 дней; явный выбор клиента: full-handoff ИЛИ retainer.

6.3. Definition of Ready / Definition of Done (delivery-версия)

• DoR (сетап готов к старту): scope подтверждён ≤12 интеграций; ICP-шаблон выбран; доступы клиента получены.
• DoD (сетап завершён): go-live чеклист зелёный; baseline-метрика зафиксирована; handoff/retainer-решение принято.

7. Как измерять delivery health (метрики PO)

[ИНТЕРПРЕТАЦИЯ — нужный набор; публичных значений Workeron нет]

7.1. Скорость и предсказуемость доставки

• Time-to-live (TTL) — дни от intake до go-live. Цель: ≤7 (их обещание). Медиана + p90.
• On-time go-live % — доля сетапов, уложившихся в 7-дневный SLA.
• Tuning duration / overrun — реально ли укладываются в 30 дней или окно ползёт.

7.2. Себестоимость и масштабируемость (ключевое для де-бутиковизации)

• Engineer-hours per setup — главный индикатор горлышка. Должен падать квартал к кварталу.
• % сетапов из шаблона без кастома — главный индикатор «продукт vs агентство». Должен расти.
• Setups per engineer per quarter — фактический throughput vs «14 spots».
• Gross margin per $1,900-client (с учётом 30 дней tuning) — положительная ли юнит-экономика одного клиента.

7.3. Качество исполнения (надёжность агента)

• Execution success rate — % действий агента, выполненных корректно без вмешательства.
• Incident rate — инциденты исполнения на клиента в месяц; по severity.
• Integration health / token-expiry incidents — поломки коннекторов на клиента.
• Approval funnel — доля действий, ушедших на approval; среднее время до one-tap; % отклонённых (прокси «агент часто ошибается»).
• Time-to-recover (MTTR) по инцидентам исполнения и интеграций.

7.4. Ценность и удержание выручки

• Time-to-first-value — когда клиент впервые получил реально сэкономленное время (их обещание «10+ ч/нед»; их же калькулятор «5.5 дней» — см. 01_company_profile §3.2; реальный payback наверняка длиннее).
• Realized hours saved vs обещанные 10+ ч/нед (нужна телеметрия, а не мокап-цифры лендинга).
• Retainer conversion % после 30 дней — фактический recurring (скрытый бизнес-двигатель).
• Handoff-vs-retainer split — сколько клиентов реально «забирают ключи» vs остаются на ретейнере.
• Setup→agency upsell % — доля .ai-клиентов, доросших до enterprise-проектов .agency.

[ИНТЕРПРЕТАЦИЯ] «Северная звезда» delivery-PO на этой стадии — engineer-hours per successful go-live при растущей доле шаблонных сетапов. Именно она показывает, превращается ли агентство в масштабируемый продукт, или остаётся ручным бутиком.

8. Факт / Гипотеза / Мнение — сводка

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

1. Бутылочное горлышко сетапа (САМЫЙ ВАЖНЫЙ). «Сколько инженеро-часов в среднем уходит на один $1,900-сетап сегодня, и какая доля сетапов уже собирается из шаблонов без кастомного кода?» — Гипотеза: сетап почти полностью ручной (>15–20 ч), шаблонизации почти нет → throughput жёстко ограничен командой, «14 spots» = реальный capacity. Если у них есть растущая % шаблонных сетапов — это сильный сигнал, что они реально строят продукт, а не агентство.

2. Юнит-экономика одного клиента. «Какова валовая маржа на одном $1,900-клиенте с учётом 30 дней донастройки, и какой % клиентов конвертируется в ретейнер после go-live?» — Гипотеза: $1,900 близок к точке безубыточности или убыточен на тонком клиенте; реальные деньги — в ретейнерах и enterprise-проектах .agency. Хочу увидеть retainer-conversion и handoff-vs-retainer split.

3. Риск исполнения и approval-граница. «Где проходит граница critical vs non-critical для smart-approval, есть ли audit-trail и rollback, и сколько инцидентов исполнения было за последний квартал?» — Гипотеза: approval покрывает деньги, но не внешние письма/CRM-апдейты; формального incident-рунбука и rollback нет → серая зона дорогих ошибок в боевых системах клиента.

4. Поддержка интеграций. «Как мониторите здоровье 12+ интеграций на клиента (протухшие OAuth, смена API), и кто и за какой SLA чинит, когда у клиента «AI перестал работать»?» — Гипотеза: health-мониторинга токенов нет, поломки ловятся реактивно по жалобе клиента; нет availability/incident-SLA. При росте N это станет доминирующей операционной нагрузкой.

5. Реальность хэндоффа «own the keys». «Сколько клиентов после 30 дней реально забрали ключи и поддерживают агента сами, без вас?» — Гипотеза: близко к нулю — самостоятельная поддержка 12 интеграций + memory нетехническому founder'у не по силам, поэтому «no lock-in» на практике конвертируется в ретейнер (скрытый recurring) либо в брошенных клиентов. Ответ покажет, честен ли оффер операционно.

Источники

Первичные (Workeron, их собственные формулировки):

• workeron.ai — прайс, «live in a week», «30 days fine-tuning», «hand you the keys / no lock-in», FAQ про «optional retainers», «up to 12 integrations», smart-approval, «SOC2-grade»: https://workeron.ai/ — fetched 30.06.2026
• workeron.agency — процесс Discovery→PoC→Pilot→Scale, careers (Client Success Manager / Automation Engineer / AI Engineer), сервисы: https://workeron.agency/ + https://workeron.agency/articles.js — fetched 30.06.2026

Внутренние артефакты исследования (опора на факты):

• 01_company_profile_model.md — бизнес-модель/юнит-экономика §3, «SOC2-grade» §2, careers/роли §5
• 02_roadmap_whats_next.md — pricing/доступ §1.3, кейсы как внутренние §2, вектор «Digital Employees Lab»
• 03_major_competitors.md — ось дифференциации DFY vs SaaS; Sierra как outcome-based эталон
• 04_minor_competitors.md — Cyndra (managed/DFY, isolated infra per client), The Crunch («30-day stabilisation windows», fixed-price + retainer), indie DFY-операторы (месячный ретейнер)

Отраслевые бенчмарки delivery (для контекста 7+30 дней и горлышка):

• The Crunch — «single-purpose AI agent $1,500–$5,000 build, 30-day stabilisation window»: https://thecrunch.io/ai-agents-price/ — 30.06.2026
• Voiceflow — «AI automation agency in 7 days», staging+evals за 14 дней, 30-day hypercare: https://www.voiceflow.com/blog/ai-agency — 30.06.2026
• abhyashsuchi.in — «capacity ceiling до систематизации delivery»: https://abhyashsuchi.in/how-to-start-ai-automation-agency-2026/ — 30.06.2026
• DesignRush — обзор AI automation agencies 2026: https://www.designrush.com/agency/ai-companies/ai-automation-agency — 30.06.2026
• Kore.ai — «agent initiatives не проектировались под масштаб», «78% agentic-пилотов стопорятся до прода»: https://www.kore.ai/blog/ai-agents-in-2026-from-hype-to-enterprise-reality — 30.06.2026
• AgentCenter — «templates reduce variability, accelerate onboarding»: https://www.agentcenter.cloud/blogs/complete-guide-ai-agent-management-2026 — 30.06.2026

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

Высокая уверенность (≥2 источника или их прямые слова):

• Структура оффера доставки (7 дней + 30 дней tuning + optional retainers + «own the keys») — прямо с workeron.ai.
• «30-day stabilisation» — отраслевой стандарт DFY (Workeron не уникален) — workeron.ai + thecrunch.io + voiceflow.
• Capacity ceiling / ручная настройка как типовое горлышко DFY-операторов — отраслевые источники + логика их оффера.
• Роли delivery-команды (CSM, Automation/AI Engineer) — careers workeron.agency (см. 01_company_profile §5).

Средняя уверенность / гипотезы (обозначены как [ИНТЕРПРЕТАЦИЯ]/ГИПОТЕЗА):

• Реконструированный 6-фазный pipeline — логичная реконструкция по их офферу, не их опубликованный процесс.
• «14 spots» = реальный capacity (а не только маркетинг) — правдоподобная, но непроверяемая гипотеза.
• Скрытый recurring через ретейнеры как реальный денежный двигатель — согласуется с 01_company_profile §3.3, но публичных цифр нет.

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

• Любые реальные delivery-метрики Workeron: TTL, on-time %, engineer-hours/setup, incident rate, retainer-conversion — отсутствуют публично.
• Внутренние артефакты: бэклог, рунбуки, SLA-документы, approval-матрица, audit-trail — публично не существуют.
• Канал и SLA саппорта; availability-SLA агента; incident/rollback-процесс — не описаны публично.
• Число платящих клиентов и фактический throughput — не раскрыты (см. 01_company_profile §4).
• Реальный статус SOC 2 (только формулировка «SOC2-grade») — не подтверждён.