Time Platform развивается как модульная рабочая платформа

1. Контекст и повод

Каждый день в рабочих чатах Time рождаются сотни договоренностей: "проверить договор", "собрать фидбек", "обновить статус", "подготовить расчет". Договоренность остается только в переписке: у нее нет владельца, нет срока, нет ответственного, нет механизма, который вернет результат в тот же канал. Через несколько дней об этом напоминают словами "кто делал, какой статус". Так теряется не только время, но и доверие к рабочему процессу: команда перестает понимать, где проходит работа и кто за что отвечает.

Почему это важно именно сейчас. Time уже стал рабочим центром Т-Банка: на него переведены 50 000 сотрудников, а по кейсу на vc.ru сотрудники сами собрали более 2000 ботов и шаблонов процессов, от пропуска до маркетинговой акции. Это значит, что спрос на автоматизацию действий внутри Time уже проявлен явочным порядком: люди строят рабочие процессы сами, из подручных средств, без единой платформенной модели. Стратегия предлагает не изобретать новый спрос, а формализовать и укрепить то, что уже работает.

Единый тезис документа: Time может стать не просто мессенджером, а точкой входа в рабочее действие, если сделать контролируемый шаг от коммуникации к управляемому действию: задача, владелец, срок, статус, контекст и связь с главной системой учета рождаются там, где уже идет разговор.

Дальше в этом документе: принцип выбора первого шага, состояние возможностей Time (AS-IS), карта продуктовой линейки, экономика, риски и план пилота.

Термины документа: TASKS - внутренний трекер задач Т-Банка (развертывание TASKS), WIKI - внутренняя база знаний (развертывание Confluence). Далее в тексте эти названия используются как родовые обозначения главных систем учета задач и знаний, к которым подключается слой действий Time.

2. Короткий вывод

Для команд Т-Банка и Т-Технологий, которые уже живут в Time, Time Platform - единственное решение, где рабочее действие рождается прямо там, где уже идет разговор, а не в отдельном приложении, куда нужно вручную переносить контекст.

Кратко:

• продуктовая гипотеза первого шага - слой задач и договоренностей из коммуникации Time;
• это рабочая поверхность между сообщением, задачей, владельцем, сроком, статусом и главной системой учета;
• открытый периметр для расчета - 50 000 сотрудников Т-Банка в кейсе Time, 60 000 обезличенных пользователей Time в исследовании рабочих переписок, 54 млн клиентов Т-Технологий по годовому отчету 2025;
• рыночный ориентир - российский рынок корпоративных мессенджеров около 3 млрд руб. в 2025 году с ожидаемым ростом до 20% в год по оценке CNews со ссылкой на Iva Technologies;
• первая версия ограничена 5-7 полями задачи, 3-4 статусами, без досок, спринтов, отчетов, миграций, вложений и LLM по умолчанию;
• решение о пилоте возможно только после входных условий: внутренний заказчик, пилотные команды, исходный замер, доступ к данным, владелец безопасности, техническая проверка Time API.

Управленческое решение стратегии: начать с одного продуктового слоя вокруг действий из коммуникации. Этот слой должен доказать, что Time удерживает рабочий результат: кто отвечает, к какому сроку, в каком статусе, где лежит первичный контекст и какая система является главным источником учета.

Главная защита выбора: Time уже является рабочим местом коммуникации, поэтому сценарий на стыке сообщения и действия логично проверять первым. Если первый модуль докажет пользу, вокруг него можно строить доменные модули для юристов, бухгалтерии, продаж, HR, ИТ и продуктовых команд. При слабом результате направление останавливается без расширения команды.

По данным Time и Т-Банка, Time уже имеет сильную стартовую позицию: внутри Т-Банка корпоративный мессенджер стал рабочим центром для крупной организации, а снаружи у него уже есть SaaS и локальный контур. Следующий логичный шаг - выбрать один модуль, быстро доказать внутреннюю ценность и создать основу для следующих продуктов.

Продуктовая гипотеза первого шага: слой задач, связанных с коммуникацией. В нем задача создается из сообщения Time, сохраняет ссылку на контекст обсуждения, возвращает статус в канал и постепенно становится общей моделью рабочих сущностей для будущей вики, почты и документов.

Важно: это продуктовая гипотеза до интервью со спонсором и пилотными командами. Для перехода к пилоту нужны внутренний спонсор, базовый замер текущей боли и доступ к реальным сценариям.

Почтовый сценарий может стать вторым вариантом. Для первого пилота он несет больше технических рисков и рисков безопасности: Exchange, синхронизация, права на ящики, вложения, поиск, хранение, мобильный доступ. Его стоит выбирать первым только при прямом подтверждении, что проблема Outlook является главной внутренней болью.

Умный слой знаний важен для долгосрочного отличия. На первом шаге он слишком зависит от политики доступа к перепискам, письмам, документам и тикетам. Начинать его лучше как контекстный слой под выбранный первый продукт с узким набором данных и понятным допуском.

Главная логика стратегии: сначала внутренний результат, потом внешняя упаковка. Горизонт 1 - внутренний пилот в Т-Банке / Т-Технологиях. Горизонт 2 - тиражирование на внешнюю клиентскую базу Time только после того, как один или два модуля показали внутреннюю ценность, получили владельца, команду и проверенную модель внедрения.

3. Рамка решения

Рынок широких офисных пакетов уже занят: Битрикс24, Яндекс 360, VK WorkSpace, МойОфис, Kaiten, Slack, Microsoft Teams и Mattermost давно развивают офисные и рабочие модули вокруг коммуникации.

Сила продуктовой позиции состоит в выборе первого проверяемого шага:

1. Выбрать первый продукт по вероятности управляемого внутреннего результата.
2. Показать, где именно Time дает преимущество: сообщения, каналы, боты, slash-команды, интерактивные сообщения, OAuth и интеграции.
3. Развести внутренний пилот и внешний продукт, чтобы не смешать разные метрики успеха.
4. Заложить архитектуру так, чтобы внутренняя специфика Т-Банка жила в адаптерах и настройках, а продуктовое ядро могло позже стать частью внешнего Time.
5. Сразу назвать условия остановки или разворота, если гипотеза не подтверждается.
6. Показать модульность по продуктам и ролям сотрудников: юристы, бухгалтерия, продажи, HR, ИТ, продуктовые и операционные команды используют разные рабочие модули поверх одного коммуникационного и контекстного ядра.

4. AS-IS: что Time уже умеет сегодня

Часть заявленной продуктовой гипотезы уже существует в Time явочным порядком. Стратегия должна это зафиксировать, иначе первый продукт выглядит как изобретение с нуля, хотя на деле он формализует уже проявленное поведение сотрудников.

Подтвержденные возможности (полный аудит с источниками вынесен в приложение as-is-capability-audit.md):

1. Плагин Workflow. У Time есть конструктор рутинных процессов без кода: шаблонизация задач, автоматическая отправка форм, например оформление обращения в техподдержку через форму вместо свободного сообщения. Источники: блог Т-Банка про корпоративные мессенджеры и кейсы внедрения.
2. Публично заявленные интеграции. На сайте Time описаны сценарии создания задач в таск-трекерах, обновления статусов в CRM через мессенджер, интеграции по API, Webhook и готовым плагинам. Есть интеграции с TASKS и Confluence (в этом документе обозначаются как TASKS и WIKI), Zoom, Контур.Толк, AmoCRM и Яндекс Трекер.
3. Органический рост ботов. По кейсу Т-Банка на vc.ru сотрудники самостоятельно создали более 2000 ботов и шаблонов процессов для разных задач, от пропуска до маркетинговой акции. По опросам сотрудники чаще получают уведомления о статусе задач в Time, чем в других трекерах.
4. API-документация. Документация Time подтверждает slash-команды, интерактивные сообщения, workflow API, OAuth2, API v4/v5 и WebSocket. Эти механизмы покрывают сценарий "создать действие из сообщения" без создания новой инфраструктуры.

Вывод раздела: первый продукт - это не создание нового паттерна с нуля, а формализация, стандартизация и укрепление уже существующего органического поведения. Сотрудники уже строят ботов и workflow вручную, значит спрос уже проявлен явочным порядком. Этот факт снижает неопределенность первого продукта и должен звучать при защите решения.

5. Два горизонта

Горизонт 1. Внутренний рабочий слой

Цель: повысить ценность Time как рабочей точки входа для сотрудников Т-Банка и Т-Технологий.

Первичный заказчик: внутренний спонсор, который отвечает за рабочую продуктивность, цифровое рабочее место, внутренние инструменты или эффективность команд. Этот спонсор пока не назван, поэтому в документе это фиксируется как ключевое допущение.

Метрики Горизонта 1:

• регулярное использование внутри пилотных команд;
• повторное использование участниками пилота в рабочих сценариях;
• доля задач, созданных из сообщений Time;
• снижение потерь договоренностей в чатах;
• сокращение переключений между Time и внешними рабочими инструментами;
• экономия или удержание затрат на сторонние сервисы, если такие данные подтвердятся;
• готовность команды продолжить использование после пилота без давления сверху.

Главный критерий успеха Горизонта 1: продукт должен стать полезным на реальной внутренней работе до того, как под него попросят большую команду.

Горизонт 2. Time Platform для внешних клиентов

Цель: после внутренней проверки упаковать один или несколько модулей как расширение Time для внешних клиентов SaaS и локального контура.

Метрики Горизонта 2:

• доля существующих клиентов Time, подключивших модуль;
• платящая конверсия на модуль;
• рост среднего счета на клиента;
• снижение оттока клиентов Time;
• скорость внедрения у внешнего клиента;
• стоимость поддержки;
• конкурентная позиция против российских и зарубежных пакетов.

Горизонт 2 является архитектурным ограничением первой версии. Решение должно сохранять путь к внешнему продукту и не замыкаться на закрытый контур Т-Банка.

Стратегия выхода на внешний рынок

Метрики выше описывают результат, но не отвечают на вопросы: в какие сегменты идти первым, через какой канал продавать, по какой цене и как отвечать на возражение "у нас уже есть Kaiten / TASKS". Ниже - рабочая рамка для Горизонта 2. Полный разбор внешней базы Time вынесен в приложение external-market-research.md.

Сегментация внешней базы Time. Существующих внешних клиентов Time можно делить по трем признакам: регулируемые финансовые организации, которым нужен локальный контур и соответствие банковским требованиям; средние технологические компании на SaaS; компании, уже мигрировавшие со Slack / Mattermost / Telegram. Точное распределение базы по этим сегментам пока неизвестно - это открытый вопрос к коммерческой команде Time (см. research-подзадачу в приложении).

Приоритет сегмента для первого внешнего пилота. Вероятно, начинать с той доли внешней базы, которая структурно похожа на Т-Банк: уже интенсивно использует Time и уже испытывает боль с внешними трекерами. Это гипотеза, требующая проверки у коммерческой команды Time, а не готовое решение.

Канал выхода. Наиболее вероятный канал первого шага - существующая команда продаж и аккаунт-менеджмента Time: минимальный дополнительный GTM-бюджет и уже налаженные отношения с клиентами. Отдельный self-serve SaaS-канал требует собственной воронки, онбординга и поддержки, поэтому для первого шага он дороже и медленнее. Сравнение каналов должно быть оформлено до выделения внешнего продукта.

Ценовая гипотеза. Логика ценообразования модуля: надбавка к текущим 350 руб. за лицензию Time в месяц или отдельный SKU для модуля. Это требует отдельного финансового расчета и не является решением на этой стадии.

Конкурентный ответ на возражение "у нас уже есть Kaiten / TASKS". Позиционирование модуля - не замена трекера, а слой синхронизации: действие рождается в Time из сообщения, статус живет в главной системе учета, результат возвращается в канал. Time усиливает существующий трекер, а не конкурирует с ним. Это аргумент для внешних продаж, а не только внутренняя рамка (см. раздел 19 "Конкурентный фон").

Карта продуктовой линейки

Линейка должна строиться как последовательность слоев. Каждый следующий слой добавляется после того, как предыдущий доказал регулярное использование, безопасность и управляемую стоимость.

