Внедрение ИИ в бизнес: шесть процессов, с которых стоит начать

Какие шесть процессов тестировать первыми

Эти шесть процессов встречаются и в финтехе, и в клиниках, и в обычной операционной работе, потому что у каждого уже есть очередь, узкое место и цифра. Поэтому их безопасно тестировать: вы измеряете состояние «до» за 5–10 рабочих дней, проводите 14-дневный тест с ИИ и измеряете «после» на тех же кейсах.

Процесс	Отрасль	Какую метрику двигает	Кто проверяет
1. Проверка документов клиента (KYC)	Финтех	Время на заявку, доля ручной проверки	Аналитик подписывает каждый помеченный файл
2. Разбор платёжных споров	Финтех	Время на кейс, доля ошибок	Проверяющий подтверждает ответ до отправки
3. Первичная обработка и сортировка заявок пациентов	Медицина	Время до первого ответа, доля заявок, дошедших до записи	Все медицинские решения принимает персонал клиники
4. Автоматизация маркетинговой отчётности	Все	Часы на отчётность в неделю	Руководитель маркетинга утверждает отчёт до рассылки
5. Квалификация и распределение лидов	Все	Время до первого контакта, доля квалифицированных	Менеджер подтверждает, что правило сработало верно
6. Помощь в закрытии месяца	Все	Дни до закрытия	Закрытие подписывает главный бухгалтер, а не инструмент

1. Проверка документов клиента (KYC)

Проверка документов клиента, KYC (know your customer, «знай своего клиента»), — это этап, на котором документы нового клиента, регистрационные данные компании и сведения о бенефициарах сверяются с правилами онбординга до открытия счёта. В версии с ИИ система читает присланные документы, извлекает 10–15 полей, которые требует ваша политика, и помечает расхождения. Человеку больше не нужно перепечатывать каждое поле вручную.

Процесс работает с документами, удостоверяющими личность, а для клиентов-юрлиц ещё и с данными о бенефициарах. В оригинале статьи пример американский: по правилу FinCEN о надлежащей проверке клиентов финансовая организация должна установить и проверить бенефициаров клиента-юрлица до открытия счёта, как правило, всех, кто владеет 25% и более. Отслеживать стоит время на заявку и долю ручной проверки, то есть долю файлов, которые всё ещё разбирает человек.

Проверка человеком здесь обязательна. Аналитик подписывает каждый файл, помеченный системой, и выборочно, обычно один из десяти, проверяет файлы, которые система пропустила автоматически, чтобы заметить дрейф. Решение «принять или отклонить» по помеченному файлу не автоматизируйте. Автоматизируйте чтение документов и извлечение полей, на которых это решение строится.

Пропустите этот процесс, если у вас меньше 20 заявок на онбординг в месяц. При таком потоке 14-дневный тест охватит меньше 10 кейсов, этого мало, чтобы надёжно оценить долю ошибок, а человек прочитает файлы быстрее, чем вы соберёте и проверите тест.

2. Разбор платёжных споров

Разбор платёжных споров сопоставляет входящий чарджбэк или спор с исходной транзакцией, иногда давностью до 90 дней, собирает доказательства и готовит ответ в срок, который задаёт процессинг. Процесс затрагивает записи о транзакциях, переписку по спору и доказательства мерчанта, а в них могут быть данные держателей карт, которые уже покрывает ваш контур PCI.

Сроки здесь жёсткие. В оригинале приведён американский пример: правила карточных сетей и, для многих потребительских счетов в США, процедуры Regulation E дают финансовой организации, как правило, 10 рабочих дней на расследование или до 45 дней, если в течение 10 дней она зачисляет клиенту предварительную компенсацию. Сценарий с ИИ, который пропускает срок, вредит сильнее, чем сценарий, который работает на несколько часов медленнее, поэтому время цикла относительно срока регулятора важно не меньше доли ошибок.

Проверяющий подтверждает подготовленный ответ и подобранные доказательства до того, как что-то попадёт в дело или к держателю карты. Итоговое решение по спору автоматизации не отдавайте. Пропустите этот процесс, если споров так мало, что сотрудник уже закрывает каждый внутри 10-дневного окна без просрочек. Тест окупается только тогда, когда объём создаёт очередь.

3. Первичная обработка и сортировка заявок пациентов

Первичная обработка заявок пациентов — это сортировка входящих обращений (звонков, форм с сайта, сообщений в мессенджерах и личном кабинете) по двум-трём уровням срочности и по направлению до того, как администратор запишет пациента или перезвонит ему. Например, обращение «болит зуб, отёк» уходит в срочную очередь стоматологии, а вопрос о стоимости профгигиены попадает в обычную. Процесс работает со сведениями о здоровье с первого сообщения.

Метрики — время до первого ответа и доля заявок, дошедших до записи без второго круга уточнений. Любое решение о диагнозе, повышении срочности или маршруте лечения принимают врач или медицинский персонал клиники. Инструмент сортирует и готовит черновик ответа, но не решает. Подробно 14-дневный тест этого процесса, включая согласия и обращение с данными, разобран в материале об обработке заявок пациентов.

Пропустите этот процесс, если заявок так мало, обычно меньше 30–40 в день, что один-два администратора уже отвечают на каждую в целевое время. Автоматизация очереди, которая не перегружена, добавляет риск без сопоставимой выгоды.

