# ПАСПОРТ ИИ-АГЕНТА

| Поле | Значение |
|---|---|
| Наименование | ИИ-агент для заявок на подключение |
| Категория | Высокая (ПДн клиентов, цена ошибки – потеря заявки, двойной звонок, искажённый отчёт) |
| Сложность | Высокая (поток десятков заявок в день, общий реестр, построчная проверка, несколько ролей, внутренние источники) |
| Исполнитель | Департамент AI (ДЦБ) АО «Казахтелеком» |
| Заказчик / Владелец | Ержан Асанов, Дивизион по трансформации, отдел продаж филиала Алматы, @erjan_a, +7 701 555 3311 |
| Дата внедрения | – |
| Пользователь | Менеджер отдела продаж, старший менеджер, руководитель отдела |

## 1. Предпосылки
- В отделе продаж заявки на подключение теряются между Lotus-почтой и Excel, а клиент может ждать взятия в работу полдня вместо нормы 30 минут.
- Ручной поток создаёт дубли, повторные звонки клиенту и искажённую картину для руководителя.
- Один общий Excel-файл на сетевом диске создаёт ожидание, потому что одновременно работать с ним неудобно.
- Статусы обновляются с задержкой 2-3 дня, поэтому управление идёт по устаревшей картине.
- В пиковые периоды, когда заявок вдвое больше, процесс разваливается сильнее всего.
- Половина менеджеров возрастные, поэтому интерфейс должен быть проще WhatsApp, иначе решение не взлетит.

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

## 3. Процессы / функции для внедрения ИИ
- Приём заявки из Lotus или из ручного ввода после звонка клиента.
- Первичная регистрация заявки в рабочем списке.
- Поиск дублей по ФИО, адресу, телефону и другим доступным признакам.
- Выделение спорных случаев для подтверждения человеком.
- Обновление статуса заявки в общем реестре.
- Формирование сводки для руководителя в Telegram.
- Подготовка Excel-выгрузки как привычного дополнительного формата.

## 4. Шаги процесса
- Триггер: заявка приходит из общего Lotus-ящика или менеджер записывает её после звонка клиента.
- Агент забирает заявку и проверяет, есть ли она уже в потоке.
- Агент сопоставляет данные и ищет возможный дубль.
- Если совпадение уверенное, заявка идёт в рабочий список.
- Если совпадение спорное, агент отдаёт заявку менеджеру на подтверждение.
- Менеджер подтверждает, отклоняет или дорабатывает спорную заявку.
- Агент обновляет статус в общем реестре и готовит сводку.
- Руководитель получает автоматическую сводку в Telegram.
- Финальный результат – заявка в работе и актуальный статус в реестре.

## 5. Результат работы агента
- Отдельный экран со списком заявок и статусами для менеджеров.
- Автоматическая сводка в Telegram для Ержана.
- Excel-выгрузка как дополнительный привычный формат.
- Статусы: новая, в работе, на проверке, спорная, просрочка.
- Критерий качества результата – заявка должна попадать в работу не позже чем через 30 минут.
- Критерий качества результата – доля дублей должна удерживаться в пределах пары процентов.

## 6. Ожидаемый эффект
- Снижение трудозатрат на 25-35 часов в неделю за счёт приёма из почты, первичной регистрации и поиска дублей.
- Сокращение личной ручной нагрузки Ержана примерно на 1 час в день.
- Снижение потерь заявок из почты и спама.
- Снижение повторных звонков клиентам.
- Ускорение взятия заявки в работу с полудня до нормы 30 минут.
- Повышение актуальности статусов в день поступления.

## 7. Экономический эффект
- Оценка экономии в часах подтверждена: 25-35 часов в неделю.
- Полный эффект в тенге не считался.
- Источник расчёта эффекта – объём 212 заявок за прошлую неделю, 10-15 минут ручной работы на заявку и подтверждение владельца.
- Дополнительный эффект – почти полное снятие личного часа Ержана на ежедневный отчёт.

## 8. Контроль и риски
- Агент не должен сам принимать спорные дубли без подтверждения человека.
- Агент не должен выносить ПДн наружу.
- Ошибка агента может привести к двойному звонку клиенту.
- Ошибка агента может привести к потере заявки.
- Ошибка агента может исказить отчёт наверх.
- В пиковые дни риск возрастает, потому что поток удваивается.
- При разном написании фамилии дубль может быть не распознан без дополнительной проверки.
- Интерфейс должен быть максимально простым, иначе менеджеры не будут им пользоваться.

## 9. Меры по снижению рисков
- Все спорные дубли передаются менеджеру на подтверждение.
- Все данные остаются во внутреннем контуре КТ.
- Для менеджеров нужен отдельный экран с построчной работой, а не сложный интерфейс.
- Для руководителя нужна автоматическая сводка, чтобы убрать ручной сбор.
- Дубли допустимы только в пределах пары процентов.
- Статусы должны обновляться в день поступления, чтобы не копить устаревшие записи.

## 10. Рекомендуемый формат реализации
- Маршрут: `Alem + веб-панель` – отдельный экран нужен менеджерам, а руководителю нужна автоматическая сводка в Telegram; процесс построчный, с общим состоянием и несколькими ролями.
- Почему подходит: есть поток десятков заявок в день, работа идёт по каждой заявке отдельно, и менеджерам нужен рабочий экран, а не только чат или сводка.
- Что делает Alem: агент читает Lotus и Excel, ищет дубли, формирует карточки, отдаёт спорные случаи на подтверждение и готовит сводку.
- Что вне Alem / требует подтверждения: точная точка входа панели, доступы к источникам, правила пометки спорных случаев и интеграционные детали.
- Не обещать запуск: маршрут – рекомендация; до production нужны подтверждения доступов, ИБ, интеграций и бюджета; финальное решение – Департамент AI (ДЦБ).

### Карточка агента Alem (черновик)
- Название: ИИ-агент для заявок на подключение.
- Тип агента: agent_with_approval.
- Суть системного промпта: забирай заявки из Lotus и Excel, ищи дубли, помечай спорные случаи, обновляй статусы, готовь сводку для руководителя, не выноси ПДн наружу.
- Базы знаний: регламент обработки заявок, правила дублей, шаблоны статусов, примеры рабочих заявок, список полей ФИО / адрес / тариф / статус / менеджер / дата.
- Инструменты / MCP: Lotus-почта, Excel-реестр на `\\ktfs01\sales\заявки`, Telegram-уведомления, рабочий экран / панель.
- Примеры диалога:
  - «Покажи новые заявки за сегодня».
  - «Какие заявки спорные и требуют подтверждения?»
  - «Сформируй утреннюю сводку для Ержана».
- Правила draft-подтверждения:
  - Спорные дубли не подтверждать автоматически.
  - Любое действие с внешним эффектом – только после подтверждения человека.
  - ПДн не выводить наружу.
- Как протестировать:
  - Заявка должна попасть в работу не позже 30 минут.
  - Доля дублей должна оставаться в пределах пары процентов.
  - Спорные случаи должны уходить человеку.
  - Сводка должна показывать новые, зависшие и дубли.

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

## 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 (ДЦБ).