Отдельно от уровней 0-9 работает облачное хранилище - не последовательный уровень, а сквозной сервис, на который опираются вложения задач, документы, доски, база знаний и почтовые вложения. Его архитектура должна проектироваться параллельно с уровнем 1 (слой действий), даже если сам продукт хранилища запускается позже.

Важно про горизонты: очередность 0-9 - это очередность реализации по сложности и риску, а НЕ автоматическая привязка к горизонту. Большинство модулей относится к Горизонту 1 и лишь позже становится кандидатами на переупаковку в Горизонт 2. Аналитика (уровень 4) и знания (уровень 7) выглядят "вынесенными на последнее место", но это операционная очередь: им нужны события от уже работающего слоя задач, а не стратегическое второстепенное положение.

Эта карта задает последовательность мышления: сначала действие из коммуникации, затем связь с главной системой, затем контекст, затем аналитика, затем домены и знания. Time расширяет свою роль как рабочая точка входа и сохраняет связь со зрелыми системами.

Расчетная база

Открытые данные дают достаточно оснований для первой рамки. Для решения о реализации нужен внутренний замер.

Публичные тарифы конкурентов дают порядок TCO. Для 50 000 пользователей готовые решения класса трекер / пакет совместной работы по открытым ценам могут стоить от сотен млн руб. в год. Внутренняя модель должна учитывать корпоративные скидки, действующие договоры, уже оплаченные лицензии и варианты "купить / построить / партнериться".

Продуктовые развилки

Купить / построить / партнериться / поглотить

Совет по инвестициям почти наверняка спросит: почему строить самим, если рынок задач, документов и коммуникаций уже занят. Поэтому стратегия должна рассматривать четыре варианта.

Для первой версии сильнее выглядит узкий слой действий. Для полноценного трекера, досок, документов, CRM, ERP или ЭДО надо сначала проверить покупку или партнерство.

Оценка подхода по модулям

Общая рамка выше не применяет четыре варианта к конкретным модулям. Ниже - предварительная оценка для каждого модуля линейки. Колонка сложности интеграции выделена отдельно, потому что интеграционная сложность (модель прав, единые сущности, встраивание в интерфейс Time) часто оказывается дороже самой покупки лицензии. Полный разбор вендоров редакторов и досок - в приложении buy-partner-vendor-landscape.md.

Амбиция на 3 года

Амбиция Time Platform на 3 года: стать общей рабочей поверхностью для коммуникации, действий, контекста и статусов.

Эта амбиция строится через доказательство платформенной роли Time. Каждый новый модуль должен иметь владельца процесса, данные, безопасность, экономику и понятный контракт с главной системой учета.

Точка отсчета для метрик зрелости: базовые значения среднего счета Time и уровня оттока клиентов не публикуются и недоступны из открытых источников. До старта пилота их необходимо зафиксировать по внутренним данным (владелец платформы Time): текущий средний счет на клиента, текущий отток по сегментам и эталонная метрика использования рабочих модулей. Без этой базы метрика "рост среднего счета, снижение оттока" не имеет знаменателя, и оценить эффект модулей на Год 3 будет невозможно.

6. Принцип выбора первого продукта

Первый продукт должен пройти четыре проверки:

1. Боль уже есть внутри. Не надо сначала создавать спрос. Нужно найти процесс, где сотрудники уже работают через обходные пути.
2. Ценность видна быстро. Руководитель и пользователи должны увидеть результат на одном сценарии, без многомесячной платформенной стройки.
3. Пилот можно провести малой командой. На старте нет готовой продуктовой команды и набора проработанных гипотез.
4. Модуль создает платформенный фундамент. Даже если первый продукт узкий, он должен накапливать общие сущности: ссылка на сообщение, владелец, статус, контекст, источник, права.

Жесткая остановка для любого первого продукта:

• нет конкретного внутреннего заказчика;
• нет 1-2 пилотных команд;
• нет базового замера текущего процесса;
• нет владельца безопасности и данных;
• ценность нельзя измерить за 4-6 недель;
• первая версия требует полноценной замены Outlook, TASKS, Confluence, Miro, CRM или ERP;
• продукт выбирается из-за знакомого сценария без подтвержденной боли у пилотных команд.

7. Продуктовая гипотеза: задачи из коммуникации

Суть продукта

Первый продукт - слой рабочих задач, который живет рядом с коммуникацией.

Основной сценарий:

1. В канале Time появляется договоренность: "подготовить расчет", "проверить договор", "собрать фидбек", "обновить статус".
2. Пользователь или бот создает задачу прямо из сообщения.
3. Задача получает владельца, срок, ссылку на исходное сообщение, канал, участников и краткий контекст.
4. В рабочей панели виден список задач команды, статусы, просрочки и связь с обсуждениями.
5. При изменении статуса Time возвращает обновление в канал или тред.
6. Контекстный слой сохраняет связь "сообщение - задача - решение - итог", чтобы позже этот же контур стал основой LLM-wiki.

Почему это сильнее для Time

Time уже публично позиционируется как мессенджер с API, Webhook, ботами и интеграциями. На сайте прямо описаны сценарии создания задач в таск-трекерах, онлайн-встреч и обновления статусов в CRM через мессенджер. Первый модуль усиливает этот образ и переводит коммуникацию в рабочее действие.

Что не входит в первую версию

• полноценная замена TASKS, Kaiten или Яндекс Трекера;
• сложная проектная иерархия;
• ресурсное планирование;
• финансовый учет трудозатрат;
• внешняя продажа модуля;
• широкий LLM-доступ ко всем перепискам;
• интеграция с реальными данными Exchange;
• редакторы документов и Miro-like доски;
• без встроенного облачного хранилища: вложения на первом этапе остаются ссылками на исходное сообщение или внешние системы. Это временное ограничение, связанное с будущим сквозным модулем хранилища (см. карту продуктовой линейки в разделе 5), а не самостоятельное решение по файлам.

8. Продуктовая линейка: описание всех модулей

Этот раздел описывает полную карту модулей в едином формате: суть, ценность, плюсы, минусы, когда модуль может стать приоритетным и ключевой риск. Подробные технические модели аналитики и знаний вынесены в приложения team-effectiveness-analytics-model.md и knowledge-module-model.md.

Слой задач из коммуникации (текущий приоритет)

• Суть: задача создается из сообщения Time, получает владельца, срок, статус и ссылку на контекст; статус возвращается в канал.
• Ценность: для сотрудника - договоренность не теряется; для руководителя - прозрачность, кто отвечает, к какому сроку и в каком статусе.
• Плюсы: ближе всего к текущим возможностям Time (раздел 4 AS-IS), низкий риск доступа к данным, быстрый полезный результат.
• Минусы: требует решения, где живет главный статус задачи; риск неявной конкуренции со зрелыми трекерами.
• Когда приоритетен: при подтверждении потерь договоренностей в чатах (развилка в разделе 5).
• Ключевой риск: первая версия распухает в полноценный трекер. Защита - жесткие границы первой версии (раздел 7).
• Полное описание гипотезы - в разделе 7.

Модуль A. Почта внутри Time

• Суть: связка письма, обсуждения в Time и задачи; почта как рабочий сценарий внутри платформы.
• Ценность: для сотрудника - меньше переключений между почтой и чатом; для компании - снижение зависимости от внешнего почтового клиента.
• Плюсы: понятный ежедневный сценарий; высокий управленческий вес, если цель - заместить Outlook.
• Минусы: высокий риск доступа к Exchange и правам на ящики; сложная синхронизация писем, вложений, поиска, календаря; высокая цена ошибки по безопасности.
• Когда приоритетен: только при подтверждении, что Outlook является болью номер один, и наличии тестового Exchange-контура.
• Ключевой риск: сложно сделать честный пилот без настоящих данных.
• Интеграционный подход: партнерство с существующим Exchange-коннектором, не построение с нуля (раздел 5).

Модуль B. Знания и контекст

• Суть: LLM-Wiki - живая база знаний, которую LLM ведет из рабочих событий (чаты, решения, задачи), а сотрудники подтверждают; плюс проектный контекст, поддержка, продуктовые разъяснения, рыночные инсайты, RAG и быстрые прототипы на безопасных данных. Концепция опирается на подход LLM-Wiki Андрея Карпаты: знание - это живой документ с источником и ревизиями, а не мертвый файл.
• Ценность: для сотрудника - ответы на рабочие вопросы без ручного поиска; для руководителя - повторяющиеся вопросы, пробелы в документации и потери контекста.
• Плюсы: самая сильная долгосрочная дифференциация; может стать общим слоем для задач, почты, документов и решений.
• Минусы: высокий риск безопасности; сложно быстро доказать бизнес-эффект; нужна строгая модель доступа к сырому контенту.
• Когда приоритетен: при наличии безопасного внутреннего контура модели и конкретного процесса (адаптация, инциденты, поддержка).
• Ключевой риск: продукт нравится на уровне идеи, но проваливается в регулярном использовании.
• Техническая модель вынесена в knowledge-module-model.md.

Модуль C. Аналитика эффективности команд

• Суть: cycle time, throughput, SDPI, риски, качество, прогноз сроков и стоимость выполнения на основе событий слоя задач.
• Ценность: для сотрудника - личная работа и сроки; для руководителя - поток, риски и прогноз; для владельца продукта - связь коммуникации с задачами и релизами.
• Плюсы: усиливает прозрачность потока без ручного сбора статусов; строит фундамент для управленческого слоя.
• Минусы: риск восприятия как система микроконтроля; требует событий от уже работающего слоя задач.
• Когда приоритетен: после появления событий задач и статусов, не раньше.
• Ключевой риск: модуль превращается в инструмент контроля людей вместо контроля потока.
• Подход: построить (логика тесно связана с моделью событий Time), полная модель - в team-effectiveness-analytics-model.md.

Модуль D. Документы

• Суть: онлайн-редакторы текста, таблиц и презентаций - отдельный продукт по своей природе (аналог МойОфис / Р7 / Яндекс Документы), не функция мессенджера.
• Два режима использования:

1. Embedded-режим внутри Time Platform: просмотр и минимальное редактирование (правки на лету, комментарии, базовое форматирование) прямо в контексте разговора.
2. Полноценная работа: отдельная веб-точка входа с полным набором функций редактора, куда embedded-режим выводит пользователя для глубокой работы.

• Сценарии сквозной интеграции: документ из сообщения открывается как встроенный просмотрщик; из карточки задачи можно прикрепить документ с превью; изменения документа порождают событие в контекстном слое.
• Ценность: сотрудник не покидает рабочий контекст; компания получает российский контур документов.
• Ключевой риск: разработка полноценного редактора с нуля экономически нецелесообразна.
• Подход: не строить редактор, встраивать через партнерство или лицензию существующего движка (раздел 5).
• Альтернативный buy/partner-подход: построить embedded-слой на базе open-source движка (Univer, LibreOffice Online via Collabora CODE, OnlyOffice, La Suite Docs, Grist, Etherpad/HedgeDoc) с российским/IP-контролем. Подробный выбор редакторов и матрица лицензий (AGPL vs MIT/Apache, внутреннее vs коммерческое SaaS) - в opensource-office-editors-research.md на столе.

Модуль E. Доски

• Суть: инструмент визуальной совместной работы (аналог Miro), отдельный продукт, не функция мессенджера.
• Два режима использования:

1. Embedded: простой просмотрщик и легкий редактор досок внутри платформы.
2. Полноценная отдельная веб-точка входа для сложной совместной работы.

• Сценарии сквозной интеграции: доска, созданная в ходе обсуждения в канале, доступна по ссылке из сообщения и карточки задачи; стикер с пометкой "сделать" может превращаться в задачу слоя действий.
• Ценность: визуальная работа связана с задачами и контекстом.
• Ключевой риск: дублирование уже покрытых рынком инструментов.
• Подход: партнерство или лицензия готового решения с embedded-интеграцией (раздел 5).
• Примечание: у Т-Банка есть собственное решение для досок, которое планируется тиражировать на платформу - buy/partner может не подтвердиться, тогда доски подключаются через внутренний продукт.

Модуль F. Облачное хранилище