4. Автоматизация маркетинговой отчётности

Автоматизация маркетинговой отчётности собирает цифры из трёх-пяти рекламных кабинетов, CRM и системы аналитики в один регулярный отчёт по расписанию, вместо того чтобы кто-то каждую неделю сводил таблицы вручную. Для клиники это, например, Яндекс Директ, VK Реклама, Яндекс Метрика, amoCRM или Битрикс24 и выгрузка записей из медицинской информационной системы. Процесс затрагивает данные о кампаниях и, если они есть в CRM, контактные данные, которые уже покрывает ваша политика обработки персональных данных.

Метрика — часы на отчётность в неделю, измеренные до старта и через 14 дней. Первые 90 дней работы процесса руководитель маркетинга утверждает каждый отчёт до рассылки. Когда отчёт три цикла подряд держится без правок, можно перейти на выборочную проверку.

Пропустите этот процесс, если отчётность уже занимает меньше двух часов в неделю. При таком объёме настройка и проверка могут стоить дороже, чем сэкономят, и правильнее сократить отчёт, чем автоматизировать его сборку.

5. Квалификация и распределение лидов

Квалификация и распределение лидов оценивают входящую заявку по вашим критериям и отправляют её одному из нескольких менеджеров или в нужную очередь в течение 5–10 минут после отправки формы, вместо того чтобы заявка лежала в общем ящике. В клинике это может быть распределение по направлениям: имплантация к одному координатору, детская стоматология к другому. Процесс затрагивает контактные данные и поля, которые использует ваша модель оценки.

Отслеживайте две цифры: время до первого контакта и долю квалифицированных, то есть долю распределённых лидов, которые менеджер подтвердил как целевые. Менеджер раз в неделю проверяет выборку лидов, правильно ли сработало правило. Проверять каждый лид обычно непрактично из-за объёма.

Пропустите этот процесс, если все входящие лиды обрабатывает один человек, обычно до 20–30 в неделю, и отвечает в целевое время. Выгода от автоматического распределения появляется, когда объём превышает возможности одного человека разбирать общий ящик вручную.

6. Помощь в закрытии месяца

Помощь в закрытии месяца готовит сверки по 5–10 счетам, которые обычно задерживают закрытие, помечает отклонения от бюджета и пишет первую версию комментариев к закрытию. Финансовая команда тратит время на исключения, а не на сборку базовых цифр. Процесс затрагивает главную книгу, банковские выписки и вспомогательные регистры, из которых собирается закрытие.

Метрика — дни до закрытия, от конца периода до подписи главного бухгалтера или финансового контролёра. Закрытие, которое занимает 12 дней, часто можно сократить до 5–7, когда рутинные сверки автоматизированы и проверяются, а не делаются вручную. Подписывает закрытие человек каждый месяц, независимо от того, как работает сценарий: автоматизация готовит цифры, но не заверяет их.

Пропустите этот процесс, если закрытие уже укладывается в 5 дней, а план счетов короче 100 строк. Процесс окупается, когда закрытие длится больше 10 дней или занимает больше одного человека на большую часть недели.

Как выстроить очередь, если вы начинаете с нуля

Начните с процесса, где уже есть цифра и жалоба, а не с того, который эффектнее смотрится в презентации. Закрытие месяца за 12 дней — более громкая и измеримая проблема, чем отчёт на три часа, поэтому обычно первый 14-дневный тест достаётся ему. Первые два раунда, примерно 60–90 дней, ведите один процесс за раз. Когда команда один раз прошла цикл «тест, проверка, масштабирование», второй процесс запускать параллельно проще: роль проверяющего, привычка откатывать изменения и ритм отчётности уже есть.

Все шесть процессов укладываются в одну практику, AI for Real Work: один названный процесс, один владелец, метрика до и после. Взгляд со стороны заказчика на ту же дисциплину есть в материале о выборе партнёра по автоматизации с ИИ (на английском): как определить объём и бюджет проекта вокруг одного из этих процессов. Финтех-командам, которые сравнивают автоматизацию KYC и споров с более широкой операционной моделью, подойдёт материал о маркетинговых операциях в финтехе. Если у ваших цифр пока нет владельца, начните с чек-листа аудита маркетинга или с материала о роли менеджера по RevOps.

Больше о том, как мы формулируем и измеряем такую работу, — в разделе AI for Real Work. Если один из шести процессов совпадает с узким местом, для которого у вас уже есть цифра, напишите нам, и мы определим рамки 14-дневного теста.

Вопросы и ответы

Источники

1. Financial Crimes Enforcement Network, Customer Due Diligence Rule FAQs
2. Consumer Financial Protection Bureau, Regulation E, 12 CFR 1005.11, Procedures for resolving errors
3. U.S. Department of Health and Human Services, HIPAA Minimum Necessary Requirement
4. КонсультантПлюс, Федеральный закон от 27.07.2006 N 152-ФЗ «О персональных данных», ст. 5 «Принципы обработки персональных данных»
5. КонсультантПлюс, Федеральный закон от 27.07.2006 N 152-ФЗ «О персональных данных», ст. 10 «Специальные категории персональных данных»