uchet-zayavok-na-podklyuchen/brief.md

Бриф инициативы: ИИ-агент для заявок на подключение

Суть: отдел продаж филиала Алматы теряет и дублирует заявки на подключение между 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 (ДЦБ).

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