• Суть: единое хранилище файлов, интегрированное со всеми модулями: вложения задач, документы, доски, база знаний, почтовые вложения.
• Роль в линейке: не последовательный уровень, а сквозной сервис (см. карту продуктовой линейки в разделе 5).
• Ценность: единая модель файлов, прав и сроков хранения вместо разрозненных ссылок.
• Ключевой риск: контур уже покрыт Яндекс.Диском для бизнеса или собственным хранилищем Т-Банка.
• Подход: проверить готовое S3-совместимое решение или существующую инфраструктуру, не строить с нуля (раздел 5).

Модуль G. Видеосвязь (видеозвонки)

• Суть: видеосвязь внутри Time и досок/документов - отдельный модуль, не функция мессенджера.
• Два режима использования:

1. Embedded: переход в видеоконференцию через кнопку в канале, на доске или из задачи.
2. Полноценная точка входа с расписанием, лайвстримом и записью.

• Ценность: сокращение переключений между видеосвязью и действием; статус встречи возвращается в канал.
• Ключевой риск: on-premise решение требует собственного MCU/сервера.
• Подход: buy/partner через on-premise (TrueConf, IVA Technologies - контроль данных, AD/SSO/DLP) для Т-Банка; облачные (Яндекс Телемост, Bitrix24) - для быстрого старта. Подробнее - таблица 3 в buy-partner-vendor-landscape.md.

9. Решение по первому продукту

В этой версии нельзя честно сказать, что матрица уже выбрала первый продукт. Открытые источники подтверждают возможности Time и конкурентный фон, но не подтверждают внутреннюю боль, спонсора, пилотные команды и доступ к данным. Поэтому решение должно идти в два шага.

Шаг 1. Входные условия

Пока хотя бы один из этих пунктов не закрыт, любой выбор остается рабочей гипотезой:

Шаг 2. Весовая оценка после входных условий

После закрытия входных условий проводится оценка по критериям ниже. Если факта нет, ставится 0. Экспертная догадка не заменяет данные.

Предварительная сводка направлений

Эта таблица не заменяет входные условия. Она показывает текущую логику приоритета по открытым данным и экспертным допущениям, чтобы выбор не выглядел интуитивным.

Баллы в таблице - экспертная оценка порядка величины, а не точный замер: диапазон неопределенности каждого чернового балла составляет не менее +/-10 пунктов (например, слой задач - не "72", а интервал "62-72"). Разница между направлениями внутри диапазона не является значимой до появления внутренних данных. Точность появится только после входных условий: заказчик, замер, пилотные команды, API и безопасность.

Почему задачи лидируют даже без финального выбора: они ближе к текущим возможностям Time, требуют меньше доступа к чувствительным данным и быстрее показывают ценность в одном сценарии. Почему это еще не решение: нет внутреннего заказчика, исходного замера, пилотных команд и технической проверки API.

Отдельная качественная ремарка: AS-IS-паттерн Time дополнительно снижает риск первого продукта (см. раздел 4). Более 2000 ботов и workflow, которые сотрудники уже собрали сами, означают, что спрос на автоматизацию действий проявлен явочным порядком, а не гипотетически. Веса и баллы в этой таблице на этом фоне не пересчитываются - без внутренних данных пересчет был бы необоснован, но качественный фактор снижения неопределенности учитывается при интерпретации результатов.

Правило решения:

• 75+ баллов - можно рекомендовать первым продуктом;
• 70-74 балла - короткий список, нужна дополнительная проверка;
• ниже 70 баллов - не брать первым без новых данных;
• отрыв победителя должен быть 5+ баллов;
• выбор должен выдерживать проверку чувствительности при изменении весов на 10-15%.

Текущая продуктовая гипотеза

Сейчас задачи из Time являются самой сильной продуктовой гипотезой для проверки. Финальная рекомендация появится после входных условий. Причина: задачи лучше остальных направлений показывают первый полезный результат, требуют меньше рискованного доступа, естественно встраиваются в коммуникацию и дают общий слой действий для будущих доменных модулей.

Но финальное решение возможно только после входных условий. Если спонсор и пилотные команды подтвердят боль по задачам, этот продукт должен стать первым. Если сильнее подтвердится боль Outlook, первым вариантом станет почтовый сценарий. Если есть согласованный безопасный контур LLM и конкретный процесс, можно вернуться к умному слою знаний.

Что именно делаем с задачами

Первый продукт не должен быть новым главным трекером компании. На первом этапе это слой захвата и координации задач из коммуникации.

Варианты режима:

1. Без внешнего трекера: Time хранит легкую задачу для пилотного сценария. TASKS, Kaiten или Яндекс Трекер остаются зрелыми системами проектного учета.
2. С внешним трекером: Time создает задачу из сообщения и синхронизирует ее с текущей системой, а внешний трекер остается главным источником статуса.
3. Смешанный режим: Time хранит контекст, источник, обсуждение и уведомления, а доменная система хранит профильную часть задачи.

Режим легкой задачи внутри Time допустим только для пилота в командах без зрелого трекера. В него не должны входить сложные доски, спринты, иерархии, ресурсное планирование, отчеты и миграции.

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

10. Модульная модель по ролям и подразделениям

Time Platform не должна развиваться как одно большое приложение со множеством функций. Более сильная модель: единое ядро коммуникации, задач, событий, прав, поиска, аудита и контекста плюс набор доменных модулей для разных групп сотрудников.

Общие платформенные сущности

Эти сущности должны быть общими для всех модулей:

• пользователь, команда, роль, гость, сервисный аккаунт;
• канал, сообщение, тред, источник;
• задача, владелец, статус, срок, приоритет;
• событие, уведомление, действие, журнал;
• документ, ссылка, версия, главная система учета;
• контекст, резюме, связанный артефакт;
• политика доступа, срок хранения, аудит, юридическое удержание;
• интеграционный адаптер и вебхук.

Доменные модули

Контракт доменного модуля

Каждый будущий модуль должен быть описан до разработки. Минимальный контракт:

• группа пользователей и главный процесс;
• текущая главная система учета;
• объект домена: договор, счет, сделка, заявка, соискатель, инцидент;
• событие, которое запускает действие из Time;
• минимальные поля объекта;
• кто может видеть объект, контекст и историю;
• где хранится финальный статус;
• как работает синхронизация;
• что пишется в аудит;
• что удаляется и что хранится по правилам компании;
• метрика пилота;
• владелец результата;
• условие остановки.

Приоритет модулей задают пять факторов:

• есть владелец со стороны бизнеса;
• боль повторяется часто;
• эффект можно измерить за 4-6 недель;
• интеграция не требует опасного доступа;
• модуль переиспользует общий слой задач, контекста, прав и событий.

На этой стадии нельзя выбрать первый доменный модуль между юристами, финансами, продажами, HR и ИТ. Для такого выбора нужны владельцы интеграций: CRM, ERP, ЭДО, договорной контур, HR-система или служба заявок. Если владельца системы нет, доменный модуль нельзя ставить в план первой реализации.

Принцип: не заменять зрелые системы сразу

ERP, CRM, система договоров и ЭДО не должны становиться первыми самостоятельными продуктами Time. На первом этапе сильнее делать тонкие рабочие поверхности и адаптеры:

• показать статус из первичной системы;
• создать задачу или согласование;
• вернуть результат в канал;
• сохранить связь с контекстом;
• не копировать весь домен в Time.

Так Time становится рабочим слоем вокруг коммуникации, где сотрудник видит действие, контекст и ответственного.

Как это влияет на первый продукт

Слой задач является сильной гипотезой первого шага, потому что при подтверждении внутренней боли он может дать общий механизм действий для многих доменных модулей:

• договор требует задач и согласования;
• счет требует проверки и статуса;
• сделка требует следующего действия;
• инцидент требует ответственных;
• HR-процесс требует шагов и сроков;
• закупка требует владельца и контроль.

Именно поэтому первый продукт лучше строить как общий слой действий. Позже к нему подключаются юридические, финансовые, CRM, ERP и HR сценарии.

Роль модулей аналитики эффективности и знаний в ролевой модели: они не привязаны к одной роли, а усиливают всех сотрудников и руководителей поверх слоя задач. Подробные описания этих модулей перенесены в раздел 8 "Продуктовая линейка" (модули B и C), а полные технические модели остаются в приложениях team-effectiveness-analytics-model.md и knowledge-module-model.md. В разделе 10 ролевая модель отвечает только на вопрос "какая роль в компании что получит".

11. Пилот: формат и критерии

Цель пилота

Проверить, могут ли задачи, созданные из сообщений Time, снизить потери договоренностей и сделать работу команды прозрачнее без перехода в отдельный трекер.

Состав пилота

Минимальный состав:

• 2 команды;
• 30-100 активных пользователей;
• 1 внутренний спонсор;
• 1 владелец продукта;
• 1 инженер интеграций;
• 1 инженер фронтенда;
• 1 инженер бэкенда;
• аналитическая функция у владельца продукта и разработчиков;
• сотрудник ИБ на контрольных точках, shared role.

Если команды нет, можно начинать прототип и предварительное исследование, но нельзя называть это боевым пилотом.

Основные метрики

Пороги ниже являются рабочими ориентирами. Финальные цели надо утвердить после исходного замера в пилотных командах. Иначе метрики будут выглядеть точными, но не будут связаны с реальной болью.

Как считать:

• недельное использование = пользователи с хотя бы одним полезным действием за неделю / все участники пилота;
• доля задач из Time = задачи, созданные из сообщения или через команду Time / все задачи выбранного сценария;
• потерянная договоренность = договоренность в канале, у которой через 24 часа нет владельца, срока или статуса;
• время до назначения = время от сообщения с договоренностью до задачи с владельцем;
• ручные напоминания = сообщения вида "кто делает", "какой статус", "не забыли" по выбранному типу работ;
• желание оставить модуль = доля пользователей, которые отвечают "оставить" или "без него стало бы хуже" после пилота.

Метрики использования:

• 65%+ участников пилота открывают модуль каждую неделю;
• 40%+ новых задач создаются из сообщений Time;
• 70%+ задач имеют владельца и статус;
• 50%+ задач имеют ссылку на исходное сообщение или тред;
• 60%+ пользователей пилота хотят оставить модуль после окончания проверки.

Метрики качества процесса:

• снижение числа "потерянных договоренностей" по самооценке команды на 25%+;
• снижение ручных напоминаний в чатах по выбранным типам задач на 20%+;
• время от договоренности в чате до назначенной задачи менее 60 секунд для базового сценария;
• доля задач без владельца через 24 часа меньше 10%.

Метрики внедрения:

• подключение новой пилотной команды без разработки за 1-2 рабочих дня;
• обучение команды за 30 минут;
• не более 0,1 критичного обращения в поддержку на активного пользователя в неделю;
• нет P1 инцидентов по доступам и утечкам.

Продолжение, разворот или остановка

Продолжение:

• есть подтвержденный внутренний спонсор;
• есть 2 команды, готовые использовать продукт на реальных процессах;
• безопасность разрешает выбранный объем данных;
• 4 недели использования дают 65%+ регулярного недельного использования;
• пользователи создают 40%+ задач из Time;
• команды просят оставить продукт после пилота;
• есть понятный запрос на команду следующего этапа.

Разворот:

• регулярное использование есть, но связь с исходным сообщением не стала привычной;
• команды просят синхронизацию с текущим трекером как главный сценарий;
• ценность видна только для отдельных ролей;
• безопасность ограничивает часть контекста, но не блокирует базовый сценарий.

Остановка:

• нет внутреннего спонсора;
• нет доступа к пилотным командам;
• безопасность запрещает хранение связей между сообщениями и задачами;
• регулярное недельное использование ниже 30%;
• пользователи возвращаются в старый трекер без явной причины;
• нет экономического или процессного эффекта после полного пилота.

12. Engagement и удержание использования

Метрики раздела 11 отвечают на вопрос "как измерить использование", но не на вопрос "почему сотрудник продолжит пользоваться модулем через месяц, а не откатится к ручным напоминаниям в чате". Раздел про вовлечение нужен, чтобы удержание не осталось случайностью.

Опора на органический паттерн Time

