# Бриф инициативы: ИИ-агент для заявок на подключение
**Суть:** отдел продаж филиала Алматы теряет и дублирует заявки на подключение между Lotus-почтой и Excel; нужен ИИ-агент с отдельным экраном для менеджеров и автоматической сводкой в Telegram для Ержана, чтобы сократить ручную нагрузку и не терять заявки.

## 1. Контакты владельца процесса
- ФИО:
  - Ержан Асанов
- Контакт:
  - @erjan_a, +7 701 555 3311
- Департамент / дивизион:
  - Дивизион по трансформации, отдел продаж филиала Алматы
- Соисполнитель / пользователь процесса:
  - Серик Жумабаев, старший менеджер отдела продаж

## 2. Процесс и владелец
- Название процесса и роль владельца:
  - Обработка заявок на подключение.
  - Ержан руководит отделом продаж и отвечает за сводную картину для отчёта наверх.
- Что входит в объём задачи и что явно вне объёма (out of scope):
  - В объём входит приём заявок, первичная регистрация, поиск дублей, обновление статусов и контроль потока.
  - В объём входит подготовка сводки для руководителя.
  - Вне объёма – внешняя передача данных; процесс должен оставаться только во внутреннем контуре КТ.
  - Вне объёма – коммерческая тайна; по словам владельца, её в процессе нет.

## 3. Процесс AS-IS
- Триггер:
  - Заявка приходит из общего Lotus-ящика с сайта или менеджер записывает её после звонка клиента.
- Участники:
  - Клиент.
  - Менеджер.
  - Старший менеджер.
  - Руководитель отдела.
  - Аналитик Динара.
- Системы:
  - Lotus-почта `sales.almaty@kt.kz`.
  - Excel-файл `zayavki_2026.xlsx`.
  - Сетевой диск `\\ktfs01\sales\заявки`.
- Что происходит сейчас:
  - Заявки из почты и звонков вручную переносят в Excel.
  - Один файл используется всеми менеджерами одновременно.
  - Пока файл открыт у одного, другой ждёт.
  - Статусы обновляют с задержкой, по факту раз в 2-3 дня.
  - Дубли специально не ищут.
  - Если дубль замечен случайно, вторую строку удаляют.
  - При разном написании фамилии дубль может не распознаться.
  - Письма с сайта иногда попадают в спам общего ящика.
  - Руководитель не видит реальную картину в моменте.
  - Клиент может получить два звонка по одной заявке.

## 4. Боль и потери
- Заявки теряются между почтой и Excel, потому что входной поток не контролируется непрерывно.
- Дубли создают повторные звонки клиенту и искажают учёт.
- Общий файл на сетевом диске создаёт ожидание и конфликт одновременной работы.
- Статусы заполняются с задержкой, поэтому руководитель видит устаревшую картину.
- В пиковые дни процесс разваливается сильнее, чем в обычные.
- Менеджеры перегружены ручной работой и не успевают держать актуальный статус.

## 5. Объёмы и baseline
- Объём за прошлую неделю:
  - Навскидку 212 заявок, точные цифры поднимет аналитик Динара из Excel.
- Текущий объём в день:
  - 30-50 заявок в день, в акции до 100.
- Пиковая нагрузка:
  - В акции заявок вдвое больше, и именно тогда процесс разваливается.
- Время на одну заявку:
  - 10-15 минут ручной работы.
- Текущая суммарная нагрузка:
  - По расчёту Төре по объёму и времени шага – примерно 35-53 часа ручной работы в неделю на всех, владелец подтвердил.
- Личная нагрузка владельца:
  - Около 1 часа в день уходит на сбор картины для отчёта наверх.
- Тройка покрытия:
  - Не применима, потому что процесс обрабатывает каждый входящий запрос, а не выборочную долю потока.
- Норма по скорости:
  - Максимум 30 минут от поступления заявки до взятия в работу.
- Допустимое качество:
  - Допустимы пару процентов дублей.
- Что нужно минимум:
  - Спорные дубли и сложные случаи должны уходить менеджеру на подтверждение.

## 6. Данные и источники
- Lotus-почта `sales.almaty@kt.kz`:
  - Источник входящих заявок с сайта.
  - Формат – письма в общем ящике.
  - ПДн присутствуют: ФИО, адреса, телефоны клиентов.
- Excel-файл `zayavki_2026.xlsx`:
  - Рабочий реестр заявок.
  - Формат – таблица на сетевом диске `\\ktfs01\sales\заявки`.
- Поля данных:
  - ФИО, адрес, тариф, статус, менеджер, дата.
- Ограничение по данным:
  - ПДн клиентов нельзя выносить наружу, только внутренний контур КТ.
- Точка доступа к Excel:
  - `\\ktfs01\sales\заявки`.
- Точка доступа к почте:
  - `sales.almaty@kt.kz`.
- API у систем:
  - не подтверждено – уточнит Динара / ИТ-сопровождение.

## 7. Рекомендуемое решение TO-BE
- Ядро решения:
  - ИИ-агент с рабочим экраном для менеджеров, автоматическим поиском и снятием дублей, сводкой в Telegram для руководителя и передачей спорных случаев человеку на подтверждение.
- Главный выходной артефакт:
  - Отдельный экран со списком заявок и статусами.
  - Автоматическая сводка в Telegram для Ержана.
  - Excel-выгрузка как привычный дополнительный формат.
