angel
72b6879f4b
- Refactored max_bot from nested packages to flat module structure - Q2: Extended BotUser model (patronymic, email, org, address, vcf_raw, contact_hash, phone_verified, email_verified, last_interaction, total_conversations, total_tickets) - Q2: VCF parser (FN, N, TEL, EMAIL, ORG, ADR), upsert on re-contact, NLP history context (_get_user_history_context -> YandexGPT) - Q1: Broadcast preview modal with 10s confirmation timer - Q3: CSS var(--white)->var(--bg-card), var(--text)->var(--text-primary) - Q4: bot_settings showNotification(), editable max_bot_id - Q5: Webhook secret passthrough via X-Max-Bot-Api-Secret - Masking sensitive keys, dialog_cleared handler, migrate via _add_column_if_not_exists() - Rate limit (asyncio.sleep 0.5 per 10), dead code removed, conv.intent context in contact.py - Portal pages: bot_consent, bot_kb (edit), bot_settings, bot_test, bot_tickets, portal_settings - Tests: 21/21 passing, added test_yandex_gpt.py, test_email_sender.py - Deploy: deploy_full.sh, schema.sql, seed_knowledge_base.sql
8.5 KiB
Ты сейчас описываешь переход от “владельца инженерной фирмы” к роли:
операционного директора инженерной системы (Engineering Operations System Owner)
В такой модели ты уже не контролируешь людей напрямую — ты контролируешь поток рисков, денег, SLA и загрузки системы.
Я разложу это как управленческую “панель управления” (CEO Dashboard), разделив на:
-
критически важные метрики (must have)
-
важные (should have)
-
полезные (nice to have)
-
формулы
-
графики и визуализации
-
как это связывается в одну систему управления
- КРИТИЧЕСКИ ВАЖНЫЕ ПАРАМЕТРЫ (CEO CORE CONTROL LAYER)
Это то, без чего ты не управляешь компанией, а просто “наблюдаешь бизнес”.
1.1 MRR / ARR (регулярный доход SLA)
Формула:
MRR = Σ (все SLA контракты / 12) ARR = MRR × 12
Почему это главное:
Ты продаёшь не монтаж, а:
стабильность объектов
График:
📈 линия роста MRR по месяцам 📊 разбивка по типам объектов
Управленческая логика:
если MRR растёт → система здорова
если нет → маркетинг/воронка сломана
1.2 RETENTION RATE (удержание клиентов)
Формула:
Retention = (клиенты в конце периода / клиенты в начале) × 100%
Норма:
95–100% = отлично
85–95% = нормально
<85% = проблема в SLA
График:
📉 “утечка клиентов по месяцам”
Интерпретация:
Если падает retention — проблема не в продажах, а в:
инженерах
SLA
качестве реакции
1.3 SLA COMPLIANCE (исполнение контрактов)
Формула:
SLA Compliance = (выполненные заявки в SLA / все заявки) × 100%
Норма:
95–99% = система стабильна
<90% = начинаются разрывы контрактов
График:
📊 compliance по инженерам / регионам
1.4 COST PER SLA OBJECT (стоимость обслуживания объекта)
Формула:
Cost per Object = (ФОТ + выезды + оборудование + накладные) / количество объектов
Почему важно:
Ты должен видеть:
объект приносит деньги или сжигает ресурс
График:
📊 распределение стоимости по типам объектов
1.5 ENGINEER PRODUCTIVITY (производительность инженера)
Формула:
EP = SLA Revenue / количество инженеров
Или глубже:
EP2 = (закрытые заявки × сложность) / часы работы
График:
📊 эффективность по инженерам (ranking)
- ВАЖНЫЕ ПАРАМЕТРЫ (OPTIMIZATION LAYER)
Это влияет на прибыль, но не ломает систему сразу.
2.1 LEAD → SLA CONVERSION RATE
Формула:
Conversion = SLA contracts / all qualified leads
График:
📈 воронка: лиды → аудит → SLA
Диагностика:
низкая конверсия → проблема продаж/аудита
высокая → система сильная
2.2 AVERAGE SLA CONTRACT VALUE
Формула:
ARPC = Total SLA revenue / number of contracts
График:
📊 средний чек по объектам
2.3 INCIDENT RATE (частота аварий)
Формула:
IR = incidents / objects
Почему важно:
Показывает:
реальное качество эксплуатации
2.4 REOPEN RATE (повторные заявки)
Reopen = повторные обращения / все обращения
Если растёт:
→ инженер плохо диагностирует
- ПОЛЕЗНЫЕ ПАРАМЕТРЫ (NICE TO HAVE)
Это усиливает контроль, но не критично.
3.1 CUSTOMER SATISFACTION (CSAT)
CSAT = (положительные оценки / все оценки) × 100%
3.2 RESPONSE TIME DISTRIBUTION
Не среднее, а распределение:
📊 0–2 часа 📊 2–6 📊 6–24
3.3 EQUIPMENT HEALTH INDEX
EHI = (исправное оборудование / общее оборудование) × 100%
3.4 ENGINEER UTILIZATION RATE
Utilization = рабочие часы / доступные часы
- ГЛАВНЫЙ CEO-ИНДЕКС (SYSTEM HEALTH SCORE)
Это твоя “панель управления бизнесом”.
Формула:
SHS = (0.25 × MRR growth) + (0.20 × SLA compliance) + (0.20 × retention) + (0.15 × engineer productivity) + (0.10 × conversion rate) + (0.10 × incident stability)
Интерпретация:
SHS состояние
85–100 масштабируемый рост 70–85 стабильный бизнес 50–70 проблемы в системе <50 системный кризис
- КЛЮЧЕВЫЕ ГРАФИКИ CEO (ДОСКА УПРАВЛЕНИЯ)
5.1 MRR Growth Curve
📈 рост повторного дохода
5.2 SLA Compliance Heatmap
🟥 красный = проблемные инженеры 🟩 зелёный = сильные
5.3 Client Retention Funnel
📊 где теряются клиенты
5.4 Engineer Performance Ranking
📊 топ / низ производительности
5.5 Incident Map
📍 какие объекты ломаются чаще
5.6 Cost vs Revenue per Object
📊 прибыльность каждого SLA
- КРИТИЧЕСКАЯ ЛОГИКА УПРАВЛЕНИЯ
Ты управляешь не людьми.
Ты управляешь:
рисками → SLA → деньгами → нагрузкой инженеров
- ЧТО ТЕБЕ ОБЯЗАТЕЛЬНО ВИДЕТЬ КАЖДЫЙ ДЕНЬ
DAILY CEO DASHBOARD:
SLA compliance
аварии за 24ч
новые SLA контракты
просрочки
перегруз инженеров
- ЧТО ТЕБЕ НУЖНО ВИДЕТЬ РАЗ В НЕДЕЛЮ
MRR рост
retention
эффективность инженеров
конверсия аудита в SLA
- ЧТО СМОТРЕТЬ РАЗ В МЕСЯЦ
прибыльность объектов
эффективность регионов
нагрузка команды
системные сбои
- ГЛАВНЫЙ ПРИНЦИП
Ты не управляешь:
❌ монтажами ❌ выездами ❌ людьми
Ты управляешь:
системой инженерной надежности объектов бизнеса
- ЕСЛИ СВЯЗАТЬ ВСЁ В ОДНУ МОДЕЛЬ
Аудит → Risk Score → SLA цена → контракт → MRR → KPI инженеров → retention → рост
- ИТОГ
Ты как CEO должен видеть не “что происходит”, а:
где именно в системе возникает прибыль или утечка денег/риска
- ЕСЛИ ДАЛЬШЕ РАЗВИВАТЬ СИСТЕМУ
Я могу собрать:
полноценный CEO-dashboard (Excel / Notion / Power BI)
автоматическую систему расчёта SHS
дашборд инженеров в реальном времени
модель прогнозирования MRR на 3–6 месяцев
систему раннего предупреждения потерь клиентов
Если коротко:
ты строишь не компанию — ты строишь управляемую инженерную систему с финансовыми законами внутри неё.