У Time уже есть готовый канал вовлечения: более 2000 ботов и шаблонов процессов, которые сотрудники Т-Банка создали сами (источник - кейс на vc.ru, см. раздел 4 AS-IS). Это значит, что модуль задач не надо "продавать" сверху. Достаточно дать инструментарий тем же сотрудникам, которые уже строят ботов, чтобы они сами встроили слой задач в свои существующие workflow. Первый продукт усиливает поведение, которое уже есть, а не создает новое.

Онбординг без трения

Создание задачи должно быть доступно в 1 действие из уже знакомого интерфейса:

• slash-команда в канале;
• реакция на сообщение;
• кнопка в интерактивном сообщении.

Без обучающих сессий длиннее уже заявленных 30 минут (перекрестная ссылка на метрики внедрения в разделе 11).

Петля обратной связи в канал

Статус задачи возвращается туда же, где родилась договоренность (сценарий раздела 7). Это ядро вовлечения, а не просто технический сценарий: пользователь видит результат своих действий в привычном месте и не переключается в отдельное приложение.

Модель "чемпионов"

В каждой пилотной команде выделяются 1-2 активных пользователя, которые получают более ранний доступ и прямую обратную связь с продуктовой командой. Это организационный элемент, перекрестная ссылка на раздел 17 "Организационная модель".

Что явно не делать

• не вводить принудительные механики: обязательные напоминания сверху, штрафы за неиспользование;
• не превращать модуль в инструмент контроля. Тот же принцип, что уже зафиксирован для модуля аналитики в разделе 8: "не как контроль людей, а как контроль потока", переносится и на слой задач.

Метрика вовлечения сверх метрик использования

Отдельно от метрики "40%+ задач создаются из сообщений Time" вводится показатель добровольного повторного создания задачи без напоминания модуля. Он измеряет отсутствие внешнего побуждения и показывает, что модуль стал привычным инструментом, а не разовой акцией.

Собранные примеры программ вовлечения (Slack Champion program, Microsoft Teams adoption playbooks, Power Platform CoE, кейсы Rabobank, Danske Bank и KeyBank) вынесены в приложение engagement-research.md.

13. План этапов

Фаза 0. Предварительное исследование и защита первого хода

Цель: снять ключевые неопределенности до разработки.

Что сделать:

• интервью с потенциальным внутренним спонсором и владельцем платформы Time;
• 5-8 интервью с командами, где много договоренностей в Time;
• инвентаризация текущих трекеров, вики, почтовых клиентов и обходных практик;
• проверка доступности Time API, slash-команд, интерактивных сообщений, OAuth;
• проверка требований безопасности к ссылкам на сообщения и хранению контекста;
• короткая техническая проверка Time API в тестовом контуре;
• финальная матрица выбора продукта.

Выход:

• решение по первому продукту;
• список пилотных команд;
• согласованный объем данных;
• отчет технической проверки API;
• критерии продолжения и остановки;
• прототипный сценарий.

Техническая проверка до пилота

До пилота нельзя опираться только на описание API и возможности с сайта. Нужна короткая техническая проверка в тестовом контуре Time.

Что надо доказать:

• можно создать действие из сообщения или команды Time;
• можно сохранить ссылку на исходное сообщение и открыть ее с проверкой прав;
• права на канал проверяются при каждом чтении задачи;
• можно вернуть статус обратно в канал или тред;
• повторная отправка события не создает дубли;
• есть повторная доставка для временных ошибок;
• понятны лимиты нагрузки API;
• есть события удаления сообщения, канала, задачи или внешнего объекта;
• есть журнал действий, достаточный для аудита;
• понятно, чем отличается SaaS и локальный контур;
• есть владелец платформы Time, который подтверждает доступность этих сценариев.

Если эта проверка не проходит, первая версия не начинается. В таком случае можно делать только визуальный прототип и возвращаться к выбору сценария.

Фаза 1. Прототип для управленческого решения

Цель: показать один связный сценарий, который объясняет ценность.

Сценарий:

Сообщение в Time - создание задачи - назначение владельца - карточка с контекстом - статус обратно в канал - краткий итог в контекстном слое.

Что не доказывает прототип:

• производительность;
• реальную безопасность;
• полный пользовательский опыт Time;
• готовность к боевому внедрению;
• замену TASKS, Kaiten или Яндекс Трекера.

Что доказывает прототип:

• понятность сценария;
• силу связки сообщения и задачи;
• ценность контекста;
• направление продукта;
• материал для разговора со спонсором и пилотными командами.

Фаза 2. Внутренняя первая версия

Цель: дать пилотным командам минимальный рабочий продукт.

Первая версия включает:

• создание задачи из сообщения;
• владельца, статус, срок, приоритет;
• ссылку на исходный канал, сообщение и тред;
• список задач команды;
• личный список задач;
• уведомление в Time при изменении статуса;
• базовый поиск;
• права доступа на основе команды, канала и роли;
• журнал действий;
• базовую аналитику регулярного использования.

Жесткие границы первой версии:

• не более 5-7 полей задачи;
• 3-4 статуса без настройки сложных процессов;
• без досок, спринтов и иерархий;
• без зависимостей между задачами;
• без импорта и миграций;
• без отчетов для руководителей;
• без комментариев внутри задачи, обсуждение остается в Time;
• без вложений внутри задачи, используется ссылка на исходный контекст;

Где физически живут вложения на первом этапе: файл не копируется в хранилище платформы. Задача хранит ссылку на исходное сообщение Time и/или на объект внешней системы (письмо, документ, заявку). Сам файл продолжает храниться там, где он был создан: в сообщении Time, в почтовом ящике, в Яндекс.Диске для бизнеса или в контуре Т-Банка. Вложение копируется в управляемое хранилище только на этапе сквозного модуля облачного хранилища (Модуль F, см. карту линейки в разделе 5), когда появится модель прав и сроков хранения. До этого момента DLP и доступ к файлу регулируются правилами той системы, где файл создан.

• без копирования доменного объекта из CRM, ERP, ЭДО или службы заявок.

Не включать:

• сложные доски и диаграммы;
• ресурсное планирование;
• массовые миграции;
• широкий LLM по всем источникам;
• внешнюю упаковку.

Фаза 3. Пилот и решение о команде

Цель: проверить, стоит ли защищать отдельную команду под продукт.

Контрольные вопросы:

• кто владелец продукта внутри;
• кто платит за развитие;
• сколько команд хотят подключиться после пилота;
• какие сторонние инструменты можно реально заместить;
• какие интеграции критичны;
• какие ограничения безопасности стали постоянными;
• какие метрики держатся без ручного подталкивания.

Решение:

• продолжить - выделить продуктовую команду и расширять модуль;
• развернуть - сделать интеграционный слой к текущему трекеру;
• остановить - закрыть модуль и оставить выводы для других продуктов.

Фаза 4. Расширение платформы

После успешного пилота можно выбирать второй модуль:

1. Один адаптер к выбранному трекеру, если он является главной системой статуса.
2. Один доменный адаптер, если у него есть владелец системы, бюджет, модель данных и согласование безопасности.
3. LLM-контекст как усиление задач, только без доступа к сырым перепискам по умолчанию.
4. Почта внутри Time, только если подтвержден сильный спрос и есть безопасный доступ к Exchange.
5. Документы и доски, только как рабочие поверхности вокруг уже созданных задач и контекста.

Запрещено запускать несколько тяжелых направлений параллельно. После первой версии разрешен только один внешний адаптер за раз. CRM, ERP, ЭДО и Exchange не входят в первые релизы без отдельного владельца системы, бюджета, модели данных и финального согласования безопасности.

Фаза 5. Подготовка Горизонта 2

Переход к внешней упаковке возможен только если:

• внутренний модуль стабилен;
• есть выделенная команда;
• есть повторяемый процесс внедрения;
• продукт не завязан на внутренние системы Т-Банка в ядре;
• есть спрос от действующих клиентов Time;
• известна цена поддержки и внедрения;
• есть понятная модель лицензирования.

14. Архитектурная рамка

Слои

1. Time как коммуникационный слой: каналы, сообщения, треды, реакции, боты, slash-команды, интерактивные сообщения.
2. Модуль задач: задача, владелец, статус, срок, приоритет, ссылка на источник, журнал действий.
3. Контекстный слой: связи между сообщениями, задачами, решениями и артефактами.
4. Доменные модули: юридический, финансовый, CRM, HR, ИТ, продуктовый, закупочный.
5. Интеграционные адаптеры: Time API, Webhook, OAuth, текущие трекеры, Exchange, CRM, ERP, ЭДО, служба заявок.
6. Общая шина событий: события, повторная доставка, защита от дублей, очередь проблемных событий, лимиты нагрузки, сквозной идентификатор.
7. Управление доступом и аудит: роли, наследование прав, журнал действий, сроки хранения.
8. Контур политик: проверка доступа, классификация данных, LLM-фильтры, запрет опасных действий.
9. Аналитика: регулярное использование, путь создания задач, использование командами, ошибки, качество данных.

Что должно быть продуктовым ядром

• модель задачи;
• связь задачи с источником;
• статусная модель;
• права и аудит;
• события и уведомления;
• аналитика;
• интерфейс адаптеров;
• модель контекста;
• каталог модулей;
• интерфейс доменного адаптера;
• модель событий;
• контур политик.

Что должно быть адаптером

• конкретные поля Т-Банка;
• внутренние оргструктуры;
• интеграции с конкретными системами;
• правила пилотных команд;
• правила срока хранения для отдельных контуров;
• брендовые и визуальные настройки.
• коннекторы к CRM, ERP, ЭДО и внутренним системам;
• доменные рабочие процессы конкретных подразделений.

Такой подход сохраняет внутренний фокус, но не блокирует будущий внешний продукт.

Контракт внешней интеграции

Любая интеграция с TASKS, Kaiten, Yandex Tracker, CRM, ERP, ЭДО или службой заявок должна проходить отдельный технический контракт.

Минимальный контракт:

• одна выбранная система на этап;
• владелец системы и владелец API;
• главная система статуса;
• карта полей;
• карта статусов;
• правило разрешения конфликтов;
• правила доступа;
• лимиты API;
• повторная доставка событий;
• защита от дублей;
• журнал изменений;
• порядок удаления и архивирования;
• сотрудник поддержки, shared role.

Для первого шага доменные системы работают только в режиме "создать, связать, прочитать статус". Нельзя копировать весь договор, сделку, счет, акт или инцидент внутрь Time.

Различия SaaS и локального контура

Если функция не может работать в обоих контурах без переписывания ядра, ее нельзя считать частью будущей внешней платформы.

15. Безопасность и требования

Для продуктовой проверки безопасность нужно вести с первого шага. В продуктах вокруг коммуникации она является частью продукта.

Регуляторный периметр

Этот раздел не является юридическим заключением. Его задача - заранее показать, какие проверки нужны до пилота в банковском и технологическом контуре.

Вывод для первой версии: пилот на реальных данных начинается после назначения владельца данных, сотрудника ИБ, SRE инженера и сотрудника поддержки. ИБ, эксплуатация и поддержка на этом этапе являются shared roles, их контрольные точки обязательны.

Контроль безопасности до пилота

До боевого пилота нужны отдельные артефакты:

• модель угроз для сценария "сообщение - задача - контекст - внешний источник";
• классификация данных: обычные рабочие данные, персональные данные, чувствительные данные, банковская тайна, гостевые каналы;
• схема доступа: кто видит заголовок задачи, описание, исходное сообщение, вложения, резюме и историю изменений;
• правила для производных данных: резюме, индексы, векторные представления, ссылки на источники, кэшированные ответы;
• политика удаления: что происходит при удалении сообщения, задачи, канала, пользователя или внешнего объекта;
• юридическое удержание и срок хранения: что нельзя удалять и кто принимает решение;
• DLP-проверка для заголовков, описаний, вложений, экспорта и логов;
• защита от подмены инструкций в письмах, документах, вики-страницах и сообщениях;
• модель инцидентов: уровень критичности, срок реакции, владелец коммуникации;
• финальное согласование от владельца безопасности и владельца данных.

Без этих артефактов можно показывать прототип, но нельзя идти в боевой пилот с реальными данными.