- Система-приёмник:
  - Рабочий экран для менеджеров.
  - Telegram для руководителя.
  - Excel-выгрузка для привычного использования.
- Уровень автономности:
  - Черновик и построчная работа с подтверждением спорных случаев человеком.
- Порог уверенности/точности, при котором агент действует сам:
  - Пару процентов дублей допустимо; спорные случаи передаются менеджеру.
- Рекомендуемый формат реализации:
  - `Alem + веб-панель` – по фактам нужен отдельный экран для менеджеров и автоматическая сводка, а контур внутренний; аналитическая рекомендация: `agent_with_approval`, уровень автономности 4/8.

## 8. Пользователи и действия после результата
- Основной пользователь – менеджер отдела продаж.
- Менеджер работает построчно в отдельном экране.
- Старший менеджер использует общий список и статусы для контроля.
- Ержан получает автоматическую сводку в Telegram без своего участия.
- После результата менеджер подтверждает спорные случаи.
- После результата руководитель смотрит сводку и картину по потоку.
- Получатель Excel-выгрузки – внутреннее использование команды продаж.

## 9. Граница проверки человеком
- Человек проверяет спорные дубли и сложные случаи.
- Человек подтверждает или отклоняет сомнительную заявку.
- Человек остаётся на границе, где агент не уверен в совпадении.
- Точка проверки – до финального принятия заявки в работу.
- При ошибке человек может подтвердить, отклонить или доработать запись.
- Автодействие без человека не допускается для спорных случаев.

## 10. Критерии приёмки
- Как менеджер, когда заявка пришла из почты или звонка, я хочу видеть её в общем списке, чтобы взять в работу не позже чем через 30 минут.
  - Вход: новая заявка из Lotus или звонка.
  - Ожидаемый выход: заявка в рабочем списке со статусом.
  - Ошибка/эскалация: если заявка спорная или дубль неясен, она уходит менеджеру на подтверждение.
- Как менеджер, когда в поток попадает дубль, я хочу видеть предупреждение, чтобы не звонить клиенту дважды.
  - Вход: заявка с совпадающими данными.
  - Ожидаемый выход: флаг дубля или карточка на проверку.
  - Ошибка/эскалация: спорный дубль передаётся человеку.
- Как руководитель, когда начинается день, я хочу получать сводку в Telegram, чтобы видеть новые, зависшие и дубли без ручного сбора.
  - Вход: поток заявок за день.
  - Ожидаемый выход: короткая автоматическая сводка.
  - Ошибка/эскалация: если данные неполные, сводка помечает это как не подтверждено.
- Числовой порог качества:
  - Время от поступления заявки до взятия в работу – не более 30 минут.
  - Доля дублей – в пределах пары процентов.

## 11. Метрики успешности проекта и ожидаемый эффект
- Трудозатраты сейчас – около 35-53 часов в неделю на всех по расчёту Төре, подтверждённому владельцем.
- Личная нагрузка Ержана – около 1 часа в день на отчёт наверх.
- Ожидаемая экономия – 25-35 часов в неделю за счёт приёма из почты, первичной регистрации и поиска дублей.
- Метрика скорости – заявка берётся в работу не позже 30 минут после поступления.
- Метрика качества – дубли удерживаются в пределах пары процентов.
- Метрика устойчивости – статусы обновляются в день поступления, без потерь из почты и спама.
- Метрика управляемости – руководитель получает автоматическую сводку без ручного сбора.

## 12. Риски, SLA и ограничения
- ПДн есть: ФИО, адреса, телефоны клиентов, поэтому решение должно оставаться во внутреннем контуре КТ.
- Цена ошибки – клиент может получить два звонка, заявка может потеряться, отчёт наверх может исказиться.
- SLA по скорости есть: заявка должна быть взята в работу максимум за 30 минут.
- В акции объём удваивается, и именно тогда процесс разваливается.
- Половина менеджеров возрастные, поэтому интерфейс должен быть проще WhatsApp.
- Письма с сайта могут попадать в спам общего ящика.
- **Оценка аналитика: возможно более простое решение**
  - Слишком простой вариант без рабочего экрана не подходит: у менеджеров поток заявок построчный и общий статус должен быть виден в работе, а не только в сводке.

## 13. Передача в работу
- Access contacts:
  - Ержан Асанов, @erjan_a, +7 701 555 3311.
- IT contacts:
  - Динара из Excel – поднимет точную цифру по прошлой неделе.
- Approvers:
  - Руководитель отдела продаж.
- Previous automation attempts:
  - не подтверждено – уточнит Ержан или Серик.
- Рабочие источники:
  - Lotus-ящик `sales.almaty@kt.kz`.
  - Excel-файл `zayavki_2026.xlsx`.
  - Сетевой диск `\\ktfs01\sales\заявки`.

## 14. Что осталось уточнить
- Точная цифра заявок за прошлую неделю – уточнит Динара.
- API или иные точки интеграции у Lotus и Excel – уточнит ИТ-сопровождение.
- Прежние попытки автоматизации – не подтверждено – уточнит Ержан или Серик.
- Кто именно будет принимать работу по решению – уточнит руководитель отдела продаж.
- Точный допустимый процент дублей в числах – уточнит Ержан, если потребуется формализация.
- Детали маршрута передачи спорных случаев – уточнит Серик.
- Дата старта проекта – не подтверждено – уточнит Департамент AI (ДЦБ).

Проверьте, пожалуйста, и скажите, если нужно что-то поправить.