TB Pulse — полный план реализации
Версия от 19.08.2026. Собран из разбора идеи 007 (ideas/exploring/007_sales_intelligence_hub.md),
разведки 12 агентов (ideas/exploring/007-research/) и наработок TB Pulse Dev v2.
Разбор: https://biztune.ru/r/260819-servis-kotorogo-net-analitik-otdela-prodazh-b7e1/
Спецификация: https://biztune.ru/r/260819-chto-imenno-my-stroim-kontseptsiya-mvp-etapy-c4a2/
0. Что это и как соотносится с существующим TB Pulse
Продукт: система контроля исполнения в продажах. Восстанавливает по следам в CRM, как реально работает отдел, и находит места, где обещанное не сделано. Не аналитика звонков, не сквозная аналитика, не BI.
Название проекта: TB Pulse (существующее). Разовая услуга внутри — «Аудит утечек».
Совпадение с TB Pulse Dev v2 — очень высокое
| Что уже есть в TB Pulse | Что с этим делаем |
|---|
| Сбор из Б24 (лиды, сделки, дела, задачи, часы, чеклисты) | Берём концепт разделов целиком. Это готовая онтология того, что вообще имеет смысл собирать |
| Директорский отчёт: компактные цифры + drill-down со ссылками на сущности Б24 | Берём как есть — это ровно наш принцип прослеживаемости |
| Утренний автоотчёт по расписанию | Берём — это наш утренний дайджест |
| Пинги = реальные действия в Б24 (комменты в задачи, дела в сделки) | Берём и расширяем — это фундамент механизма напоминаний |
| Раздел «Менеджеры» — сводка всех проблем | Берём, переосмысляем: не «проблемы», а «кому звонить» |
| Задачи: просрочено / замершие 7д+ / вот-вот | Прямой прообраз правил утечек |
| Дела: необработанные звонки/чаты/письма, просроченные | Прямой прообраз L1 и L4 |
| AI-онбординг из плана (скан портала → базовый пульс → AI-анализ → кастомный) | Это наш агент-сканер. Год назад задумано верно, теперь реализуем |
| Кастомный пульс через голос/текст, AI генерирует конфиг | Это наш словарь понятий голосом. Тоже уже задумано |
| Мультитенант: workspace_id → API key | Берём |
| VibeCode API как транспорт к Б24 | Развилка Ф1-Р1 — см. ниже |
| claude-runner для AI | Берём для внутренних задач; для клиентских данных — см. юрконтур |
Чего в TB Pulse нет и что добавляем
1. Деньги. Ни одна метрика не переведена в рубли. Добавляем «деньги под риском» с видимой формулой.
2. Обещания из разговоров. Расшифровки не используются вообще.
3. Голосовой обход — вечерний сбор недостающего.
4. Отслеживание исполнения обещаний (kept/broken).
5. Семантический слой — определения метрик как данные, а не код.
6. Достоверность как фича — «как посчитано», сверка с CRM, честный отказ.
7. Продажа — TB Pulse был внутренним инструментом, продукт не продавался.
8. Мультисорсность — только Б24.
Что НЕ берём из TB Pulse
- Часы и чеклисты по задачам — это про исполнение проектов, не про продажи. Оставляем как есть, в новый контур не тащим.
- Привязку к Telegram как единственному каналу.
- Хардкод под конкретный портал.
1. Принципы, которые нельзя нарушать
1. Ни одна цифра в ответе не приходит из токенов модели. Модель выбирает что посчитать, считает движок, значения подставляет шаблон.
2. Метрика без drill-down не существует. Не можешь показать, из каких записей собрана — не показывай вообще.
3. Отчёт отвечает «кому звонить», а не «кто виноват».
4. Данные со слов человека помечаются отдельно и не смешиваются с фактами из систем.
5. Считаем часы на онбординг с первого клиента. Больше 4 часов — это подряд, а не сервис.
6. Коннектор пишется только под оплатившего клиента (кроме первых трёх источников).
7. Абстракция источника расшифровки — с первого дня.
8. Отраслевое живёт в словаре, а не в коде.
ФАЗА 0. Проверка гипотезы — 3–5 дней
Цель: узнать, есть ли в живых данных то, что мы собираемся продавать.
Задачи
- 0.1. ~~Выбрать 2 портала~~ Решение владельца 19.08: только наш biztune39, клиентские порталы не трогаем.
- 0.2. Скрипт-разведчик: выгрузить 90 дней (сделки, лиды, дела, звонки, история стадий).
- 0.3. Посчитать без ИИ: лиды без касания 24ч+; сделки без активности 14д+; пропущенные без перезвона 24ч; повторные обращения одного клиента разными лидами; отвалы после первого касания; застрявшие дольше p90 своей стадии.
- 0.4. Перевести в рубли по формуле «сумма × историческая конверсия стадии за 90 дней». Формулу зафиксировать в отчёте.
- 0.5. Проверить доступность транскриптов:
crm.activity.call.getTranscript на живых звонках. Есть/нет/сколько процентов звонков покрыто.
- 0.6. Проверить глубину истории стадий: восстанавливается ли движение за 90 дней назад или только с момента подключения.
Результат
Файл research/phase0-results.md: сколько утечек, на какую сумму, на обоих порталах отдельно.
🚦 Критерий продолжения
На чужом портале утечек минимум на 1 млн ₽. Меньше — STOP, вопрос в Сёму.
ФАЗА 1. Ядро: сбор и лента событий — 2 недели
Цель: своя копия данных, из которой можно считать что угодно.
Задачи
- 1.1. Решить развилку Ф1-Р1 (VibeCode API vs прямой REST) — см. раздел развилок.
- 1.2. Схема хранения:
raw_payloads (сырое, вечно) → events (лента «клиент × время») → parties/identities/opportunities/stage_history.
- 1.3. Забор истории: сделки, лиды, дела, звонки, история стадий и смен ответственного. Приём
start=-1 + фильтр по ID.
- 1.4. Ограничитель скорости на портал, а не на процесс. Backoff на 429/503. Никогда не доводить до OVERLOAD_LIMIT.
- 1.5. Инкремент: подписка на события + офлайн-очередь + ночная сверка по DATE_MODIFY (события Б24 не имеют повторной доставки).
- 1.6. Нормализация: словарь
event_type, отсев тестовых, приведение валют, рабочий календарь по фактическим активностям.
- 1.7. Identity resolution: ИНН > телефон (E.164) > email. Спорное — в список «похоже на дубли», не склеивать автоматически.
Результат
Портал заливается за ночь, лента событий воспроизводима из сырых данных без обращения к клиенту.
Критерий готовности
Контрольная сверка: число сделок, сумма выигранных за месяц, число активностей совпадают с самим Битриксом с расхождением <0,5%.
ФАЗА 2. Правила утечек и отчёт — 1,5 недели
Цель: первый продаваемый артефакт.
Задачи
- 2.1. Материализация
gaps (интервалы тишины) с рабочим календарём и SLA по стадиям.
- 2.2. Правила без ИИ: L1 лид без касания · L3 сделка в тишине · L4 пропущенный без перезвона · L5 повторное обращение новым лидом · L6 застрял дольше p90 · L10 отвал после первого касания.
- 2.3.
money_at_risk = сумма × историческая конверсия стадии за 90 дней у этого же клиента. Поле basis с текстовым объяснением. Никогда не называть «упущенной выручкой».
- 2.4. Генератор отчёта: HTML + PDF. Структура: сумма → топ сделок к обзвону с именами и ссылками → системные дыры → «как посчитано» под каждой цифрой.
- 2.5. Штамп полноты: «данные на дату, охват сделок N%, охват звонков M%».
- 2.6. Ночная сверка с CRM по 8–10 контрольным срезам, дрейф >0,5% → пометка «расходится с CRM».
Результат
Отчёт, за который берут 39 000 ₽.
Критерий готовности
Отчёт по чужому порталу прочитан вслух его владельцем и вызвал реакцию «а покажи эти сделки».
ФАЗА 3. Продажа — параллельно с Ф2, не после
Цель: первые деньги на четвёртой неделе.
Задачи
- 3.1. Образец отчёта на обезличенных данных, 6–8 страниц.
- 3.2. Строка «Аналитический контур» в шаблон КП студии — включённой по умолчанию, чтобы её вычёркивали, а не добавляли.
- 3.3. Счётчик утечек: страница + скрипт, результат за 20 минут без участия человека.
- 3.4. Калькулятор упущенного без доступа к CRM (менеджеров × лидов × чек).
- 3.5. Письма по трём сегментам базы (действующие / тёплые / холодные). Холодных — только звонком, не рассылкой (38-ФЗ).
- 3.6. Оффер с гарантией: «не найдём на миллион — вернём деньги и отдадим отчёт».
🚦 Критерий продолжения
Один оплаченный счёт. Нет счёта за 30 дней при 8+ сделанных проверках — STOP, вопрос в Сёму.
ФАЗА 4. Обещания из разговоров — 2 недели
Цель: закрыть главную незанятую щель рынка.
Задачи
- 4.1. Конвейер расшифровок: событие звонка → отложенный опрос готовности → забор транскрипта → своё хранилище.
- 4.2. Абстракция источника: CoPilot / покупная STT / своя. Переключение конфигом на клиента.
- 4.3. Извлечение обещаний LLM: тип (перезвонить / отправить КП / встретиться / выставить счёт / вернуться в срок), дата, цитата-доказательство, уверенность. Только факт — считать нельзя.
- 4.4. Разрешение kept/broken детерминированно по ленте, с правилами из спецификации (звонок >30 сек, КП = письмо с вложением и т.д.).
- 4.5. Три защиты от ложных обвинений: клиент опередил, сделка закрылась, кнопка «я такого не обещал».
- 4.6. Правила L2 (сломанное обещание) и L7 (КП без follow-up).
- 4.7. Уверенность <0,75 → в «требует подтверждения», не в агрегаты.
Критерий готовности
На 50 реальных звонках: доля верно извлечённых обещаний >80%, ложных срабатываний <10% (проверяется руками).
ФАЗА 5. Подписка и дайджест — 1,5 недели
Цель: превратить разовое в рекуррент. Здесь максимально переиспользуем TB Pulse.
Задачи
- 5.1. Автоматический пересчёт по расписанию.
- 5.2. Утренний дайджест (берём scheduler/digest.py как основу): кому звонить сегодня, просроченные обещания, новые утечки. Одна приоритетная рекомендация на сделку, не список.
- 5.3. Вечерний дайджест руководителю: что изменилось за день.
- 5.4. Личный кабинет: список утечек, фильтры, drill-down, экспорт.
- 5.5. Эскалация: сначала менеджеру → при повторе руководителю. Выполненное в срок не порождает уведомлений.
- 5.6. Тарифы и учёт: 9 900 / 19 900 / 35 000. Счета пока руками.
🚦 Критерий продолжения
Три платящие подписки. И замер: сколько часов ушло на подключение каждой. >4 часов — идём в Ф6 автоматизировать онбординг, а не строить новое.
ФАЗА 6. Агентский слой: сканер и словарь — 3 недели
Цель: превратить внедрение в сервис. Это условие существования бизнес-модели.
Задачи
- 6.1. Сканер, проход 1 — структура: воронки, стадии, поля, роботы, оргструктура, телефония.
- 6.2. Сканер, проход 2 — фактическое поведение: медианы в стадиях, куда уходят сделки, мёртвые поля (<10% заполнения), пропускаемые стадии, рабочий календарь, тестовый мусор.
- 6.3. Сканер, проход 3 — рассказ человеческим языком + вопрос «что здесь неверно?».
- 6.4. Правка голосом: кнопка записи, цикл «что-то ещё?» до явного «нет», показ понятого до применения, пересчёт истории после завершения с показом разницы.
- 6.5. Опрос 2–3 менеджеров тем же способом; расхождение с версией руководителя — в отчёт.
- 6.6. Словарь метрик как данные (Cube Core или свой): определения, версии, drill-down обязателен.
- 6.7. Переопределение понятия с предпросмотром «как поедут цифры».
- 6.8. Создание нового понятия из кирпичей (события, интервалы, условия, агрегаты) с проверкой на истории и честным отказом.
Критерий готовности
Новый клиент подключается за 2 часа, из них человек участвует не больше 30 минут.
ФАЗА 7. Голосовой обход — 2 недели
Цель: закрыть слепые зоны и замкнуть петлю.
Задачи
- 7.1. Детектор пробелов: сделка сменила этап без касаний · встреча без отметки · оплата без контакта · обещание с истёкшим сроком · долгое стояние.
- 7.2. Канал — голосовое в мессенджере, не звонок. Бот в Telegram и/или в Б24-чате. Звонок — позже, как эскалация.
- 7.3. Не больше 3–4 вопросов, только по сделкам выше порога суммы.
- 7.4. Извлечение из ответа: что было, обещания, следующий шаг, изменения.
- 7.5. Запись в CRM: комментарий в ленту, дело нужного типа, задача на обещанное. Всё помечено как заполненное голосом.
- 7.6. Пометка «со слов менеджера» в нашей ленте, отдельный учёт в метриках.
- 7.7. Напоминания: срок предлагает система, человек подтверждает. Двойная запись — в CRM и к нам как ожидаемое событие.
- 7.8. Правила записи в чужую CRM: только добавляем, всё помечено, три режима (сразу / с подтверждением / только у нас), без дублей, порог по сумме.
Критерий готовности
Доля ответов на обход >60% на второй неделе. Ниже — менять формат, не давить.
ФАЗА 8. Разговор с данными — 3 недели
Цель: удержание и отстройка.
Задачи
- 8.1. Роутер намерений L0: 40 канонических вопросов, собранных из логов реальных вопросов клиентов, а не выдуманных.
- 8.2. L1: генерация структурного запроса из словаря (не SQL).
- 8.3. Валидатор: схема → каталог → совместимость → политики → dry-run → sanity → self-consistency ×3 → аудит.
- 8.4. L3: честный отказ + предложение завести метрику.
- 8.5. «Как посчитано» — рендер из объекта запроса, не сочинение модели.
- 8.6. Golden set 150 вопросов + регрессионный прогон в CI.
- 8.7. Дашборд по фразе: спецификация из enum → Vega-Lite. Агрегации в спецификации запрещены.
- 8.8. Сохранение и версионирование дашбордов, плашка при смене определения метрики.
ФАЗА 9. Мультисорсность — по оплаченному спросу
- 9.1. Телефония напрямую (Mango / UIS / Sipuni) — для клиентов без BitrixGPT.
- 9.2. Своя расшифровка (T-one или VoiceKit; не Whisper — WER 19–27% против 8,6%).
- 9.3. amoCRM.
- 9.4. Универсальный вебхук по нашей схеме — закрывает самописные CRM без коннекторов.
- 9.5. Таблицы (Excel / Google Sheets): сканер структуры, ежедневный снимок для построения истории, мэтчинг телефонии по номеру.
- 9.6. 1С — факт денег вместо статуса «Успех».
- 9.7. Мессенджеры (WhatsApp через шлюзы).
- 9.8. Сквозная аналитика — стоимость упущенного лида.
ФАЗА 10. Инфраструктура зрелости — по мере роста
- 10.1. Мультиарендность: tenant_id первым в ключе, три рубежа изоляции, отдельная база на клиента.
- 10.2. Юрконтур: ООО, уведомление РКН, политика, договор + поручение + заверения, PII-redaction, LLM в РФ-контуре.
- 10.3. Свой биллинг.
- 10.4. Бесплатное приложение-установщик в Маркете как витрина, не как касса.
- 10.5. Партнёрская программа: 40% с разового, 25% с подписки, клиент на нашем домене.
- 10.6. Отраслевые словари и бенчмарки.
Развилки, требующие решения владельца
| ID | Развилка | Варианты | Моя рекомендация |
|---|
| Ф1-Р1 ✅ | Транспорт к Б24 | VibeCode vs прямой REST | РЕШЕНО 19.08: VibeCode. Разведка Фазы 0 показала, что он покрывает и транскрипты (/v1/activities/:id/transcript), и таймлайны — то есть аргумент «за прямой REST» отпал. Обязательное условие: абстракция транспорта, чтобы переключиться на REST без переписывания. |
| Ф1-Р2 ✅ | Куда писать код | tb-pulse-dev vs новый репозиторий | РЕШЕНО 19.08: новый модуль pulse-core/ внутри tb-pulse-dev. Старый бот работает, его не трогаем |
| Ф4-Р1 | LLM для разбора разговоров | claude-runner (как в TB Pulse) vs GigaChat/YandexGPT vs своя модель | На тестах — claude-runner. На боевых клиентских данных — только РФ-контур, иначе юридически невозможно продавать |
| Ф5-Р1 | Канал доставки дайджеста | Telegram (как сейчас) vs Б24-чат vs оба | Оба, но Б24-чат приоритетнее: он внутри рабочего контура клиента и не зависит от блокировок |
| Ф6-Р1 | Словарь метрик | Cube Core vs свой минимальный | Начать со своего минимального (10–15 метрик), Cube — когда упрёмся в кэш и мультиарендность |
Порядок работы в новой сессии
1. Читать этот план + ideas/exploring/007_sales_intelligence_hub.md + ideas/exploring/007-research/.
2. Идти по фазам сверху вниз, не перепрыгивая.
3. Каждую задачу — в чеклист, отмечать выполнение прямо в этом файле.
4. На развилке или стопоре — вопрос в Сёму (механизм ниже), ждать ответ, продолжать.
5. По завершении фазы — отчёт в Сёму + обновление статуса здесь.
Механизм вопросов владельцу
Отправить вопрос:
curl -s "https://api.telegram.org/bot8307683495:AAFjV1TBtaHjKkLyytGMrdiL-haO2ft5qTc/sendMessage" \
-d chat_id=38459671 --data-urlencode "text=❓ ВОПРОС [ID]: ...
1️⃣ Делаем
2️⃣ Не делаем
3️⃣ Делаем с уточнениями (напиши какими)
Ответь цифрой или голосом."
Прочитать ответ (Сёма сохраняет и текст, и расшифровки голосовых):
docker exec tbsema_postgres psql -U tb -d tb_bot -t -c \
"select created_at, text from messages where telegram_user_id=38459671 and direction='in' and created_at > now() - interval '2 hours' order by id desc limit 5"
Ждать циклом с интервалом 5–10 минут. Пока ждём — делать то, что от ответа не зависит.
Статус выполнения
- [x] Фаза 0 — проверка гипотезы ✅ 19.08.2026: 2 459 813 ₽ на biztune39, порог пройден. Результаты: research/phase0-results.md
- [x] Фаза 1 — ядро сбора ✅ 29.08.2026: лента событий, сверка с порталом 0,32 % при допуске 0,5 %
- [x] Фаза 2 — утечки и отчёт ✅ 29.08.2026: движок 5 правил + генератор отчёта. 2 227 001 ₽ / 175 находок
- [ ] Фаза 3 — продажа
- [ ] Фаза 4 — обещания
- [ ] Фаза 5 — подписка и дайджест
- [ ] Фаза 6 — агентский слой
- [ ] Фаза 7 — голосовой обход
- [ ] Фаза 8 — разговор с данными
- [ ] Фаза 9 — мультисорсность
- [ ] Фаза 10 — зрелость
Журнал реализации
29.08.2026 — Фазы 0–2
Сделано: схема core (10 таблиц) · транспорт с абстракцией и ограничителем на портал · нормализация с тестами · склейка клиентов · сборщик · движок правил L1/L3/L4/L5/L10 · генератор отчёта · канал вопросов через отдельного бота.
Ловушки Битрикса, пойманные на живых данных (все дают неверную цифру и никогда не дают ошибку):
1. closedAt — плановая дата закрытия, а не факт. Заполнена почти всегда, часто в будущем. Давала 171 «проигрыш» вместо 77 и события в будущем времени. Лечится: факт = флаг closed + терминальная семантика.
2. Контакты нельзя тянуть с фильтром по дате — сделки за 90 дней ссылаются на карточки многолетней давности. 59 % треков остались без клиента. Лечится: клиентская база тянется целиком.
3. VibeCode отдаёт разовые HTTP 500 — не ошибка данных, а сбой шлюза. Лечится ретраями 5xx.
4. Несколько пропущенных по одной сделке — одна утечка, а не пять.
Замеры: заливка 90 дней портала (188 сделок, 622 дела, 6494 клиента) — около 4 минут при 2 запросах в секунду. Транскрипты доступны, покрытие 12 %.
Канал вопросов: отдельный бот @TBPulseAI_dev_v2_bot, контейнер pulse_dev_bot остановлен по решению владельца (вернуть: docker start pulse_dev_bot). Утилита pulse-core/ask.py.