Минимальный пакет допуска к пилоту:

Рабочий срок подготовки такого пакета для ограниченного пилота: 1-2 недели при наличии владельцев данных и безопасности. Если владельцы не названы, этот срок не планируется и пилот нельзя обещать.

Базовые принципы:

• задача не должна раскрывать сообщение пользователю, который не имеет доступа к исходному каналу;
• ссылка на сообщение должна проверяться при каждом обращении;
• права на задачу должны учитывать команду, канал, автора, владельца и гостей;
• любые действия должны попадать в журнал аудита;
• удаление сообщения или канала должно иметь понятное влияние на связанные задачи;
• LLM-слой не получает сырые переписки без отдельного разрешения;
• векторные индексы, резюме и сжатый контекст должны наследовать права исходных данных;
• для локального контура нужен режим без внешних моделей и без передачи данных наружу;
• в прототипе все данные должны быть демонстрационными и явно помеченными;
• сервисные аккаунты не должны иметь широкий доступ "на все";
• вебхуки должны быть подписаны, защищены от повторной отправки и иметь повторную доставку с контролем дублей;
• все LLM-действия должны проходить через контур политик;
• поиск и контекст должны применять права в момент запроса.

LLM-ограничения для первых этапов:

• LLM выключен по умолчанию;
• LLM не получает сырые переписки без отдельного разрешения;
• LLM не меняет статусы и не создает действия без подтверждения человека;
• все ответы должны иметь ссылку на источник;
• нужен набор проверочных примеров качества;
• нужен лимит стоимости на пользователя или команду;
• нужен лимит задержки ответа;
• нужна защита от подмены инструкций в сообщениях и документах;
• нужен журнал обращений к контексту.

Роли и правила доступа:

• администратор платформы;
• администратор организации;
• администратор приложения;
• владелец рабочего пространства;
• владелец команды;
• участник;
• гость;
• бот или сервисный аккаунт;
• аудитор;
• сотрудник безопасности.

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

Условия, при которых LLM-wiki нельзя делать первым продуктом:

• нет утвержденной модели прав на смешанные источники;
• нет решения по хранению векторов и резюме;
• нет разрешенного LLM-контура;
• нет политики удаления данных;
• нет аудита обращений к контексту;
• нет понятного сценария, где ценность видна без доступа ко всем данным.

16. Экономическая модель

Точная экономия появится только после внутренних данных. Продуктовая стратегия показывает, как считать экономику и какие данные собрать.

Формула эффекта

TCO-диаграмма сравнивает открытые тарифы 430, 580 и 819 руб. в месяц на масштабах 1 000, 10 000 и 50 000 пользователей.

График эффекта времени использует допущение 18 рабочих дней и 2 500 руб. за час. Это рамка для пилотного замера.

Эффект пилота = экономия времени + снижение потерь задач + возможная экономия лицензий + снижение операционного риска - стоимость внедрения и поддержки.

Пример расчета для проверки порядка величины:

• 100 пользователей пилота;
• 8 минут экономии в день на человека за счет создания задач из Time и меньшего числа ручных напоминаний;
• 18 рабочих дней в месяц;
• 2 500 руб. условная стоимость часа сотрудника.

Месячный эффект = 100 * 8 / 60 * 18 * 2 500 = 600 000 руб.

Это расчетная рамка. Ее нужно заменить фактическими данными пилота.

Рыночная рамка TCO

Открытые тарифы показывают порядок затрат, с которыми будут сравнивать внутреннюю разработку. Крупные клиенты получают скидки, часть лицензий уже может быть куплена, а локальные поставки часто считаются отдельно. Такая рамка нужна, чтобы защищать команду с числами.

Порог для внутренней разработки: если модуль не заменяет лицензии напрямую, он должен давать измеримый эффект времени, качества или риска. Без подтвержденного эффекта разработка остается продуктовой гипотезой.

Ориентир стоимости построения (build)

Для честного сравнения "купить против построить" нужна и сторона внутренней разработки. Ориентир на первый MVP слоя задач: команда из 2-3 разработчиков, 1 дизайнера и 1 продакта на 2-3 месяца, то есть 5-8 человеко-месяцев. При условной стоимости команды 1,2-1,8 млн руб. за человеко-месяц (бэкенд, интеграции, безопасность, тесты, администрирование контура) разовые затраты на первый продукт составляют примерно 6-15 млн руб. без учета поддержки. Это сопоставимо с годовым TCO покупного трекера на 1-2 тыс. пользователей (см. таблицу выше), но без лицензионных платежей и с полным контролем интеграций с Time. Постоянные затраты на сопровождение и доработку оцениваются в 15-25% от стоимости разработки в год. Точные цифры появятся после оценки ресурсов пилотной команды и зафиксированной стоимости часа.

Сценарии эффекта от времени

Для оценки порядка величины используется допущение: 18 рабочих дней в месяц и 2 500 руб. условная стоимость часа сотрудника. Это расчетная переменная для защиты модели.

Главный смысл таблицы: даже малое сокращение ручной координации может дать крупный расчетный эффект на масштабе Time. Но защищать можно только тот эффект, который будет подтвержден исходным замером и пилотом.

Чистый эффект для защиты команды

Для решения о команде нужен чистый эффект с учетом затрат, рисков и стоимости поддержки.

Чистый эффект = подтвержденная экономия + подтвержденное снижение риска + подтвержденное замещение инструментов - стоимость разработки - стоимость эксплуатации - стоимость поддержки - стоимость внедрения - стоимость изменения привычек - стоимость отвлечения команды от других задач.

Разделять надо два типа эффекта:

• денежный эффект, который реально высвобождает бюджет;
• эффект продуктивности, который улучшает работу, но не всегда превращается в прямую экономию.

Команду стоит защищать только если есть хотя бы один из трех сигналов:

• внутренний спонсор готов платить из своего бюджета;
• есть подтвержденное расширение на новые команды;
• есть понятный денежный или рисковый эффект, который больше стоимости следующего этапа.

Для защиты следующего этапа надо заранее назвать диапазон затрат:

Точка окупаемости для внутреннего решения: подтвержденный денежный эффект или снижение риска должны покрывать стоимость следующего этапа за согласованный период. Если эффект только в продуктивности, решение о продолжении должно принимать подразделение, которое готово платить за этот эффект своим бюджетом.

Верхняя граница сроков и затрат

Срок 4-6 недель относится к измерению пилота после запуска.

Рабочие границы:

Если первая версия требует больше 12 недель до пилота, объем надо сокращать и выносить часть функций в следующие этапы.

Какие данные собрать до защиты команды

• сколько команд используют внешние трекеры;
• какие роли и подразделения используют какие системы: CRM, ERP, договоры, ЭДО, служба заявок;
• сколько платных лицензий реально можно заменить;
• сколько задач теряется или дублируется в чатах;
• сколько времени уходит на ручное создание задач из переписок;
• сколько стоит поддержка текущего процесса;
• сколько стоит поддержка нового модуля;
• сколько команд готовы подключиться без продажи сверху.

17. Организационная модель

На старте нельзя исходить из того, что команда уже есть. Значит стратегия должна включать рост команды по мере доказательства ценности.

До пилота

Минимальная группа:

• владелец продукта;
• технический лидер Time;
• архитектор или старший разработчик;
• сотрудник ИБ, shared role;
• SRE инженер, shared role;
• сотрудник поддержки, shared role;
• представитель внутреннего спонсора;
• 1-2 пилотные команды.

Роль владельца продукта и технического лидера можно объединить в роль технического владельца продукта. Для Time это может быть сильнее на старте: один человек держит сценарий, границы первой версии, API, риски и критерии готовности.

Первая версия

Минимальная команда:

• технический владелец продукта;
• технический руководитель;
• инженер бэкенда;
• инженер фронтенда;
• аналитическая функция у технического владельца продукта и разработчиков;
• дизайнер на частичную занятость;
• QA на частичную занятость;
• SRE инженер на контрольных точках, shared role;
• сотрудник поддержки, shared role;
• владелец платформы Time;
• владелец каждого внешнего API, если есть интеграция;
• исследователь пользовательского опыта на частичную занятость;
• сотрудник ИБ и требования на контрольных точках, shared role.

После успешного пилота

Полная команда:

• продуктовый менеджер;
• руководитель разработки или технический руководитель;
• 2 инженера бэкенда;
• 2 инженера фронтенда;
• QA;
• продуктовая аналитика внутри команды или shared role;
• дизайнер;
• специалист по внедрению для внутренних команд;
• сотрудник ИБ, shared role;
• SRE инженер;
• сотрудник поддержки;
• архитектор на ревью.

Команда второго модуля появляется только после того, как первый модуль показал удержание и понятный спрос.

Ответственность за пилот

Перед стартом пилота для каждой строки должны быть названы роли, конкретные владельцы и заместители. Если для строки нет владельца решения, этап нельзя считать готовым к запуску.

18. Риски

19. Конкурентный фон

Российские пакеты и открытые тарифы

Вывод из конкурентного анализа

1. Ширина пакета уже не является сильным отличием. На рынке есть игроки с почтой, задачами, документами, досками, CRM и локальными поставками.
2. Сильное место Time - рабочая коммуникация, принятая в крупной организации, и публично заявленные интеграции с задачами, встречами и CRM.
3. Первый модуль должен защищаться через снижение потерь между сообщением, владельцем, сроком и статусом.
4. Для внешнего рынка надо считать цену модуля, рост среднего счета Time, снижение оттока, стоимость поддержки и сложность локальной поставки.
5. Для внутреннего рынка надо сравнивать с уже купленными договорами. Если договоры уже оплачены, экономия лицензий может быть нулевой, и ценность должна доказываться временем, качеством и снижением риска.

Зарубежные модели

Slack показывает, что мессенджер может быть платформой приложений и автоматизации.

Microsoft Teams с Loop, Planner и Outlook показывает модель работы "в потоке", где задачи и компоненты живут рядом с коммуникацией.

Mattermost важен как близкий отраслевой пример: у него есть Boards, Playbooks, интеграции, плагины, API, права и локальные сценарии.

Материалы для сайта стратегии

Для лендинга стратегии нужны визуальные материалы, которые помогают принять решение:

Версия: 1.0 Назначение: дать прозрачное правило выбора первого продукта и отделить факты от экспертной оценки

1. Главное правило

Первый продукт выбирается по вероятности доказать ценность внутри Т-Банка / Т-Технологий при малой команде, понятном владельце результата и контролируемом риске.

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

2. Шаг 1. Входные условия

До подсчета баллов каждая идея проходит входные условия. Если хотя бы одно условие не выполнено, идея остается в статусе гипотезы и не может быть рекомендована как первый продукт.

3. Шаг 2. Весовая оценка

Оценка проводится только после входных условий. Шкала: 0-5. Если факта нет, ставится 0. Экспертная догадка фиксируется отдельно.

Сумма весов: 100.

После базовой оценки применяются технические штрафы. Они не должны прятаться внутри общей оценки, потому что именно они чаще всего увеличивают сроки и стоимость.

4. Рабочие направления

5. Текущая продуктовая гипотеза

На текущих данных наиболее сильная гипотеза: начать со слоя задач и договоренностей из Time.

Важно: первый продукт работает как слой захвата и координации действия из коммуникации. TASKS, Kaiten, Yandex Tracker, CRM, ERP и договорная система остаются главными системами учета, если уже выполняют эту роль.

Возможны три режима:

Для зрелой корпоративной стратегии предпочтительны второй и третий режимы. Они снижают риск конкуренции со зрелыми системами и делают Time рабочей поверхностью.

6. Правила остановки

Гипотезу нужно остановить, если:

• нет внутреннего заказчика;
• эффект не измеряется за 4-6 недель;
• для первой версии нужна полная замена зрелой системы;
• нет владельца доступа, данных и безопасности;
• непонятно, где главный статус задачи или объекта;
• выигрыш держится на знакомом прошлом опыте без подтвержденной боли;
• пользователи не готовы менять поведение даже в узком сценарии.

7. Модульность и доменные слои

Слой задач получает высокий платформенный вес только в том случае, если он создает общий контракт для будущих доменных модулей.

