158 lines
16 KiB
Markdown
158 lines
16 KiB
Markdown
# ПАСПОРТ ИИ-АГЕНТА
|
||
|
||
| Поле | Значение |
|
||
|---|---|
|
||
| Наименование | ИИ-агент для заявок на подключение |
|
||
| Категория | Высокая (ПДн клиентов, цена ошибки – потеря заявки, двойной звонок, искажённый отчёт) |
|
||
| Сложность | Высокая (поток десятков заявок в день, общий реестр, построчная проверка, несколько ролей, внутренние источники) |
|
||
| Исполнитель | Департамент 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 (ДЦБ). |