Каждый доменный модуль должен заранее описать:

• целевую группу пользователей;
• текущую систему учета;
• главную систему статуса;
• событие, которое запускает действие;
• минимальные поля объекта;
• правила доступа;
• аудит действий;
• схему синхронизации;
• метрику пилота;
• владельца со стороны бизнеса;
• условие остановки.

Примеры модулей:

Версия: 1.0 Источник: документ "Эффективность команд" Назначение: описать отдельный модуль Time Platform для сотрудников, руководителей команд, руководителей программ и владельцев продуктов

1. Роль модуля

Модуль аналитики эффективности команд показывает, как работа проходит через поток: сколько задач входит в процесс, сколько выходит, где появляются задержки, как меняется качество, насколько команда предсказуема и какие риски уже видны руководителю.

Для сотрудников этот модуль должен помогать видеть собственную работу без ручного сбора статусов. Для руководителей он должен отвечать на вопросы про сроки, загрузку, качество, риски и зависимые команды. Для владельцев продукта он должен связывать коммуникацию Time с рабочими артефактами в TASKS, репозиториях, службах заявок, CRM, ERP и других системах.

Главная продуктовая роль для Time: превращать коммуникацию, задачи и статусы в понятную картину исполнения. Этот модуль не должен становиться системой микроконтроля. Его ценность в прозрачности потока, раннем выявлении рисков и снижении ручных статусных встреч.

2. Кому это нужно

3. Набор отчетов

Модуль должен развиваться в несколько слоев. Первый слой дает базовую аналитику пилота, следующий слой подключает полноценные графики потока и качества.

4. SDPI и инсайты

SDPI, Software Development Performance Index, можно использовать как индекс эффективности команды. Он собирает четыре измерения:

• производительность;
• предсказуемость;
• скорость реакции;
• качество.

Каждое измерение может считаться через набор метрик и процентилей. Для части команд важнее абсолютные значения, например throughput 40-50 задач за период. Для руководителей полезнее сравнение с прошлым периодом, соседними командами или портфелем.

В Time Platform это должен быть не рейтинг сотрудников. Это индекс состояния командного потока. Он помогает понять, где команде нужен процессный ремонт, помощь зависимой команды, снижение WIP, доработка качества или пересмотр скоупа.

5. Данные и доступы

Модуль требует строгой модели доступа:

• пользователь видит только задачи, проекты и сообщения, к которым у него есть права;
• агрегаты строятся с учетом прав пользователя отчета;
• персональные данные в сводных отчетах маскируются по правилам роли;
• руководитель видит командный уровень, если это разрешено оргструктурой и владельцем данных;
• raw events доступны только владельцам данных, сотруднику ИБ и техническим ролям в рамках допуска;
• данные из репозиториев, задач, заявок и коммуникаций связываются через идентификаторы и события, с аудитом доступа.

6. MVP аналитики в прототипе

Для первого веб-прототипа достаточно показать:

1. SDPI-панель по роли руководителя.
2. Cycle time и throughput в одном компактном блоке.
3. Риск по эпикам и зависимостям.
4. Список причин риска, связанных с сообщениями и задачами.
5. Настройки доступа: личный уровень, командный уровень, портфельный уровень.
6. Связь с модулем знаний: объяснение метрики, источник данных, возможные действия.

Этого достаточно, чтобы показать новый модуль как часть Time Platform и не уходить в тяжелую систему отчетности на первом шаге.

Версия: 1.0 Назначение: подробно описать слой знаний Time Platform как основу базы знаний, поддержки, контекста, RAG, инсайтов и быстрых прототипов

1. Роль модуля

Модуль знаний является ключевым стратегическим слоем Time Platform. Он связывает коммуникации, задачи, решения, документы, продуктовые описания, клиентский контекст, исследования рынка и внутренние правила компании.

Центральный механизм модуля - LLM-Wiki: живая база знаний, которую LLM ведет автоматически из рабочих источников (чаты, решения, задачи, обсуждения, тикеты), а сотрудники подтверждают и дополняют. Концепция опирается на подход Андрея Карпаты: знание компании должно быть не набором мертвых документов, которые никто не обновляет, а постоянно актуализируемой wiki, где каждая статья - живой документ с источником, ревизиями и владельцем. LLM выступает соавтором: он замечает новое решение в переписке, формирует черновик статьи и предлагает его в канал; человек за минуту подтверждает или правит.

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

2. Что входит в слой знаний

Ядро слоя - LLM-Wiki, поверх которой строятся остальные подслои. Каждая статья wiki автоматически предлагается LLM из рабочих событий и подтверждается человеком.

Ключевое отличие от классической вики: статьи не требуют ручного ведения. LLM следит за рабочими событиями (закрытая задача, принятое решение, ответ в канале) и предлагает черновик статьи. Сотрудник подтверждает, правит или отклоняет черновик - это занимает секунды, а не часы. Каждая статья хранит ревизии, источник (сообщение, задача, документ) и владельца.

3. Сценарии для сотрудников

Сотруднику нужны простые сценарии:

• найти ответ на вопрос по продукту или процессу;
• получить краткое резюме обсуждения;
• понять, какое решение уже принято;
• увидеть, кто владелец темы;
• создать задачу или заявку из найденного контекста;
• открыть исходные материалы с проверкой прав;
• предложить обновление статьи, если ответ устарел.

Интерфейс должен показывать ответ и источник: сообщение, задачу, документ, статью, решение, тикет поддержки или запись CRM. Пользователь должен понимать, откуда взялась информация и кому можно задать следующий вопрос.

4. Сценарии для руководителей

Руководителю нужны другие сценарии:

• где команда чаще всего теряет контекст;
• какие вопросы повторяются в каналах;
• какие темы требуют статьи базы знаний;
• какие решения приняты без владельца или срока;
• какие продуктовые изменения вызывают больше обращений;
• какие рыночные сигналы требуют discovery;
• какие знания доступны слишком широко или слишком узко.

Важный управленческий результат: знания должны сокращать время адаптации, число повторных вопросов, ручные статусные встречи и зависимость от отдельных сотрудников.

5. Архитектура знаний

Модуль знаний должен строиться вокруг нескольких типов объектов.

Поток LLM-Wiki: рабочее событие (решение в канале, закрытая задача, ответ поддержки) → LLM формирует черновик статьи со ссылками на источник → черновик предлагается в канал или личный инбокс → человек подтверждает, правит или отклоняет → статья публикуется и индексируется для поиска и RAG. Повторное событие по той же теме запускает обновление существующей статьи с новой ревизией.

6. Доступы и конфиденциальность

Разграничение доступа является главным условием запуска.

Уровни доступа:

• публичный внутри компании;
• уровень команды;
• уровень проекта;
• уровень подразделения;
• конфиденциальный продуктовый контур;
• юридический и договорной контур;
• финансовый контур;
• клиентские данные;
• персональные данные;
• ИБ и эксплуатационный контур.

Правила:

• ответ не должен раскрывать источник, если пользователь не имеет к нему доступа;
• RAG использует только документы и сообщения, доступные пользователю;
• агрегированные инсайты маскируют чувствительные данные;
• производные данные имеют срок жизни и политику удаления;
• каждый ответ показывает уровень уверенности и список доступных источников;
• все обращения к знаниям пишутся в журнал аудита;
• владелец данных может удалить источник и связанные производные данные.

7. RAG и LLM

RAG и LLM решают в модуле две разные задачи, и их нужно разделять.

RAG: ответ по подтвержденным источникам

RAG отвечает на вопрос пользователя, опираясь только на разрешенные источники: подтвержденные статьи wiki, сообщения, задачи, документы, тикеты. Это режим достоверного поиска:

• поиск по разрешенным источникам;
• ответ с обязательной ссылкой на источник;
• без источника ответ не должен выглядеть как факт;
• уровень доступа фильтрует источники до выполнения поиска.

RAG обслуживает сценарии «найти ответ», «показать контекст», «подготовить черновик ответа поддержки». Это самый безопасный режим: модель не порождает новые знания, а пересказывает проверенные материалы.

LLM: ведение LLM-Wiki и генерация

LLM-контур отвечает за создание и обновление знаний (LLM-Wiki) и за аналитические задачи:

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

В этом режиме модель порождает контент, поэтому обязателен контур подтверждения человеком (черновик → ревью → публикация) и строгий контроль доступа к исходным данным.

Политики контура

Для критичных контуров нужны отдельные политики: модель, хранилище векторов, индексация, удаление, аудит, контроль галлюцинаций, список запрещенных источников и red team проверки. LLM-Wiki безопаснее генерации на лету: галлюцинация на этапе черновика отсекается человеком, а опубликованная статья проверена и связана с источником.

8. Рыночные и discovery-инсайты

Модуль знаний может автоматически собирать и структурировать сигналы:

• изменения конкурентов;
• новости рынка;
• отзывы клиентов;
• обращения поддержки;
• обсуждения продаж;
• результаты интервью;
• заметки discovery;
• изменения регуляторики;
• внутренние решения по продуктам.

Каждый инсайт должен иметь источник, силу сигнала, связанный продукт, владельца проверки и предлагаемое действие. Это превращает знания в рабочий процесс: сигнал найден, оценен, связан с задачей и проверен в Time.

9. Инструмент поддержки

Для поддержки слой знаний должен давать:

• поиск по типовым обращениям;
• подсказку статьи или решения;
• связь обращения с дефектом, задачей или релизом;
• резюме истории клиента;
• автоматическое предложение обновить базу знаний после закрытия повторяющегося вопроса;
• оценку качества ответа;
• контроль доступа к клиентским данным.

Это особенно важно для Time Platform как корпоративного продукта: поддержка становится источником инсайтов, качества и обновления знаний.

10. Простая сборка прототипов

На более позднем этапе слой знаний может помогать собирать простые прототипы на основе данных:

• выбрать доменный сценарий;
• взять безопасный набор демо-данных;
• предложить структуру экранов;
• связать экран с источниками знаний;
• описать ограничения доступа;
• создать черновой UI для проверки с пользователями;
• собрать обратную связь и превратить ее в задачи.

Этот сценарий полезен для владельцев продукта, аналитиков внутри подразделений и продуктовых команд. Он не требует сложного backend на этапе прототипа, но требует строгих правил по данным и источникам.

11. MVP знаний

Первый прототип должен показать:

1. Поиск по доступным знаниям.
2. Ответ с источниками и уровнем доступа.
3. Резюме обсуждения в канале.
4. Карточку решения с владельцем и сроком.
5. Черновик статьи LLM-Wiki: из решения в канале LLM предлагает статью, человек подтверждает.
6. Инсайт из поддержки или рынка.
7. Связь знания с задачей и аналитикой.
8. Состояние, когда источник скрыт из-за прав.

Для первой внутренней версии достаточно метаданных, ссылок и ограниченного текстового контекста. Широкий LLM-доступ должен запускаться после отдельного допуска ИБ и владельцев данных.

Назначение: собрать открытые данные, расчетные допущения и формулы для стратегии Time Platform.

1. Открытые факты

2. Тарифы и рыночные ориентиры

3. TCO-сценарии для внутреннего периметра

Расчеты ниже не являются внутренними данными Т-Банка. Это сценарные оценки на основе открытых тарифов. Внутренние закупочные цены могут быть ниже из-за корпоративных скидок, долгих контрактов и пакетных условий.

4. Эффект продуктивности

Формула:

пользователи * минут экономии в день / 60 * рабочих дней * стоимость часа

Допущения для расчета:

• 18 рабочих дней в месяц;
• 2 500 руб. условная стоимость часа сотрудника;
• эффект считается как продуктивность, прямое высвобождение бюджета проверяется отдельно.

Эти цифры нельзя подавать как экономию бюджета. Их корректная роль - показать порядок величины проблемы и оправдать пилотный замер.

5. TAM / SAM / SOM

Так как точная внешняя клиентская база Time публично не раскрыта, расчет ниже является предположением на основе открытого рынка и тарифов.

Это не прогноз продаж. Это рамка для обсуждения: если модуль не может выйти хотя бы на десятки млн руб. годовой выручки или сравнимый внутренний эффект, его не стоит превращать во внешний продукт.

6. Купить / строить / партнериться

Для первой версии сильнее вариант "построить узкий слой действий". Для полноценного трекера, досок, документов, CRM, ERP или ЭДО по умолчанию надо сначала проверять "купить / партнериться".

7. Развилки выбора

Версия: 1.0 Проверено: 2 августа 2026

1. Как читать этот файл

Источники ниже подтверждают внешние факты: что Time уже существует как корпоративный мессенджер, имеет API, ботов, интеграции, кейсы внедрения и конкурирует в поле корпоративной совместной работы.

Они не подтверждают внутреннюю боль Т-Банка / Т-Технологий по задачам, почте, знаниям, CRM, ERP или договорам. Эти данные надо собрать отдельно через интервью, замеры и доступ к процессам.

2. Источники по Time

3. Кейсы Time

4. Конкурентный контекст

5. Зарубежные ориентиры

6. Проверенные выводы

Можно утверждать:

• Time уже имеет базу корпоративного мессенджера и интеграционной платформы.
• Путь через API, ботов, команды и интерактивные сообщения согласуется с текущими возможностями Time.
• Рынок движется к связке коммуникаций, задач, знаний и совместной работы.
• Российским корпоративным клиентам важны локальный контур, безопасность и управляемость.
• Почтовый модуль нельзя считать быстрым расширением, так как интеграция с Outlook / Exchange не подтверждена и в FAQ Time указана как отсутствующая.
• Умный слой знаний требует отдельной модели доступа, аудита, хранения и удаления данных.

7. Регуляторные источники

8. Расчетные допущения v0.4

Подробные таблицы вынесены в data-room-v0.4.md.

9. Неподтвержденные допущения

Нельзя утверждать без внутреннего исследования:

• что задачи из Time являются болью номер один;
• что Outlook является болью номер один;
• что сотрудники готовы создавать задачи из сообщений;
• что текущие трекеры вызывают массовое недовольство;
• что команды готовы перенести работу в новый модуль;
• что у Time есть свободная команда на этот продукт;
• что внешние клиенты готовы платить за такие модули;
• что умный слой знаний можно запускать на реальных данных без нового контура безопасности;
• что CRM, ERP, ЭДО или договорные системы можно подключить без владельцев данных и согласованных правил.

10. Что надо собрать внутри компании

Перед финальным выбором первого продукта нужны:

• список команд, где теряются договоренности в Time;
• текущий путь от сообщения до задачи;
• доля задач без владельца, срока или статуса;
• текущие инструменты: TASKS, Kaiten, Yandex Tracker, CRM, ERP, ЭДО, внутренние системы;
• карта интеграций и владельцев API;
• оценка боли вокруг Outlook;
• сценарии, где знания реально ищут в переписке и документах;
• владельцы безопасности, данных и поддержки;
• стоимость текущего процесса;
• текущие договоры, цены, сроки продления и владельцы закупок по трекерам, почте, вики, доскам, CRM, ERP, ЭДО и службе заявок;
• базовый уровень вовлечения Time по сегментам сотрудников;
• внешний периметр клиентов Time и доля клиентов с локальным контуром;
• готовность внутреннего заказчика финансировать следующий этап.

Дата: 2026-08-02. Метод: веб-ресерч по официальным источникам (time-messenger.ru, docs.time-messenger.ru, блоги Т-Банка) и независимым площадкам. Все факты подтверждены реальными URL. Цель: зафиксировать, что Time уже умеет в области задач, workflow, ботов и интеграций, чтобы позиционировать первый продукт Time Platform как формализацию существующего паттерна.

Таблица возможностей

Выводы для стратегии

• Time уже содержит все строительные блоки действий: workflow с формами, slash-команды, интерактивные сообщения и диалоги, ботов, OAuth2 и открытый API. Первый продукт Time Platform должен формализовать эти существующие механизмы в единый шаблон "задача/заявка со статусом", а не изобретать новую модель.

• Паттерн уже работает в проде: 2000+ ботов и шаблонов процессов созданы сотрудниками сами, бот поддержки Т-Банка (200+ услуг) принимает заявки в 4 раза быстрее, внешние клиенты (Skillfactory) интегрировали AmoCRM и Яндекс Трекер. Позиционирование "формализуем то, что рынок уже делает вручную" снижает порог принятия.

• Доказан разрыв "статус задачи": сотрудники чаще получают уведомления о статусе задач в Time, чем в TASKS. Задачи живут в трекерах, а коммуникация о них - в мессенджере. Time Platform как слой действий/статусов поверх Time закрывает именно этот разрыв.

• Интеграции с трекерами и CRM (TASKS, AmoCRM, Яндекс Трекер, готовые конфигурации) - это фундамент, а не конкурент. Свой продукт должен опираться на существующие интеграции Time и добавлять над ними управляемый workflow, а не пытаться заменить таск-трекеры.

• Документация (docs.time-messenger.ru) готова для разработки: API v4/v5, WebSocket, OAuth2, интерактивные диалоги с валидацией форм - есть все технические предпосылки, чтобы строить платформу действий без бэкдор-решений.

• Факт о "задачах прямо из чата" из обзора toolfox.ru официально не подтвержден (на сайте и в документации отсутствует) - перед стратегией стоит верифицировать у вендора, есть ли нативный таск-менеджмент в Time, это влияет на границы продукта.

Резюме открытых данных (июль 2026). Все факты подтверждены URL. Что не подтверждено - помечено "не подтверждено".

Ключевые цифры масштаба: Time (ООО "ТЦР") используют около 70 000 сотрудников Т-Банка, всего 30-40 внешних компаний-клиентов и суммарно более 100 000 пользователей (заявление CTO Time Андрея Собянина в подкасте TAdviser, 2026).

Найденные публичные кейсы внешних клиентов

Дополнительно: сайт time-messenger.ru утверждает, что "помогаем перейти в Time компаниям из разных сфер" и что по итогам опросов 90% пользователей считают, что с Time рабочие вопросы решать проще. Число компаний "30-40" и "свыше 100 000 пользователей" - данные CTO (заявление, не аудированная статистика).

Гипотезы сегментации внешней базы

Это рабочие гипотезы для GTM-стратегии на основе публичных кейсов, официально подтвержденной статистики сегментов нет.

• Регулируемые финансовые организации (банки, страховые, финтех, ИТ для финансов). Гипотеза: ближайший к ядру сегмент. Time соответствует требованиям Банка России и GDPR, есть ISO/IEC 27001/27017/27018, работает в средах с десятками тысяч пользователей, доступен on-premise. Якорный кейс - сам Т-Банк. Триггер: жесткие требования ИБ и импортозамещение. Продавать через гостевые доступы для работы с контрагентами.
• Средний tech / SaaS-компании (300-2 000 сотрудников). Гипотеза: ядро текущих пилотов (Skillfactory, Кама). Триггер: уход Slack (2022-2024) и блокировки публичных мессенджеров; потребность в автоматизации (боты, Workflow), интеграциях по API и совместимости с API Slack. Подходит SaaS-версия.
• Мигранты со Slack / Mattermost / RocketChat / Telegram. Гипотеза: официально заявленная функция миграции из Slack, Mattermost, Rocket.Chat и (с марта 2026) из Telegram - сильный конверсионный аргумент. Публично подтверждены миграции: из Slack (Т-Банк, Skillfactory, Кама), из Telegram (Центральный университет).
• Образование (вузы, онлайн-школы, edtech). Гипотеза: отдельный ценовой сегмент (тариф 20 руб/мес за лицензию, от 100 пользователей) и готовые кейсы (Skillfactory, Центральный университет). Сильная связка с Unidraw (онлайн-доска).
• SMB и малый бизнес, мигранты из Telegram. Гипотеза: по словам Михаила Шишкина (CNews, 2024), Time подходит SMB, которые хотят перевести сотрудников из Telegram в защищенный мессенджер. Здесь ключевая роль SaaS-версии и простого онбординга.
• Международный (азиатский) рынок. Гипотеза (заявлена Шишкиным в CNews, 2024): интерес из Азии к Time как к коммерческой альтернативе open source (RocketChat, Mattermost). Требует отдельной проверки.

Открытые заявления о планах Time

• 10.11.2022, vc.ru (Т-Банк): запуск TiMe/Time на 50 000 человек вместо Slack; уже тогда заявлено намерение "развивать корпоративный мессенджер как продукт" и готовность делиться опытом с рынком. URL: https://vc.ru/tinkoff/536505-Pb3XmBtzstp1xKsauBgTQQLeAPwyLfDzDFboRLL
• 10.11.2022, пресс-релиз Т-Банка: TiMe вместо Slack, идеи по развитию принимаются на time@tinkoff.ru. URL: https://www.tbank.ru/about/news/10-11-2022-time-instead-of-slack-tinkoff-has-developed-its-own-corporate-messenger/
• 17.07.2024, vc.ru (Т-Банк): продукт "выходит на рынок", проведены "сотни внешних пилотов"; стратегический выбор - "сначала сделать хороший мессенджер, а потом расширять функциональность", а не суперапп; упор на открытый API, инструменты и визуальные формы для автоматизаций. URL: https://vc.ru/tinkoff/1312848-kak-korporativnyi-messendzher-time-ot-t-banka-zamenil-slack-i-reshaet-zadachi-biznesa
• 15.07.2024, CNews (интервью Михаила Шишкина): разрабатывается SaaS-версия для "мгновенного" подключения; три формата пилота (SaaS-пилот, express on-premise до 500 пользователей, полный on-premise); интерес азиатского рынка; планы по расширению числа совместимых open source решений; частый запрос - интеграция с почтой и календарем; рекомендация "не гнаться за супераппами", а соединять мессенджер с ВКС и трекером задач. URL: https://www.cnews.ru/articles/2024-07-12_mihail_shishkint-bank_najti_zamenu
• 11.03.2026, CNews: Time запустил функцию миграции данных из Telegram (перенос рабочих чатов и истории в защищенный контур). URL: https://www.cnews.ru/news/line/2026-03-11_time_zapustil_funktsiyu_migratsii
• 2026, TAdviser (подкаст с CTO Андреем Собяниным): 30-40 внешних компаний, 100 000+ пользователей; SaaS добавлен как метод дистрибуции примерно за год до интервью; планы по AI-функциям (саммаризация переписок, автоматическое формирование задач по итогам обсуждения, умный поиск по базе знаний переписок) - "планируем выпустить в ближайшее время"; рассматривается возможность общения между Time и другими мессенджерами; пока нет партнерской сети (возможна в будущем). URL: https://www.tadviser.ru/a/952128 (страница статьи "CTO мессенджера Time Андрей Собянин - о рынке корпоративных коммуникаций, переходе Т-Банка на Time и роли ИИ")

Контекст для стратегии "Горизонт 2" (модульная платформа): публично заявленный вектор - мессенджер как "единое окно" и платформа автоматизации (боты, Workflow, интеграции с таск-трекерами, ВКС, CRM по API/Webhook), а не суперапп. AI-модули (аналитика и поиск по знаниям) официально анонсированы, но дата релиза и состав для внешних клиентов не раскрыты.

Позиционирование на рынке корпоративных мессенджеров РФ

• Рынок: мировые корпоративные коммуникации ~74 млрд долл. (к 2035 прогноз ~300 млрд), российский сегмент ~2% мирового, но растет быстрее (заявление Собянина, TAdviser 2026). Доля российских решений выросла с 4% (2021) до 25% (2022) - по данным "Ведомостей", цитируемых в vc.ru.
• Конкуренты: Битрикс24 (портал/CRM с чатами), Яндекс 360 / Яндекс Мессенджер (от ~249 руб/пользователь/мес), VK WorkSpace / VK Teams (от ~159-249 руб/пользователь/мес), MTS Messenger ("Чаты" от МТС), eXpress (Анлимитед Продакшен), Compass (от ~390 руб), Пачка, Frisbee, а также решения Сбера и МегаФона.
• Отличия Time (по официальным материалам): российская альтернатива Slack, интерфейс и UX "как Slack", совместимость API Slack и инструменты миграции (Slack, Mattermost, Rocket.Chat, Telegram), on-premise в периметре компании, масштаб до 50 000+ пользователей онлайн, SLA 99,5%, реестр российского ПО (экономия на НДС до 20%), сертификаты ISO/IEC 27001/27017/27018, соответствие GDPR и требованиям Банка России, гостовые доступы для подрядчиков.
• Слабости (по независимым обзорам): молодой продукт, меньше интеграций, чем у зарубежных аналогов, ограниченная публичная информация о тарифах (обзоры toolfox.ru, vc.ru, startpack.ru).
• Цена Time на фоне конкурентов: 350 руб/мес за лицензию (SaaS и on-premise) против 249 руб у VK Teams/Яндекс Мессенджера и 390 руб у Compass - средний ценовой диапазон.

Ценовая политика Time для бизнеса (официальный сайт time-messenger.ru)

• SaaS (облако Time): от 50 лицензий, 350 руб/мес за лицензию; гостевой доступ - 175 руб/мес. В FAQ упоминается порог от 100 сотрудников для SaaS.
• On-Premise: от 500 лицензий (в FAQ - от 1 000), 350 руб/мес; гостевой доступ - 175 руб/мес; техподдержка - 25% от стоимости лицензий.
• Образование: 20 руб/мес за лицензию, от 100 пользователей, размещение в облаке.
• Акция: 3 месяца использования бесплатно (PDF условий на time-messenger.ru).
• Бесплатная демо/пилот: заявка на демосессию через сайт; по CNews (2024) есть SaaS-пилот и express-пилот on-premise.
• Реестр российского ПО: освобождение от НДС, экономия до 20% на лицензиях.
• Точные условия крупных контрактов (скидки, enterprise-цены) публично не раскрыты - "не подтверждено".

Выводы для GTM-стратегии

• Начать с подтвержденных якорей: финтех/регулируемые финансовые организации (доверие к банковскому происхождению, ИБ-комплаенс) и средний tech/SaaS на 300-2 000 сотрудников (Skillfactory, Кама) - два сегмента с публичными доказательствами.
• Использовать миграцию как главный конверсионный крючок: официальная поддержка Slack, Mattermost, Rocket.Chat, Telegram + совместимость API Slack; таргетировать "вторую волну" компаний, которые в 2022-2023 выбрали решение наспех (эффект "замещения импортозамещения", заявлен Собяниным).
• Для модульной стратегии (Горизонт 2) продавать не "суперапп", а связку "мессенджер + автоматизация процессов + открытый API": официально заявленный вектор - сначала качественный мессенджер, затем расширение функциональности; AI-модули (аналитика переписок, умный поиск по базе знаний) уже анонсированы как ближайшие планы.
• Двухступенчатая ценовая лестница: демо/бесплатный пилот -> SaaS (350 руб/мес, порог 50-100 лицензий) для быстрого онбординга среднего бизнеса и SMB; on-premise с поддержкой 25% для крупных и регулируемых клиентов; отдельный образовательный тариф 20 руб/мес как канал расширения базы.
• Каналы: на текущем этапе прямые продажи без партнеров (сайт + демосессии + контент Т-Банка), что совпадает с заявленной моделью; партнерская сеть и федеральные интеграторы - возможный масштаб на следующий горизонт (заявлено как возможное будущее).

Вендоры документов и досок: ландшафт для buy/partner

Дата сбора: август 2026. Статусы данных: "подтверждено" - информация из указанного источника, "не подтверждено" - публично не найдено. Цены не являются публичной офертой, уточнять у вендоров.

Таблица 1. Редакторы документов

Таблица 2. Онлайн-доски

Таблица 3. Видеосвязь (видеозвонки)

Видеозвонки рассматриваются как самостоятельный модуль Time Platform, а не как «интеграция с видеосервисом» в рамках другого модуля. Это позволяет решить видеосвязь через buy/partner (on-premise или облако с API), а не строить WebRTC-инфраструктуру с нуля, и не привязывать модуль к выбору коммуникационного канала.

Вывод для видеозвонков: on-premise решения (TrueConf, IVA MCU) дают полный контроль над данными, поддерживают LDAP/AD, SSO и DLP - это предпочтительный buy/partner путь для корпоративного сегмента Т-Банка. Для быстрого старта допустимо подключить облачный виджет (Телемост, МТС Линк Встречи, Битрикс24) через API. Строить видеосвязь с нуля нецелесообразно - WebRTC-инфраструктура, SFU/SVC-кластеры и транскодеры требуют отдельной постоянной эксплуатации, а ИИ-функции (транскрипция, протоколы) быстрее появятся у партнеров.

Выводы для решения buy/build/partner

• Модуль Документы решается покупкой или партнерством: и МойОфис, и Р7 поставляют встраиваемые веб-редакторы с публичным API (МойОфис Web Editor API / SDK с Document API и WOPI; Р7 Сервер документов с Document Server API) и готовыми партнерскими программами, включая ISV-лицензии (МойОфис SDK от 2 490 руб./год) - это самый короткий путь к рабочему модулю без разработки с нуля.
• Публичные цены есть только у МойОфис (частично), Р7 (десктоп от 6 000 руб./год) и Яндекс 360 (от 319 руб./мес). У серверных редакций МойОфис и Р7 цены закрыты за заявкой у партнеров - для точной оценки buy нужно запрашивать КП у авторизованных партнеров.
• Доски: открытое встраивание (API/embed) подтверждено только у sBoard (доступ к API в on-premise, функция встраивания) и частично у Контур.Толк Доски (API на корпоративных тарифах) и Pruffme. У крупных игроков (Яндекс Концепт, VK Доска, МТС Линк Доски) публичного API для встраивания в стороннюю платформу нет - они закрытые экосистемные продукты.
• Если Доски нужны как встроенный модуль Time Platform, наиболее реалистичны варианты: partner с sBoard (облако или on-premise) либо build собственной доски; готовых "встраиваемых досок" уровня Miro с открытым SDK на рынке почти нет.
• Рынок консолидируется (Яндекс купил Pruffme и перезапустил как Концепт, МТС купил Jespo) - выкуп нишевых досок (sBoard, Holst, Unidraw) технически возможен, но цены и финансовые условия не публикуются; sBoard - единственный подтвержденный кандидат на partner/поглощение с коробочной поставкой и API.

Engagement и удержание: практики и выводы

Research-материал для раздела стратегии Time Platform про engagement и удержание использования модуля задач. Собраны реальные практики Slack, Microsoft Teams, Microsoft Power Platform и крупных банковских citizen developer программ. Паттерн для соотнесения: внутри Time уже 2000+ ботов и шаблонов процессов, созданных сотрудниками самостоятельно.

Таблица примеров

Соотнесение с паттерном 2000+ ботов Time

Паттерн, который уже работает внутри Time (2000+ ботов и шаблонов процессов от сотрудников), в мировой практике называется citizen development или bottom-up платформенный рост. Все крупные платформы подтверждают: этот паттерн не побочный эффект, а главный драйвер удержания.

1. Интеграции и боты напрямую повышают retention. Слоган стратегии Slack ("virtuous circle"): чем больше приложений установлено и чем больше процессов заведено в платформе, тем дороже уход и тем чаще пользователь возвращается. Боты и шаблоны работают как "investment" в hook-модели Nir Eyal: пользователь вкладывает данные и процессы, уходить становится невыгодно. Для Time это означает, что 2000 ботов это уже накопленный switching cost, который надо охранять и развивать, а не упрощать. Slack, https://www.theverge.com/2015/12/15/10235114/slack-app-directory-80-million-fund; https://www.nirandfar.com/habit-forming/.

1. Масштаб citizen developer роста требует governance, а не запретов. Банковские кейсы (Microsoft internal, Rabobank, Danske Bank, KeyBank) показывают единый путь: сначала бурный неконтролируемый рост, затем CoE с tiered политиками, риск-классификацией и признанием чемпионов. Danske Bank прямо называет риск: если CoE отвечает "нет", сотрудники уходят в shadow IT. Вывод для Time: 2000 ботов это сигнал зрелости, но без легкого центра компетенций и каталога качество и discoverability деградируют. Microsoft, https://www.microsoft.com/insidetrack/blog/empowerment-with-good-governance-how-our-citizen-developers-get-the-most-out-of-the-microsoft-power-platform/; Danske Bank, https://www.uipath.com/resources/automation-case-studies/danske-bank-expands-citizen-developer-program-intelligent-automation.

1. Ценность создают не сами боты, а их discoverability и reuse. Slack вложился в App Directory, шаблоны Workflow Builder и возможность "дублировать чужой workflow и донастроить". Для 2000 ботов Time это главный незакрытый слой: каталог, поиск, рейтинг использования, шаблоны. Если пользователь не находит готового решения, он либо дублирует работу, либо уходит. Slack, https://slack.com/blog/news/new-workflow-builder; https://slack.com/help/articles/17542172840595-Build-a-workflow--Create-a-workflow-in-Slack.

1. Авторов ботов надо формально признавать. Slack (Champion of the Year, community chapters) и Microsoft (champions network, Power Platform Ninjas, CoE наблюдает за активными авторами и приглашает их в программу) показывают: признание и привилегии конвертируют power users в амбассадоров, которые сами обучают коллег и дают продуктовый фидбек. В Time авторы 2000 ботов это готовая база для такой сети. Slack, https://slack.com/customer-stories/bolt-slack-champion-mathis-bogens; Microsoft, https://learn.microsoft.com/en-us/power-platform/guidance/adoption/champions.

1. Активность не-разработчиков это норма, а не исключение. Slack Workflow Builder: почти 1 млн создателей, 80% нетехнические. Паттерн Time совпадает: шаблоны процессов и ботов собирают не инженеры. Значит, инструменты должны быть низко-пороговыми (шаблон вместо чистого листа, AI-подсказка, кнопка вместо команды). Slack, https://slack.com/blog/news/new-enhancements-to-workflow-builder.

1. Онбординг должен быть без трения и давать результат в первые минуты. Slack фиксирует onboarding в продукте: приветственное сообщение, кнопки "Start Tour" и "Create First Task", App Home tab как панель действий. Для модуля задач Time это переводится в 1 клик до действия: создать задачу из сообщения, запустить бота кнопкой, получить первый результат без чтения документации. Slack, https://slack.dev/marketplace-best-practices/.

1. Метрики engagement надо искать в поведении, а не в активностях-валютах. Slack нашел activation-порог (команда за 2000 сообщений, 93% retention) и подстроил под него весь продукт. Для Time это гипотеза для проверки: порог "команда создала N задач из сообщений", "пользователь запустил бота повторно на второй неделе" и т.п. Slack, https://www.ideaplan.io/case-studies/slack-product-led-growth.

Выводы для стратегии engagement

• Паттерн 2000+ ботов Time уже содержит доказанный спрос на bottom-up автоматизацию. Стратегия должна не создавать спрос, а снижать трение между "есть 2000 ботов" и "пользователь запускает нужный за 1 клик": каталог, поиск, шаблоны, slash-команды и кнопки в интерактивных сообщениях.

• Ввести формальную программу чемпионов по образцу Slack и Microsoft: выявлять активных авторов ботов и шаблонов, давать им статус, ранний доступ к фичам и привилегии; чемпионы работают как сеть (канал чемпионов, офисные часы, разбор лучших кейсов), а не как формальная поддержка.

• Приоритет на discoverability и reuse: каталог ботов и шаблонов с метриками использования, возможность копировать и донастраивать чужой процесс, "дублируй и улучши" как рабочий цикл. Для 2000 ботов это снимает риск дублирования и спама.

• Измерять удержание поведенческими метриками по модели Slack: найти activation-порог модуля задач (первая задача из сообщения, первый запуск бота, первый созданный шаблон), следить за voluntary повторным использованием, stickiness (DAU/WAU), feature adoption vs retention картами. Использовать их как north star, а не DAU.

• Гардрейлы вместо запретов: по образцу Microsoft "empowerment with guardrails" и банковских CoE создать легкий центр компетенций: риск-классификация ботов, базовые политики качества, шаблоны и ревью лучших практик. Feedback loop от чемпионов и авторов ботов в продуктовую команду Time как постоянный источник идей.